Socket proactively blocks malicious open source packages in your code.
RubyGems and Bundler 4.0.13 introduced an opt-in cooldown feature that can delay installation of newly published gem versions, bringing a time-based supply chain defense to Ruby’s package management workflow.
The feature allows developers to configure Bundler so it will not resolve to a gem version until it has been public for a set number of days. In the example published by RubyGems maintainer Hiroshi SHIBATA, a project can add a cooldown directly to its Gemfile:
source "https://rubygems.org", cooldown: 7
With that setting, Bundler skips gem versions published within the last seven days and chooses versions that fall outside the cooldown window. Cooldown is unset by default, so existing projects continue resolving to the newest eligible versions unless the setting is explicitly enabled.
The feature targets a narrow but recurring supply chain risk: the period immediately after a malicious package version is published. In many compromise scenarios, attackers rely on speed. A maintainer account is taken over, a malicious release is pushed, and automated installs or CI jobs can pick it up before maintainers, registries, or security researchers have time to respond.
Cooldown does not determine whether a gem is safe. It only delays resolution to versions that are too new under the configured policy.
Time-based install delays can reduce exposure to newly published malicious versions, but they can also hold back legitimate releases, including urgent security fixes. Bundler includes an escape hatch for those cases: passing --cooldown 0 disables the delay for a run when a project needs to install the newest available version.
The feature is part of a wider movement among package managers to add install-time controls that account for the speed of modern dependency attacks. pnpm introduced minimumReleaseAge to delay dependency updates, and npm later added a similar minimumReleaseAge setting. RubyGems’ cooldown feature applies the same general idea to Bundler’s resolver.
gem.coop’s cooldown feature tested a similar idea at the registry layer. The independent RubyGems-compatible registry delayed access to newly published gems through a separate gem source. Bundler’s version takes a different route: the delay is applied by the client during dependency resolution, using timestamp metadata from RubyGems.org’s compact index.
Bundler’s cooldown feature depends on per-version created_at metadata now available in RubyGems.org’s v2 compact index, which Bundler uses during dependency resolution.
RubyGems did not add this data to its public API. The timestamp is available to Bundler through the compact index, not as a new public gem metadata field for general API consumers.
When Bundler has the timestamp data, it compares a gem version’s release time against the configured cooldown period and skips versions that are still inside the window. If Bundler cannot prove that a version is too new, it does not block it. Older gem servers, historical entries from before the v2 cutover, and private registries that do not expose the timestamp remain resolvable.
That conservative behavior avoids breaking sources that do not provide the new metadata, but it also means the feature depends on whether Bundler can see release timestamps for a given source.
RubyGems’ announcement describes several ways to enable cooldown. The most project-specific option is the cooldown: keyword on a source in the Gemfile. Bundler also supports project config, global config, the BUNDLE_COOLDOWN environment variable, and command-line flags for bundle install, bundle update, bundle add, and bundle outdated.
The per-source option lets teams apply different policies to different registries. For example, a project could delay new versions from RubyGems.org while allowing an internal gem server to resolve immediately:
source "https://rubygems.org", cooldown: 7
source "https://gems.internal.example.com", cooldown: 0 do
gem "internal-tool"
end
Command-line flags take precedence over configuration settings, which take precedence over per-source Gemfile settings.
Bundler 4.0.13 also makes cooldown visible in bundle outdated. When a newer version exists but is still inside the configured waiting period, Bundler annotates it with the remaining cooldown time rather than treating the project as simply up to date.
Cooldown shipped alongside RubyGems 4.0.13 and Bundler 4.0.13, which also included other enhancements and fixes. In the release notes, RubyGems listed cooldown under Bundler security changes.
The feature follows other recent RubyGems.org security work, including push-time gem validation, checks against Have I Been Pwned to prevent reuse of compromised passwords, mandatory 2FA, trusted publishing, and AI-assisted vulnerability scanning for critical gems backed by Alpha Omega and Anthropic.
Those efforts address different parts of the package supply chain. Registry-side checks can help prevent or detect malicious releases. Authentication improvements make maintainer account compromise harder. Cooldown gives consumers a way to delay adoption of releases that have only just appeared.
The tradeoff is that delay-based controls are not always desirable. A newly published version may be malicious, but it may also be an urgent fix. Bundler’s implementation leaves that decision to projects by making cooldown opt-in and allowing it to be disabled for a specific run.
RubyGems’ cooldown feature brings that control to Bundler at a time when delayed installation is becoming a more common response to fast-moving package compromises. The idea is simple: many malicious releases are detected and removed within hours, while automated installs can consume them almost immediately. A short waiting period gives those detection and takedown processes more time to work before a new version enters a project’s dependency resolution.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。