These tools are very helpful and it’s great that we have so many tools to choose from in this space 👏.
I’d also like to see cargo itself provide some better defaults in support of supply chain safety.
Specifically as a default I’d like to always be in control of the versions of dependencies I’m using. But developers using cargo, similar to developers using npm, or ruby’s bundler, aren’t in control in at least a couple situations:
If you cargo install a tool or dep, the lock file for the tool/dep is ignored unless you pass --locked. This means if a dep released an update containing malware, you get it immediately if you cargo install immediately after the release. This also means CI builds containing secrets like API keys and that run a cargo install could expose an API key to a 5 min old code update, unless developers know to use --locked.
The ecosystem norm is to not commit Cargo.lock files in libs. But the side-effect is any dev who does a fresh clone of the repo, say when a new dev joins a company or getting a new computer, immediately gets max compatible versions, which could be an update released 5 mins ago containing malware.
Would be great to see the ecosystem lean into using lock files in libs and bin installs, or maybe even reevaluate Go’s minimum compatibility dependency resolution which would address both of these, and adopting automatic audit checks like npm.
Definitely interested in hearing how other people mitigate these types of things.
These tools are very helpful and it’s great that we have so many tools to choose from in this space 👏.
I’d also like to see
cargoitself provide some better defaults in support of supply chain safety.Specifically as a default I’d like to always be in control of the versions of dependencies I’m using. But developers using
cargo, similar to developers usingnpm, or ruby’sbundler, aren’t in control in at least a couple situations:If you
cargo installa tool or dep, the lock file for the tool/dep is ignored unless you pass--locked. This means if a dep released an update containing malware, you get it immediately if you cargo install immediately after the release. This also means CI builds containing secrets like API keys and that run a cargo install could expose an API key to a 5 min old code update, unless developers know to use--locked.The ecosystem norm is to not commit
Cargo.lockfiles in libs. But the side-effect is any dev who does a fresh clone of the repo, say when a new dev joins a company or getting a new computer, immediately gets max compatible versions, which could be an update released 5 mins ago containing malware.Would be great to see the ecosystem lean into using lock files in libs and bin installs, or maybe even reevaluate Go’s minimum compatibility dependency resolution which would address both of these, and adopting automatic audit checks like npm.
Definitely interested in hearing how other people mitigate these types of things.
This was really handy, thanks! I was aware of cargo crev, but not the others.