Ruby's Bundler Adds an Opt-In 'Cooldown' That Skips Gem Versions Until They Have Been Public for a Set Number of Days

Overview

The dependency manager that underpins most Ruby projects has shipped a new defense against software supply-chain attacks. According to LWN.net, “Bundler 4.0.13 introduces cooldown, a time-based filter that refuses to resolve to a version until it has been public for at least N days.” The mechanism is opt-in and is meant to deny attackers the narrow window they rely on after compromising a package account.

What We Know

The feature targets a specific attack pattern. As LWN.net describes it, the risk is that “an account is compromised, a malicious version ships, and any bundle install in the minutes that follow resolves straight to it.” By refusing to pick up a release until it has been public for a configured number of days, cooldown gives automated scanners and the wider community time to notice a bad release before projects pull it in.

Cooldown is layered on top of existing protections rather than replacing them. LWN.net notes that “it is opt-in, and complements rather than replaces existing defenses like mandatory 2FA and trusted publishing.”

The design details are documented in a RubyGems GitHub discussion, opened by a contributor using the handle mudge in November 2025, that proposed the option before it shipped. According to that discussion, “versions within the cooldown period are excluded from the candidate set during version resolution — they are treated as if they do not exist.” In other words, the resolver behaves as though too-new releases simply are not available, and falls back to the most recent version that has aged past the window.

The window is expressed in whole days. The GitHub discussion states that “--cooldown 3 means ‘only consider versions published 3 or more days ago,’” while “--cooldown 0 temporarily disables cooldown regardless of other settings.” The same discussion shows the setting can be declared per source in a Gemfile with the syntax source "https://rubygems.org", cooldown: 7.

The filter does not apply uniformly to every command. The GitHub discussion lists the affected operations as bundle install without a lockfile, bundle update, bundle add, bundle outdated, gem install, and gem update; a bundle install run against an existing lockfile is not subject to cooldown checks, so previously locked versions are left untouched.

The idea is not unique to Ruby. The GitHub discussion cites prior art across other ecosystems, noting that “npm-check-update supports this natively via its cooldown option, pnpm via its minimumReleaseAge, and Dependabot via cooldown.”

What We Don’t Know

The public reporting covered here does not quantify how much cooldown reduces real-world compromise rates, nor what default window length, if any, projects will converge on. Because the feature is opt-in, its practical impact will depend on adoption, and the sources reviewed here do not provide adoption figures. The trade-off is also inherent rather than measured in these sources: a cooldown that blocks a malicious release also delays a legitimate security patch by the same number of days, and the reporting here does not resolve how teams should tune the window against that tension.

Analysis

Cooldown reframes a timing problem as a configuration setting. Most package-registry attacks are a race: defenders must detect and pull a malicious version faster than victims install it, and as LWN.net summarizes, an automated bundle install can lose that race within minutes. Adding a deliberate delay shifts the advantage back toward defenders without requiring registry-side changes, which is why, per the GitHub discussion, comparable options already exist in npm tooling, pnpm, and Dependabot. Bundler’s contribution is to bring the same defense to the default Ruby toolchain as a first-class, per-source option rather than a third-party add-on.