Repository navigation
Value of adding a --cooldown option to delay adoption of crate versions #963
Description
Supply-chain attacks can exploit Cargo's behavior of resolving a project's Cargo.toml restrictions to the newest compatible versions in Cargo.lock.
Other package managers have similar behavior -- for instance, notoriously, the community has suffered from supply-chain attacks through npm, with Trivy and Axios getting gravely compromised in March of this year.
In May, npm-check-updates added a --cooldown option to help prevent most of the impact of such attacks. Other package managers did or are doing the same.
Indeed, compromised package versions tend to be noticed in a matter of hours or days, the alarm is raised, the compromised versions get pulled. A 10-day cooldown would have protected anyone from both the Axios attack and the Trivy attack. Detection speed being roughly proportional to package popularity, adding a cooldown mechanism is simple and effective for supply chain attack mitigation.
(from https://www.npmjs.com/package/npm-check-updates)
I'm writing this issue to ask you to assess the value (and effort) of adding a --cooldown option of your own to cargo-edit, to delay adoption of crate versions and help make software a bit safer.
I'm aware that there's an RFC currently happening about this topic in the rust-lang repo, so maybe Cargo itself is poised to implement a cooldown feature and cargo-edit doesn't need to. Is that correct?
Thank you for all the free cool stuff
Activity
epage commentedon Jun 7, 2026
We'll still need something when setting version requirements.
I'd like Cargo to lead out and us to follow.
cschanhniem commentedon Jun 18, 2026
There's an important distinction worth keeping in mind:
cargo updateresolves to the latest compatible version within your existing semver constraint and writes Cargo.lock (transient), butcargo upgradeedits Cargo.toml source-of-truth version requirements (persistent). A cooldown in cargo-edit serves a different purpose than one in Cargo itself — it gates what developers adopt as policy for a project, not just what gets resolved on a given machine.That suggests a cooldown implementation in cargo-edit could be richer than just time-based:
I think (2) and (3) could give a Rust-specific cooldown that's actually stronger than npm's. The crates.io API already exposes download data, and cargo-vet's trust model is explicitly designed for exactly this kind of gating.
AMDmi3 commentedon Jul 9, 2026
Worth mentioning that
min-publishing-agesetting was recently implemented in cargo. Would be nice to have at least the symmetrical setting forcargo upgrade, otherwise it's impossible to use bothupdatewith min-publishing-age andupgrade.