cargo/tests/lockfile-compat.rs

279 lines
6.8 KiB
Rust
Raw Normal View History

Add sha256 checksums to the lockfile 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
2016-02-03 19:04:07 +00:00
#[macro_use]
extern crate cargotest;
extern crate hamcrest;
use std::fs::File;
use std::io::prelude::*;
use cargotest::support::git;
use cargotest::support::registry::Package;
use cargotest::support::{execs, project};
use hamcrest::assert_that;
#[test]
fn oldest_lockfile_still_works() {
Package::new("foo", "0.1.0").publish();
let p = project("bar")
.file("Cargo.toml", r#"
[project]
name = "bar"
version = "0.0.1"
authors = []
[dependencies]
foo = "0.1.0"
"#)
.file("src/lib.rs", "");
p.build();
let lockfile = r#"
[root]
name = "bar"
version = "0.0.1"
dependencies = [
"foo 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "foo"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
"#;
File::create(p.root().join("Cargo.lock")).unwrap()
.write_all(lockfile.as_bytes()).unwrap();
assert_that(p.cargo("build"),
execs().with_status(0));
let mut lock = String::new();
File::open(p.root().join("Cargo.lock")).unwrap()
.read_to_string(&mut lock).unwrap();
assert!(lock.starts_with(lockfile.trim()));
}
#[test]
fn totally_wild_checksums_works() {
Package::new("foo", "0.1.0").publish();
let p = project("bar")
.file("Cargo.toml", r#"
[project]
name = "bar"
version = "0.0.1"
authors = []
[dependencies]
foo = "0.1.0"
"#)
.file("src/lib.rs", "");
p.build();
File::create(p.root().join("Cargo.lock")).unwrap().write_all(br#"
[root]
name = "bar"
version = "0.0.1"
dependencies = [
"foo 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "foo"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[metadata]
"checksum baz 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "checksum"
"checksum foo 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "checksum"
"#).unwrap();
assert_that(p.cargo("build"),
execs().with_status(0));
let mut lock = String::new();
File::open(p.root().join("Cargo.lock")).unwrap()
.read_to_string(&mut lock).unwrap();
assert!(lock.starts_with(r#"
[root]
name = "bar"
version = "0.0.1"
dependencies = [
"foo 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "foo"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[metadata]
"#.trim()));
}
#[test]
fn wrong_checksum_is_an_error() {
Package::new("foo", "0.1.0").publish();
let p = project("bar")
.file("Cargo.toml", r#"
[project]
name = "bar"
version = "0.0.1"
authors = []
[dependencies]
foo = "0.1.0"
"#)
.file("src/lib.rs", "");
p.build();
t!(t!(File::create(p.root().join("Cargo.lock"))).write_all(br#"
[root]
name = "bar"
version = "0.0.1"
dependencies = [
"foo 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "foo"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[metadata]
"checksum foo 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "checksum"
"#));
assert_that(p.cargo("build"),
execs().with_status(101).with_stderr("\
[UPDATING] registry `[..]`
error: checksum for `foo v0.1.0` changed between lock files
this could be indicative of a few possible errors:
* the lock file is corrupt
* a replacement source in use (e.g. a mirror) returned a different checksum
* the source itself may be corrupt in one way or another
2016-07-26 22:23:20 +00:00
unable to verify that `foo v0.1.0` is the same as when the lockfile was generated
Add sha256 checksums to the lockfile 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
2016-02-03 19:04:07 +00:00
"));
}
// If the checksum is unlisted in the lockfile (e.g. <none>) yet we can
// calculate it (e.g. it's a registry dep), then we should in theory just fill
// it in.
#[test]
fn unlisted_checksum_is_bad_if_we_calculate() {
Package::new("foo", "0.1.0").publish();
let p = project("bar")
.file("Cargo.toml", r#"
[project]
name = "bar"
version = "0.0.1"
authors = []
[dependencies]
foo = "0.1.0"
"#)
.file("src/lib.rs", "");
p.build();
t!(t!(File::create(p.root().join("Cargo.lock"))).write_all(br#"
[root]
name = "bar"
version = "0.0.1"
dependencies = [
"foo 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "foo"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[metadata]
"checksum foo 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "<none>"
"#));
assert_that(p.cargo("fetch"),
execs().with_status(101).with_stderr("\
[UPDATING] registry `[..]`
error: checksum for `foo v0.1.0` was not previously calculated, but a checksum \
could now be calculated
this could be indicative of a few possible situations:
* the source `[..]` did not previously support checksums,
but was replaced with one that does
* newer Cargo implementations know how to checksum this source, but this
older implementation does not
* the lock file is corrupt
"));
}
// If the checksum is listed in the lockfile yet we cannot calculate it (e.g.
// git dependencies as of today), then make sure we choke.
#[test]
fn listed_checksum_bad_if_we_cannot_compute() {
let git = git::new("foo", |p| {
p.file("Cargo.toml", r#"
[project]
name = "foo"
version = "0.1.0"
authors = []
"#)
.file("src/lib.rs", "")
}).unwrap();
let p = project("bar")
.file("Cargo.toml", &format!(r#"
[project]
name = "bar"
version = "0.0.1"
authors = []
[dependencies]
foo = {{ git = '{}' }}
"#, git.url()))
.file("src/lib.rs", "");
p.build();
let lockfile = format!(r#"
[root]
name = "bar"
version = "0.0.1"
dependencies = [
"foo 0.1.0 (git+{0})"
]
[[package]]
name = "foo"
version = "0.1.0"
source = "git+{0}"
[metadata]
"checksum foo 0.1.0 (git+{0})" = "checksum"
"#, git.url());
File::create(p.root().join("Cargo.lock")).unwrap()
.write_all(lockfile.as_bytes()).unwrap();
assert_that(p.cargo("fetch"),
execs().with_status(101).with_stderr("\
[UPDATING] git repository `[..]`
error: checksum for `foo v0.1.0 ([..])` could not be calculated, but a \
checksum is listed in the existing lock file[..]
this could be indicative of a few possible situations:
* the source `[..]` supports checksums,
but was replaced with one that doesn't
* the lock file is corrupt
2016-07-26 22:23:20 +00:00
unable to verify that `foo v0.1.0 ([..])` is the same as when the lockfile was generated
Add sha256 checksums to the lockfile 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
2016-02-03 19:04:07 +00:00
"));
}