You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit changes how lock files are encoded by checksums for each package in
the lockfile to the `[metadata]` section. The previous commit implemented the
ability to redirect sources, but the core assumption there was that a package
coming from two different locations was always the same. An inevitable case,
however, is that a source gets corrupted or, worse, ships a modified version of
a crate to introduce instability between two "mirrors".
The purpose of adding checksums will be to resolve this discrepancy. Each crate
coming from crates.io will now record its sha256 checksum in the lock file. When
a lock file already exists, the new checksum for a crate will be checked against
it, and if they differ compilation will be aborted. Currently only registry
crates will have sha256 checksums listed, all other sources do not have
checksums at this time.
The astute may notice that if the lock file format is changing, then a lock file
generated by a newer Cargo might be mangled by an older Cargo. In anticipation
of this, however, all Cargo versions published support a `[metadata]` section of
the lock file which is transparently carried forward if encountered. This means
that older Cargos compiling with a newer lock file will not verify checksums in
the lock file, but they will carry forward the checksum information and prevent
it from being removed.
There are, however, a few situations where problems may still arise:
1. If an older Cargo takes a newer lockfile (with checksums) and updates it with
a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then
the `[metadata]` section will not be updated appropriately. This modification
would require a newer Cargo to come in and update the checksums for such a
modification.
2. Today Cargo can only calculate checksums for registry sources, but we may
eventually want to support other sources like git (or just straight-up path
sources). If future Cargo implements support for this sort of checksum, then
it's the same problem as above where older Cargos will not know how to keep
the checksum in sync
0 commit comments