Minimum age for dependencies

[larry0x]

Problem

Recently there has been two high severity supply chain attacks on NPM:

• https://x.com/P3b7_/status/1965094840959410230
• https://x.com/feross/status/1967732902256579014

In light of this, pnpm has introduced a minimumReleaseAge parameter, such that it will only install packages older than a chosen age: https://github.com/pnpm/pnpm/releases/tag/v10.16.0

I would recommend cargo implement a similar mechanism.

Proposed Solution

Do the same thing as pnpm.

Notes

No response

[epage]

We have #7193 for a more general dependency resolution hook to allow anyone any policy they want. cargo plumbing commands may be one way to achieve that.

As for directly addressing the request here, we generally recommend the use of a lockfile, so this is mostly a problem when editing dependencies, running cargo update, or running cargo add. The underlying technical requirements are the same as #5221. We'd need to resolve dependencies ignoring everything newer than a timestamp. We currently lack the timestamp in the index. There is the question of how this would interact with yanked since that is mutable state. As compared to #5221, the answer is a little bit more clear here (just use latest).

[epage]

Another consideration is whether we should disallow newer versions (and error if a version req is too high) or fallback when only a newer version allows the resolution to complete.

For incompatible-msrv versions, we talked about this in terms of allow, fallback, and deny.

If we added this field, we'd need to decide

• which is implied by setting minimumReleaseAge
• do we allow customizing how its treated and what do we call that parallel field

[epage]

Looking at npm/rfcs#549 got me thinking

• would we want this to be per registry so corp vs public stuff can be handled separately or do corp registries (e.g. artifactory) normally handle this
• how do we treat git dependencies?

[weihanglo]

https://docs.renovatebot.com/configuration-options/#minimumreleaseage

Just another data point: Renovatebot also has a minimumreleaseage option.

[dertin]

https://crates.io/crates/cargo-cooldown

I built a small PoC to try this idea: cargo-cooldown. It enforces a minimum release age by walking the graph, querying crates.io for created_at/yanked, and auto-pinning the newest compatible version >= N minutes into Cargo.lock. It's functional but rough.
I'm sharing it as evidence the approach is feasible.

[penso]

https://crates.io/crates/cargo-cooldown

I built a small PoC to try this idea: cargo-cooldown. It enforces a minimum release age by walking the graph, querying crates.io for created_at/yanked, and auto-pinning the newest compatible version >= N minutes into Cargo.lock. It's functional but rough. I'm sharing it as evidence the approach is feasible.

Highly recommend using clap for your argument parsing, will be cleaner and you won't have to do stuff manually.

[epage]

See also

• https://docs.rs/clap/latest/clap/_cookbook/cargo_example_derive/index.html
• https://docs.rs/clap-cargo/latest/clap_cargo/

[epage]

In reading discussions on this, a common concern is if this will delay discovery of problems. We had a similar conversation when changing our defaults to committing Cargo.lock for libraries. Not everyone will pick the same update so instead we get a gradual deployment of new versions, depending on people's risk tolerance.

[nicoburns]

I would really like to see:

• crates.io host an auditing system that allows users to submit audit reports crates that they have manually reviewed
• These audits should be based on reviewing the actual published source code through a site like https://diff.rs/ (not the version in source control).
• Support for gating cargo update/cargo install on number of approved audits (with open to restrict to trusted auditors - who each user could specify through a manifest file), and on lack of rejected audits.

This way we would actually be enforcing that N trusted people have read the source code, rather than just that a certain amount of time has passed.

Perhaps this could be developed as an external tool to begin with.