Skip to content

Add --cooldown to gem install, update and outdated - #9734

Open
hsbt wants to merge 4 commits into
masterfrom
cooldown-gem-cli
Open

Add --cooldown to gem install, update and outdated#9734
hsbt wants to merge 4 commits into
masterfrom
cooldown-gem-cli

Conversation

@hsbt

@hsbt hsbt commented Jul 28, 2026

Copy link
Copy Markdown
Member

Gem versions published within the last N days can now be excluded from gem install, gem update (including --system) and gem outdated, porting Bundler's cooldown supply chain mitigation to the gem CLI. The period comes from --cooldown DAYS or the :cooldown: gemrc setting, with the flag taking precedence and 0 disabling it.

Resolution falls back to the newest version outside the window. An explicitly requested version inside the window fails with a hint to pass --cooldown 0. Versions with no known publish time are never excluded, so Marshal indexes, file:// sources and historical versions keep working, with a one-time warning when a source provides no publish times at all. gem update filters at name-tuple selection through the new Gem::Source#created_at, since it installs with an exact version pin.

$ gem install rails --cooldown 7
$ gem outdated --cooldown 7
foo (0.1 < 0.2, 0.3 (cooldown 7d))

Generated with Claude Code

hsbt and others added 4 commits July 28, 2026 18:03
A cooldown period excludes gem versions published within the last N days
from installation and update, as a mitigation against supply chain
attacks through freshly published releases. This adds the configuration
mechanism: the Gem::Cooldown judgment class, the :cooldown: gemrc
setting, and the --cooldown DAYS option mixin. The --cooldown option
takes precedence over gemrc, and 0 disables the cooldown. Versions with
an unknown publish time are never excluded, so the cooldown fails open.

Co-Authored-By: Claude Fable 5 <[email protected]>
The resolver drops release candidates published within the cooldown
period, alongside the platform and required_ruby_version filters, so
gem install falls back to the newest version outside the window.
Installed and lockfile specifications carry no publish time and are
never dropped. When an explicitly requested version is within the
window, resolution fails with a hint naming the cooldown period and the
--cooldown 0 bypass. Sources that provide no publish times at all warn
once and are not filtered.

Co-Authored-By: Claude Fable 5 <[email protected]>
gem update installs the resolved version with an exact pin, so the
resolver filter cannot make it fall back. Filter instead when picking
the target name tuple, using the new Gem::Source#created_at, which
looks up a version's publish time through the compact index info file
for the gem. While a cooldown is active the update and outdated
lookups search the full index instead of the latest-only index, which
carries nothing to fall back to.

gem outdated picks the newest version outside the cooldown period as
the update candidate and annotates a newer version still within the
period with "(cooldown Nd)".

Co-Authored-By: Claude Fable 5 <[email protected]>
The tuple selection and resolver filters already apply to
rubygems-update, so gem update --system needs no dedicated code path.
Add coverage that the newest release within the cooldown period is
passed over in favor of the newest one outside it.

Co-Authored-By: Claude Fable 5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant