Rust 1.100 introduces dependency cooldowns to slow malicious crate adoption
The upcoming Rust release adds an opt-in delay for new dependencies, helping teams catch supply chain attacks before they spread to developer machines.
Key points
- Rust 1.100, arriving November 12, will include stable support for configurable minimum publish ages in Cargo.
- The feature allows teams to reject dependency updates that are too new, giving security scanners time to detect malicious releases.
- This follows August incidents where compromised crates were available for under two hours before removal, spreading via supply chain attacks.
Rust 1.100, scheduled for release on November 12, will introduce stable support for dependency cooldowns in Cargo. This opt-in feature allows development teams to configure a minimum age for package updates, preventing the automatic adoption of newly published crates. According to first-hand research published by Socket, the change aims to give security scanners and maintainers critical time to identify and block malicious releases before they propagate through the ecosystem.
The stabilization pull request merged on August 28, and the feature is currently available in beta channels. Rust’s draft release notes confirm its inclusion in the 1.100 stable version. By default, Cargo’s minimum publish age remains zero, meaning the cooling-off period is not active unless teams explicitly enable it. Developers must adjust their configuration files to apply these delays, ensuring that the protection aligns with their specific security requirements and risk tolerance levels.
Context from recent supply chain attacks
Recent compromises in the Rust ecosystem highlight the urgency of such defensive measures. In August, attackers published compromised versions of the arrayref, internment, and append-only-vec crates. These packages depended on proc-macro1, a malicious crate containing a build script that downloaded a payload. Socket documented how the malicious dependency spread through these three compromised crates, demonstrating how quickly an attack can cascade through the supply chain if new versions are accepted immediately.
The Rust Security Response Team reported that the malicious releases of arrayref, internment, and append-only-vec were available on crates.io for 86, 90, and 107 minutes, respectively, before being removed. All three releases were taken down in under two hours. However, dependency updates often move faster than investigations, pulling malicious code onto developer machines and into continuous integration pipelines before the registry can intervene. A configurable cooldown provides defenders with a necessary head start to detect and respond to these threats.
Implementation and operational details
Work on the cooldown feature predates the August compromises, with the tracking issue opening on May 18 and nightly availability on June 21. Rust contributor Giles Cope emphasized the need for an early minimum viable product to address AI-assisted supply chain attacks. Teams can configure a waiting period, such as seven days, in their .cargo/config.toml file. Cargo’s configuration reference supports durations expressed in seconds, minutes, hours, days, weeks, or months, offering flexibility for different operational needs.
When resolving dependencies, Cargo excludes releases younger than the configured threshold. If no eligible older version satisfies the project’s requirements, resolution fails rather than falling back to a newer, potentially malicious release. This behavior addresses attack scenarios where an attacker publishes a malicious update and yanks safe versions. During the August incident, attackers yanked legitimate versions of arrayref, making the fail-safe approach critical for preventing fallback to compromised code.
What should you do?
Developers planning to upgrade to Rust 1.100 should review their current dependency management practices. Enabling the cooldown feature requires modifying the .cargo/config.toml file to set a minimum publish age. The resolver’s incompatible-publish-age setting defaults to "deny," so a separate resolver entry is unnecessary unless other configurations have changed. Cargo will report when the cooldown is in use and identify newer versions it passed over, including their age, to help developers understand the resolution process.
The system preserves versions already recorded in Cargo.lock, even if they are younger than the configured minimum. This means enabling a cooldown does not retroactively reject a fresh release that has already entered the lockfile. Developers can override the cooldown for urgent fixes if necessary. If resolution fails due to age restrictions, Cargo’s diagnostics explain how to adjust version requirements or override the age check, allowing teams to balance security with operational urgency.
What to do and how to stay safe: Rust
- Review current .cargo/config.toml files to prepare for manual enablement of the minimum publish age setting in Rust 1.100.
- Audit existing Cargo.lock files to identify any dependencies that were recently added and may not have undergone sufficient security review.
- Monitor official Rust security advisories and Socket reports for new supply chain threats that might require overriding the cooldown for legitimate updates.
- Train development teams on the new resolution failure behaviors to ensure they understand how to adjust version requirements when the cooldown blocks updates.
Step-by-step guide: Mobile Device Security: How to Protect Data Beyond Passwords
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Does Rust 1.100 automatically protect against malicious crates without user action?
No, the dependency cooldown feature is opt-in and requires teams to manually configure a minimum publish age in their Cargo settings.
What happens if a project has no older, eligible version of a dependency?
Cargo resolution will fail rather than selecting a newer, potentially malicious release, forcing developers to explicitly adjust requirements or override the check.
Will existing dependencies in Cargo.lock be rejected if they are too new?
No, the resolver preserves versions already recorded in Cargo.lock, so enabling a cooldown does not retroactively reject releases already in the lockfile.
