search

rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.84k stars 2.43k forks source link

Options to update dependencies to "at least X days old" #11167

Open RCasatta opened 2 years ago

RCasatta commented 2 years ago

Problem

Supply chain attacks with malicious packages downloaded via dependencies or indirect dependencies are exploding in the NPM ecosystem.

Auditing of dependencies with tools like cargo crev and cargo vet seems necessary for packages with a high level of security requirement, however, those tools are not widely used yet, and directly auditing dependencies in small teams could be a task too demanding.

Proposed Solution

The proposal is an option for cargo update to update all dependencies up to a certain date in the past to avoid just released packages.

The rationale is that malicious packages are more likely to stay undetected near the release date but after a while they are spotted.

Notes

Example:

my project has in Cargo.toml

[dependencies]
coollib=0.1.0

And a Cargo.lock with the same version.

coollib 0.1.2 is released 30 days ago. coollib 0.1.3 is released yesterday.

I would like to use something like:

cargo update --older 10d

And the Cargo.lock will update to coollib 0.1.2 because 0.1.3 is too recent

epage commented 2 years ago

FYI I've updated your examples to work with cargo update as cargo update won't upgrade from 0.1 to 0.2 but will upgrade 0.1.0 to 0.1.2.

In way this is a user-driven rolling releases which is an intriguing idea. As this is security focused and I know I'm not the greatest in analyzing attack vectors and solutions, I would be interested in hearing from other security people on alternatives, downsides, etc.

For example, what if a security fix is made available, how do we make sure workflows around this feature aren't set to delay people getting it?

RCasatta commented 2 years ago

FYI I've updated your examples to work with cargo update as cargo update won't upgrade from 0.1 to 0.2 but will upgrade 0.1.0 to 0.1.2.

Thanks for the fix

For example, what if a security fix is made available, how do we make sure workflows around this feature aren't set to delay people getting it?

In this workflow, security fixes must be explicitly and singularly updated:

cargo update -p lib-with-security-fixes