Rust 1.100 gives Cargo a cooldown: a minimum age a crate version must reach before the resolver will pick it. It's the right control, and it ships set to zero. A security control that's off by default protects the teams that already think about this, not the teams that never do.
The Control
It's one setting in .cargo/config.toml:
[]
= "3 days"
With that, Cargo "skips any version published more recently than that, and tells you what it held back." Versions already in your Cargo.lock stay put; the config reference only ignores too-new versions "unless they already exist in the lock file." Two gaps worth knowing: cargo install ignores the setting, and versions without a publish time in the index are never held back.
What It Would Have Stopped
In August, the Rust Security Response Team removed a malicious crate, proc-macro1, whose build script was "downloading a malicious payload," and malicious versions of three real crates from one author. arrayref@0.3.10 was online for 86 minutes. internment@0.8.7 for 90. append-only-vec@0.1.9 for 107. The team said the author's "computer or credentials are likely compromised" -- the bad versions came from the account, not from the source.
Under two hours, every one. Any cooldown measured in days would have skipped all three for anyone resolving that morning who hadn't already locked them.
Zero Is a Decision
I understand the default. A resolver that suddenly refuses versions surprises people, and Cargo has always been careful about surprising builds. pnpm went the other way: from v11, "newly published packages won't be resolved until they're at least 1 day old," as I noted when I made the case for cooldowns. Composer went Cargo's way: its new cooldown policy is disabled by default too.
But the default isn't really the point. My read: companies don't fail at supply chain security for lack of tools. They fail for lack of agency, and attention goes to the next customer until something forces it back. An opt-in control is the first thing that never gets turned on. So turn it on, once, where it counts:
- Put it in the repo, not on developer laptops. A
.cargo/config.tomlat the root of a monorepo covers every crate and every CI job in one line of review. - Make the exception loud. When a real security fix lands and you need it today, let it through for that one update, as Socket shows:
CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update -p some-crate --precise 1.2.3. It's in the command, so it shows up in review and in CI logs.
The Tradeoff
A cooldown delays fixes as well as attacks, and it only works because someone else installs first and scanners look -- the hash post covers both. The release notes say it plainly: cooldowns "are not a complete defense on their own." A patient attacker who waits out your window still gets in, and cargo install on a CI runner isn't covered at all. It buys time for detection. That's the part you control today.
Set it, commit it, move on.