search

mozilla / cargo-vet

supply-chain security for Rust
Apache License 2.0
650 stars 43 forks source link

Track the version of cargo-vet used to create the supply-chain store #435

Closed mystor closed 1 year ago

mystor commented 1 year ago

This is important given changes like https://github.com/mozilla/cargo-vet/issues/431, which will change the meaning of imports.lock in such a way that earlier versions of cargo-vet may not understand parts of it correctly anymore. While we generally need to keep the audits.toml file somewhat forward-and-back compatible due to imports, this is less of a concern for other files, so preventing downgrades could be valuable here.

This new approach allows implicit upgrades when running without --locked, but prevents downgrades or locked upgrades. cargo-vet versions with the same minor release are considered compatible, so only the major and minor components are considered.

Fixes https://github.com/mozilla/cargo-vet/issues/430

mystor commented 1 year ago

Builds on top of https://github.com/mozilla/cargo-vet/pull/434, so leaving as a draft until that is merged.

mystor commented 1 year ago

How will we handle migrations in the future if there are incompatibilities? I was expecting to see a strategy (boilerplate) in the code, though it's fine to omit it until we need it.

I figured that pre-building a strategy for doing migrations before we know what we're going to need was a bit of pre-emptive optimization. So far we've never needed to e.g. break serialization and have managed to do migrations fairly painlessly, so I don't want to build an infrastructure for doing that before we need it. The main thing I was adding this for was for the interpretation of the machine-generated imports.lock file, which will be automatically updated the first time someone runs cargo vet with a new version because it'll be re-generated, so no explicit migration is necessary.