RubyGems Blog

Making RubyGems Guides friendly to humans and AI

2026-08-06T00:00:00+00:00

The RubyGems guides at guides.rubygems.org are read by more than humans these days. AI agents fetch them to answer questions about building, publishing, and installing gems. Evil Martians’ Ruby/Rails LLM discoverability scorecard asks how easily an agent can find and read Ruby documentation, and the guides had no good answer. There was no machine readable index, and no way to get a page without its navigation and markup. This week we merged three changes that close both gaps.

The first change adds sitemap.xml and robots.txt (rubygems/guides#523), giving crawlers a complete map of the site. The robots.txt allows everyone, AI crawlers included. Some documentation sites have gone the other way, but these guides exist to be read, and that holds regardless of what is doing the reading.

The second adds llms.txt and llms-full.txt (rubygems/guides#525). llms.txt lists every guide with a one-line description in about 10 KB, so an agent can fetch it once and jump straight to the page it needs. llms-full.txt concatenates the full text of all guides into a single document of about 460 KB, roughly 120,000 tokens. That is most of a context window on many models, so it suits a tool that wants the whole corpus in one pass rather than an agent answering a single question.

Neither file is written by hand. llms.txt is generated from the same sidebar data that builds the site navigation, so a guide that shows up in the menu shows up in the index, and llms-full.txt is assembled by a Jekyll plugin at build time. Neither can quietly fall behind the guides themselves.

The third serves raw Markdown for every page (rubygems/guides#524). Append .md to any guide URL, such as what-is-a-gem.md, and you get the rendered Markdown source with no navigation or markup. That cuts page size to between a half and an eighth of the HTML. what-is-a-gem is 26.7 KB as HTML and 3.3 KB as Markdown. Each HTML page also links its Markdown twin via rel="alternate" type="text/markdown".

To try it, hand your agent the URL https://guides.rubygems.org/llms.txt and ask a RubyGems question. One fetch gives it a table of contents. Every page it reads afterward fills the context window with the answer rather than with navigation and tags, so the same budget covers several times more material.

New formats need fresh content

A machine readable feed is only as useful as the writing behind it. Serving an agent guidance that still mentioned freenode IRC and Ruby 1.8 path layouts would defeat the purpose, so the content was overhauled alongside the formats. The guides are reorganized around tasks instead of tools, into four sections named Getting Started, Guides, Concepts, and Reference. Full-text search is powered by Pagefind, so open any page, press Cmd+K or Ctrl+K, and search the whole site without leaving where you are.

The new Concepts section explains how the system works, from dependency resolution to platforms and native gems. Reference now documents .gemrc configuration and environment variables for the first time, and absorbs the Bundler man pages. The security guide was rewritten around MFA, Trusted Publishing, lockfile checksums, and cooldown.

None of this is a one-off. Project DREAM (Driving Ruby’s Evolution to AI Maturity), which Ruby Central set out in A New Chapter for Ruby Central, calls for extending RubyGems and the infrastructure around it to fit the patterns now emerging around AI. Documentation an agent can consume is part of that. Both audiences want the same things from a guide, which are clear structure, current facts, and a page you can reach without wading through anything else.

This is not a finished piece of work. What counts as machine readable keeps moving, and the conventions that matter a year from now may not be the ones we implemented this week. We will keep watching what actually helps and adapting the guides to it. There is more coming.

4.0.18 Released

2026-08-05T00:00:00+00:00

RubyGems 4.0.18 includes enhancements, bug fixes and documentation and Bundler 4.0.18 includes enhancements, bug fixes, security and documentation.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.18

RubyGems Release Notes

Enhancements:

Check the resolved parent directory before extracting old format gems. Pull request #9755 by hsbt
Installs bundler 4.0.18 as a default gem.

Bug fixes:

Call Kernel.format explicitly in Gem::Deprecate wrapper. Pull request #9714 by hsbt

Documentation:

Point bundler.io URLs at guides.rubygems.org. Pull request #9737 by hsbt

Bundler Release Notes

Enhancements:

Don’t mask install errors when no Gemfile can be located. Pull request #9757 by hsbt
Warn when duplicate source declarations conflict on cooldown. Pull request #9736 by hsbt
Redact URI userinfo from settings names in Bundler User-Agent. Pull request #9716 by hsbt
Validate gem name before building compact index cache paths. Pull request #9717 by hsbt

Bug fixes:

Fail bundle check when frozen mode needs lockfile changes. Pull request #9715 by hsbt
Skip empty checksum values in compact index metadata. Pull request #9713 by hsbt

Security:

Add –cooldown flag to bundle lock and bundle cache. Pull request #9725 by hsbt

Documentation:

Point bundler.io URLs at guides.rubygems.org. Pull request #9737 by hsbt
Document Bundler checksum behavior for default gems. Pull request #9735 by p-linnane
List missing subcommands in bundle(1) UTILITIES section. Pull request #9721 by hsbt
Document pessimistic operator and eval_gemfile in gemfile(5). Pull request #9719 by hsbt

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.18.tgz
8ff8738ecbf147d1bd2eff1ca13ea432c45e9bd9489f46a74fb99e7117ed890c
rubygems-4.0.18.zip
637f11a5b337e85ec746d84b76eee4e27e1697c947c9128492e1c5d6359a18c4
rubygems-update-4.0.18.gem
a6a8653069b81b7977d4d341b3ba9f0212f14aa9756f0143dca2dcc3e793db97

Security advisory: Possible leak of legacy API keys via improper cache configuration

2026-07-22T21:02:00+00:00

A CDN caching bug on RubyGems.org could hand one account’s API key to another person for up to an hour. If you signed in to RubyGems.org with a gem client older than v3.2.0, your key could have been exposed (the technical details are below). Currently, 18% of sign-ins through gem signin come from an affected version, and for the first several years of this bug, before we changed the client’s sign-in path in December 2020, it was every gem client.

We’ve reviewed the access logs we keep and found no sign of a legacy key being used maliciously, and no user or support report has suggested otherwise. Those logs only cover a recent window, though, a small slice of the years this bug is estimated to have been present. Rather than lean on log analysis to rule out any potential abuse, we’ve revoked every RubyGems.org legacy key, and we’re asking owners to check their own gems.

Your already-published gems were never at risk: existing releases cannot be rewritten, and installing gems was never affected. What was at risk is the key itself. Anyone holding a leaked key could act as that account: publish a new gem version, yank versions, add themselves as an owner.

If you had MFA enabled for API requests, your key could still have leaked, but MFA blocks a leaked key from pushing, yanking, or changing owners.

What account holders should check

Existing releases cannot be rewritten, so if you’re an account owner, what you are checking for is anything added or removed under your name. On each of your gems, look for versions you did not publish (especially one higher than your latest), unexpected yanks, unfamiliar owners or maintainers, trusted publishers you did not configure, and webhooks you do not recognise.

We’re notifying users whose account held a legacy API key at any point, since those are the accounts this bug could have exposed, so please keep an eye on your inbox. You can immediately review your account’s API Key history through your profile page.

What is a RubyGems.org Legacy API Key

A Legacy API key is a single credential that carries every gem-management permission at once. It isn’t tied to a single gem, so those permissions apply across every gem you own, and it has no expiry, so it stays valid until you delete it.

In practice that means the key can do many operations the API exposes for publishing and maintaining your gems: push a new version, yank an existing one, add or remove owners, change webhooks, and configure trusted publishers. What it can’t do is act as a full account login. No API key can change your password or email, alter your MFA settings, or delete your account.

The word “legacy” undersells how ordinary these keys were. When this endpoint was built, and for years afterward, this was simply the API key: the only kind RubyGems.org issued, and the only way the gem CLI could sign you in. Scoped keys arrived in RubyGems v3.2.0 in December 2020, and it’s at that point the older keys became “legacy”. So for most of the roughly nine years this bug existed, the affected credential wasn’t a deprecated relic that a few stragglers still used. It was the standard way everyone authenticated.

Who is affected

Users of the rubygems client older than v3.2.0, which signs in by calling GET /api/v1/api_key. Notably, this includes the vendored rubygems with current macOS (Tahoe), version 3.0.3.1 at /usr/bin/gem, so the affected client is a standard system tool, not an edge case.
Recipients of a leaked key, who may be entirely uninvolved account holders. A cached hit wrote another account’s key into their local credentials file, and from that point they acted as the other account until they signed in again.

Technical detail

Under a specific interaction between the response compression and cache headers, our CDN cached the successful response and served the same freshly created key to subsequent callers on the same edge node (POPs) for up to an hour, without re-checking their credentials.

The result was that one account’s API key could be handed to another party, with no attacker involved. Once one user’s sign-in response was cached at a Fastly edge node, the next user signing in through that same node within the hour received the earlier user’s key instead of a fresh one of their own. And because cache hits were served at the edge without contacting the origin, an unauthenticated party could also poll the endpoint to harvest whatever key happened to be cached.

The chain is as follows:

GET /api/v1/api_key authenticates with HTTP Basic and creates a new legacy key, returning it in a 200 body.
The Ruby client sends Accept-Encoding: gzip by default (via Net::HTTP). Rack::Deflater replaces the response body with a GzipStream.
Rack::ETag can’t read the gzipped body, so it falls back to a bare Cache-Control: no-cache, with no private and no Set-Cookie.
With only a bare no-cache and no Vary: Authorization, Fastly cached the 200 for up to an hour under a shared cache key for the single CDN node that processed that request. Every cache hit during that window returned the same key, served at the edge without re-authenticating the caller.
A successful response here is itself the API key.

A detail worth calling out, because it explains why casual testing missed this: the bug is conditional on Accept-Encoding: gzip. A plain curl request, which sends no such header, received a correct-looking Cache-Control: private, must-revalidate response and did not reproduce the issue. The vulnerable path was the one the real Ruby client exercises by default.

The application-side trigger (Rack::Deflater) was introduced on 10 October 2016 (commit 03d89c0). The date the response first became edge-cacheable cannot be established from the repository, so the conservative assumption is that the endpoint was exploitable for most of the roughly nine years since.

We have assigned this incident the following CVSS score:

CVSS Version	4.0
Base Score (CVSS-B)	7.3 (High)
Environmental Score (CVSS-BE)	7.2 (High)
Overall Score	7.2 (High)
Macro Vector	111100

Vector String:

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:H/VA:H/SC:L/SI:H/SA:H/CR:L/IR:H/AR:H/MAV:N/MAC:L/MAT:P/MPR:N/MUI:P/MVC:L/MVI:H/MVA:H/MSC:L/MSI:H/MSA:H

Impact and its limits

Adding an owner and registering a trusted publisher persists even after the key itself is revoked, which is why key revocation alone is necessary but not sufficient, and why we asked owners to review their ownership and trusted-publisher settings.

There are firm limits on what was possible:

Existing gem releases cannot be altered by users. Any existing name, version, and platform is immutable; pushing an already published version is rejected with HTTP 409 “Repushing of gem versions is not allowed”. A yanked version number cannot be reused either.
What “clobbering” actually means here is shipping a new, higher version that supersedes the current one as the default install, yanking versions, or (after yanking all versions) reclaiming a name. A new platform variant of an existing version number is a distinct, allowed artifact rather than an overwrite. None of this rewrites an already-published release.
MFA helps when enabled on API requests. A leaked key is neutralised for push, yank, owner changes, and trusted-publisher changes when the account has enabled it for API requests (ui_and_api), which forces multifactor authentication on those actions. Accounts set to disabled, or ui_and_gem_signin, get no such protection against a leaked key.

When the vulnerable client path was retired

The gem signin flow stopped calling GET /api/v1/api_key in RubyGems v3.2.0, released 10 December 2020, which switched sign-in to POST /api/v1/api_key as part of the introduction of scoped API keys.

That client change did not remove the risk, because the GET endpoint was deliberately kept on the server so that actively maintained clients would keep working. It continued to mint new API keys for every caller until the fix below. In other words, the client version determined only whether the modern gem reached the endpoint; the endpoint itself remained live and cacheable for everyone, including direct API callers, for the whole period.

Why we didn’t detect this before

Attribution of any misuse is difficult by design of the platform, and we want to be plain about that rather than reassuring:

Every action taken with a key is recorded under the legitimate key-holder. The pusher, the event actor, the notification emails, and the rate-limit bucket all read as the rightful owner.
The only signals that distinguish a different caller are the source IP address and user-agent. There was no notification on key use (only on key creation), and no new-IP or velocity alerting on API keys.
As noted above, the flaw only manifested for gzip-compressed requests, so header inspection with ordinary tools did not surface it.

The worst-case exposure dates back to 2016 and our log history is limited. As a result, most of that window cannot be reconstructed. This is why we treated revocation as the remedy and any log review as best-effort corroboration only.

The fix

Deployed in commit d3d11c0 (9 July 2026):

The authentication response now sets Cache-Control: private, no-store, Surrogate-Control: max-age=0, and appends Authorization to Vary on the API key response and on the other authenticated API endpoints. The sign-in response can no longer be stored in a shared cache, and any cache that does store a response now varies on the credential.
We purged the affected objects from Fastly before revoking keys, so re-issued keys could not be re-poisoned.

Remediation and what breaks

We’ve revoked all legacy API keys. No other keys were affected. Scoped keys created through the RubyGems.org UI and the RubyGems CLI were never exposed by this bug, which only affected the legacy sign-in method, not the way scoped keys are created. Short-lived OIDC and trusted-publisher keys were also left alone, since they come from a separate token exchange, expire on their own within minutes, and can’t leak through this path.

Because only legacy keys were revoked, the breakage is limited and predictable:

Both gem install and bundle install are anonymous and keep working.
The next gem push, gem yank, or gem owner using an expired legacy key will return an HTTP 401 response. To recover, create a new API key at https://rubygems.org/profile/api_keys and load it into your local RubyGems configuration by following the API key guide.
For CI or automation using legacy keys, the next gem push will return an HTTP 401 response until you replace the stored key (for example RUBYGEMS_API_KEY or GEM_HOST_API_KEY) with a newly created one. CI that only installs gems is unaffected, and CI already using trusted publishing (OIDC) keeps working, since those keys weren’t revoked and are re-minted on each run.
If you moved off legacy keys to scoped keys, nothing was revoked and no further action is required.

We’ve also retired the old sign-in endpoint (GET /api/v1/api_key), so gem signin on RubyGems clients older than v3.2.0 no longer works. Creating a key on the website and loading it as above works on any client version, and replacing your stored key this way also clears any key you may have been unknowingly holding for another account.

We recommend scoped keys over full-access keys, MFA enabled for API access, and trusted publishing over long-lived keys in CI.

Timeline

10 October 2016: Rack::Deflater added, introducing the application-side trigger (commit 03d89c0).
10 December 2020: RubyGems v3.2.0 released; the modern gem signin stops calling the GET endpoint, though the endpoint remains for older clients.
6 July 2026: reported to RubyGems.org by Luke Marshall
9 July 2026: root-cause fix deployed (commit d3d11c0), Fastly purged
23 July 2026: Legacy API keys revoked, affected users notified & public disclosure published

Credit

Thanks to Luke Marshall from Truffle Security for the responsible report and for working with us through remediation. This security report has been published as GHSA-9j48-x3c3-mrp2

Our commitment to security

I lead the team that maintains RubyGems.org and my name is on Bundler, rubygems & RubyGems.org going back almost a decade. When the report came in, the first thing I felt wasn’t so much about the bug itself. It was the question of how it sat there, in the open, for the better part of a decade, and we never caught it ourselves. We found this because someone told us, not because we saw it, and I want to be honest about that.

Beyond the actions we’ve taken today, we’re looking at expanding the two-factor authentication requirement across the platform in 2026, so a single leaked key is worth much less on its own. If you haven’t already, please turn it on today and set it to apply to both the UI and API.

None of this makes RubyGems.org 100% safe, and I won’t pretend it does. Each of these fixes a specific weakness this incident exposed, and we’ll keep working on the rest. RubyGems.org is infrastructure that nearly every Ruby developer depends on, and keeping it secure is the core of what our team is here to do.

Colby Swandale, RubyGems.org Technical Lead

4.0.17 Released

2026-07-22T00:00:00+00:00

RubyGems 4.0.17 includes enhancements and bug fixes and Bundler 4.0.17 includes enhancements, bug fixes and documentation.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.17

RubyGems Release Notes

Enhancements:

Validate spec name before writing to the spec cache. Pull request #9690 by hsbt
Installs bundler 4.0.17 as a default gem.

Bug fixes:

Unquote Gem.ruby when spawning it as a separate argv element. Pull request #9695 by hsbt
Escape glob metacharacters in install paths when globbing. Pull request #9687 by hsbt
Preserve Windows editor paths in gem open and bundle open. Pull request #9694 by hsbt
Preserve Windows paths in MAKE and rake environment variables. Pull request #9693 by hsbt
Fix bundle binstub broken by gem update --system on Homebrew ruby. Pull request #9688 by hsbt

Bundler Release Notes

Enhancements:

Open compact index cache in binary mode when appending. Pull request #9679 by hsbt

Bug fixes:

Unquote Gem.ruby when spawning it as a separate argv element. Pull request #9695 by hsbt
Escape glob metacharacters in install paths when globbing. Pull request #9687 by hsbt
Avoid space-containing absolute path in RUBYOPT. Pull request #9696 by hsbt
Preserve the locked Bundler checksum when the gem isn’t cached. Pull request #9658 by rwstauner

Documentation:

Point Bundler gemspec metadata at the moved docs. Pull request #9648 by hsbt

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.17.tgz
5bbb245b7e7c1a01b1ef7fa95c35517ebf3be77815cbe3e63c97c3067b9a0d13
rubygems-4.0.17.zip
4f3cf8d8d2250be984f7ee4516b3138d82054db7ee759ec6fc6839f4557b464b
rubygems-update-4.0.17.gem
a3f458ae8fcf607602bb9ae111ac9a57036914c2e6bce7736418df504ec4e455

4.0.16 Released

2026-07-10T00:00:00+00:00

RubyGems 4.0.16 includes enhancements and bug fixes and Bundler 4.0.16 includes enhancements, bug fixes and documentation.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.16

RubyGems Release Notes

Enhancements:

Installs bundler 4.0.16 as a default gem.

Bug fixes:

Skip the make job server when using BSD make. Pull request #9676 by flavorjones

Bundler Release Notes

Enhancements:

Bundler: Fix Bundler::Fetcher for PQC support, adding integration connection tests. Pull request #9637 by junaruga
Reuse RubyGems’ vendored tsort in Bundler. Pull request #9647 by hsbt

Bug fixes:

Initialize the new gem’s git repo without a subshell. Pull request #9670 by hsbt
Preserve CRLF lockfile line endings on Windows. Pull request #9669 by hsbt
Fix the gemspec error snippet on Windows drive-letter paths. Pull request #9668 by hsbt

Documentation:

Point Bundler gemspec metadata at the moved docs. Pull request #9648 by hsbt

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.16.tgz
ea9c669526af82874f8f33f69bea1b6ddd99283756e598227a9a890035a5a06a
rubygems-4.0.16.zip
1c76924eddda3b1fe2922a2a9022eeee51706d31b5c0ed9e00c777c399e23e71
rubygems-update-4.0.16.gem
0475b0b254d46e5eeec1bfc2ef17fa0eaaf17ae561806b74652d1bffbef6ff8d

4.0.15 Released

2026-06-24T00:00:00+00:00

RubyGems 4.0.15 includes enhancements and bug fixes and Bundler 4.0.15 includes enhancements and bug fixes.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.15

RubyGems Release Notes

Enhancements:

Rubygems: Fix Gem::Request for PQC support, adding integration connection tests. Pull request #9615 by junaruga
Reduce peak memory usage of full index loading and bundle install. Pull request #9618 by hsbt
Installs bundler 4.0.15 as a default gem.

Bug fixes:

Forward security policy to old-format gems. Pull request #9611 by hsbt

Bundler Release Notes

Enhancements:

Resolve Git LFS files in git sources from the real remote. Pull request #9632 by hsbt
Suggest access issues, not only yanking, for missing locked gems. Pull request #9631 by hsbt
Implement a make jobserver (continuation of #9210). Pull request #9625 by hsbt
Reduce peak memory usage of full index loading and bundle install. Pull request #9618 by hsbt
Bump up to rb-sys 0.9.128. Pull request #9569 by hsbt

Bug fixes:

Skip the make jobserver on Windows. Pull request #9630 by hsbt
Don’t require source plugins to be installed to parse a lockfile: 4.0.x. Pull request #9621 by hsbt
Exempt lockfile versions from cooldown on every resolution path. Pull request #9619 by hsbt
Set Bundler.settings[:ssl_ca_cert] to download gems. Pull request #9610 by junaruga

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.15.tgz
ec63459a0746d6e33804c0d6cbbcd1bcc6359f44fcada267b0f489cc84083687
rubygems-4.0.15.zip
54e30f36e5dbf193e1abbb1d6f995a83d3f1bcab0ff4cfe21064c8a3cb9554ed
rubygems-update-4.0.15.gem
bb22f30d9172f4ecd646c2bc8de341a820814401bcada5d7c5c541bd63b8f427

4.0.14 Released

2026-06-10T00:00:00+00:00

RubyGems 4.0.14 includes enhancements and Bundler 4.0.14 includes bug fixes.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.14

RubyGems Release Notes

Enhancements:

Add executables and bindir validation to the gem installer. Pull request #9595 by hsbt
Strip C1 control characters from displayed gem text. Pull request #9597 by hsbt
Installs bundler 4.0.14 as a default gem.

Bundler Release Notes

Bug fixes:

Preserve per-source cooldown when converging sources from the lockfile. Pull request #9601 by bryanwoods
Don’t exclude the locked version from cooldown during bundle update. Pull request #9599 by hsbt

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.14.tgz
7cb03059c028d073dd1efab322dddd6fe9e1a5976e2d35a1806066e069588812
rubygems-4.0.14.zip
8d93b7b8371309b9e4fe4c8d4da5e8f1e41d3ec5dd60af57b953793a039d9ae5
rubygems-update-4.0.14.gem
11ad1d808025f191c9cdde38bfb96aec01c7b75746870fe396a3334bdc29d050

Cool down before you install: give new gems a few days to be vetted

2026-06-03T00:00:00+00:00

Most supply-chain attacks against RubyGems exploit a narrow window: an account is compromised, a malicious version ships, and any bundle install in the minutes that follow resolves straight to it. 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. Releases too new to have been scrutinized are passed over in favor of ones that have aged past the window.

The feature was designed in the open, drawing on how other ecosystems approach the same problem. It is opt-in, and complements rather than replaces existing defenses like mandatory 2FA and trusted publishing.

Cooldown reads the per-version created_at timestamp that rubygems.org’s v2 compact index now serves. A version whose source does not expose created_at, such as older gem servers, historical entries from before the v2 cutover, or private registries still on the v1 format, is treated as outside the window and stays resolvable. Cooldown never blocks resolution silently; it only holds back versions it can prove are too new.

Getting started

Cooldown ships in Bundler 4.0.13. If you are on an earlier release, update Bundler in place and pin the same version in your lockfile so the whole team moves together:

$ gem update --system          # or: gem install bundler -v 4.0.13
$ bundle update --bundler=4.0.13

Then declare a small cooldown on your source in the Gemfile. This is the right setup for most teams: it is committed alongside your code, so every developer and CI run enforce the same window with no extra setup.

source "https://rubygems.org", cooldown: 7

gem "rails"
gem "puma"

Cooldown takes effect during resolution. Run bundle install when there is no lockfile yet, or bundle update to re-resolve against it once a lockfile exists; an existing Gemfile.lock is always honored as-is, so adding a cooldown never disturbs versions you have already locked. Cooldown is unset by default, so a project without it keeps resolving to the newest versions.

That is all most projects need. The rest of this post covers the finer-grained controls.

Other ways to set it

Beyond the per-source keyword, the cooldown setting applies one value across every source, scoped per-project, globally, or through the environment:

$ bundle config set cooldown 7          # stored in .bundle/config for this project
$ bundle config set --global cooldown 7 # applies to every project for this user
$ BUNDLE_COOLDOWN=7 bundle install      # no lockfile yet, e.g. a fresh CI checkout
$ BUNDLE_COOLDOWN=7 bundle update       # re-resolve when a lockfile already exists

For a one-off run, pass --cooldown to install, update, add, or outdated:

$ bundle install --cooldown 7
$ bundle update --cooldown 7
$ bundle add rails --cooldown 7
$ bundle outdated --cooldown 7

When more than one of these is present, they resolve in a fixed order of precedence: command-line flag > configuration setting > per-source cooldown: in the Gemfile. A --cooldown flag overrides the cooldown setting (bundle config or BUNDLE_COOLDOWN), which in turn overrides a cooldown: declared on a source. The cooldown value is always a non-negative integer number of days; a string, float, negative number, or array is rejected with an InvalidOption error.

Mixing sources

Because the flag and the setting apply uniformly to every source, the per-source keyword is what you reach for when policy differs by registry, for instance cooling down public gems while trusting an internal registry you operate:

source "https://rubygems.org", cooldown: 7

source "https://gems.internal.example.com", cooldown: 0 do
  gem "internal-tool"
end

cooldown: 0 on the private source keeps it permanently exempt while public gems still age. Note that a command-line --cooldown N overrides every source for that run, including the exempt one.

The escape hatch

Passing 0 disables cooldown for the run. It is the reliable way to reach the newest version on demand and to override a per-source or configured cooldown. This matters most when waiting is the wrong default: a fix lands for an actively exploited 0-day, or a vulnerability disclosure tells you to upgrade immediately. In those cases the freshest release is exactly the one you want, and --cooldown 0 lets you take it without removing the policy for everyone else:

$ bundle install --cooldown 0
$ BUNDLE_COOLDOWN=0 bundle update rails   # ignore any configured cooldown this time

You will reach for this when every candidate version of a gem is still inside the window. Rather than fall back to a too-new release, Bundler stops, reports how many versions the cooldown excluded, and points you at --cooldown 0 to proceed.

Seeing what is held back

bundle outdated is cooldown-aware. It annotates versions that are newer but still inside the window with the days left before they become resolvable, so “up to date” stays distinct from “deliberately waiting”:

$ bundle outdated --cooldown 7
Gem             Current   Latest                  Requested   Groups
aws-partitions  1.1251.0  1.1256.0 (cooldown 3d)  = 1.1251.0  default

One layer among many

Cooldown is most useful as one part of the wider security investment happening on rubygems.org. The registry now validates gem contents at push time and checks logins against Have I Been Pwned so that compromised passwords cannot be reused, work described in Protecting rubygems.org from the outside in. A dedicated team is running AI-assisted vulnerability scanning against the most critical gems, backed by Alpha Omega and Anthropic, and the direction of all of this is tracked on a public roadmap. Trusted publishing and mandatory 2FA already raise the bar for who can push a release in the first place.

Cooldown itself only works because rubygems.org now publishes the per-version created_at timestamp through its v2 compact index (v2 is an internal format version, not a public API change), delivered through a careful dual-write migration and a flagged cutover with no disruption for clients. I’m grateful to the rubygems.org team for that groundwork. Cooldown is a thin client-side filter on top of it.

Each of these defenses covers a different gap, and they compound. Resolving your dependencies against rubygems.org is what puts all of them to work on your behalf, which makes it the safest default for Ruby projects.

4.0.13 Released

2026-06-03T00:00:00+00:00

RubyGems 4.0.13 includes enhancements and Bundler 4.0.13 includes enhancements, bug fixes and security.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.13

RubyGems Release Notes

Enhancements:

Prevent extraction from escaping destination_dir via pre-existing symlinks. Pull request #9493 by thesmartshadow
Close stdin immediately when using popen2e. Pull request #9540 by rwstauner
Fallback to copy symlinks on Windows. Pull request #9296 by larskanis
Installs bundler 4.0.13 as a default gem.

Bundler Release Notes

Enhancements:

Do not hard-code permissions for new gem directories during bundle install. Pull request #9557 by maxfelsher-cgi
Clear gem specification cache after acquiring process lock. Pull request #9310 by ngan
Show release date with bundle outdated. Pull request #9337 by hsbt

Bug fixes:

Apply cooldown to locally installed gem versions. Pull request #9582 by hsbt

Security:

Add cooldown to delay newly published gem. Pull request #9576 by hsbt. See Cool down before you install for what it does and how to turn it on.

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.13.tgz
91088b66de3e57b3865251610a06254e88f5cf268521cd9fd3c9559a33c5a567
rubygems-4.0.13.zip
7b9d20fec6503d738de6b954dbd506bc8ee9ff9266f47f6f382b60464033faa7
rubygems-update-4.0.13.gem
80dabc8ce1243c2d7c4b32f8898df56fc03db5f616ca1cb35bc5af5a8bf1a3e4

4.0.12 Released

2026-05-20T00:00:00+00:00

RubyGems 4.0.12 includes enhancements and bug fixes and Bundler 4.0.12 includes enhancements and bug fixes.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.12

RubyGems Release Notes

Enhancements:

Remove cygwin from WIN_PATTERNS. Pull request #9527 by fd00
Installs bundler 4.0.12 as a default gem.

Bug fixes:

Fall back to lockfile version when BUNDLE_VERSION is “lockfile”. Pull request #9545 by hsbt
Read BUNDLE_VERSION env var in BundlerVersionFinder. Pull request #9538 by hsbt

Bundler Release Notes

Enhancements:

Make bundle config get return status 1 when the value is not set. Pull request #9505 by willnet
Use Pathname#absolute?. Pull request #9529 by nobu
Deprecate parsing non-lockfile content in LockfileParser. Pull request #9502 by kurotaky
Print a warning for a potential confusion from the indirect dependencies. Pull request #5029 by junaruga
Respect Gemfile bundler setting in Bundler.setup. Pull request #4892 by godfat

Bug fixes:

Gracefully handle missing checksums in Compact Index. Pull request #9492 by jneen
Skip git source exclusion when lockfile cannot backfill. Pull request #9544 by yahonda
Fix bundle config gemfile unset behavior. Pull request #9514 by afurm

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.12.tgz
d4a125cb0df8afccda92c976b7170a977fccb3a133daa55ec45d681478912a50
rubygems-4.0.12.zip
5be0ec39295602e83b339b1a0326db1e383ea267594a9a3cd401f7aff06d5228
rubygems-update-4.0.12.gem
7ad8f633a3e4217b6c23455f22fd145a3c5434f8b3b49999a4fde6493318095e

4.0.11 Released

2026-04-30T00:00:00+00:00

RubyGems 4.0.11 includes enhancements and Bundler 4.0.11 includes enhancements, bug fixes and documentation.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.11

RubyGems Release Notes

Enhancements:

Add commented-out rubygems_mfa_required to bundle gem template. Pull request #9487 by MatheusRich
Clarify the name and meaning of the first argument to gem spec. Pull request #9476 by eregon
Installs bundler 4.0.11 as a default gem.

Bundler Release Notes

Enhancements:

Update gem creation guide URL to rubygems.org. Pull request #9500 by nissyi-gh
Lock the checksum of Bundler itself in the lockfile. Pull request #9366 by Edouard-chin

Bug fixes:

Fix installing gems with native extensions + transitive dependencies. Pull request #9477 by nicholasdower
Fix the bundler version not being updated in dev/test lockfile. Pull request #9463 by Edouard-chin
Ensure the release CI doesn’t break due to the Bundler checksum feature. Pull request #9436 by Edouard-chin

Documentation:

Fix formatting for BUNDLE_PREFER_PATCH variable in man page. Pull request #9474 by toy

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.11.tgz
95fe9d9d5293d022ceb29afac56eee4e2d46f901de309ab46915ff84d5ec68e8
rubygems-4.0.11.zip
1b5800bf8b94d0ac4027d71efe8eace3d1ec24442397731cd0c6b16ecfa30163
rubygems-update-4.0.11.gem
d851e6dfc3d1984952c1f6129798472baa899d3ad84ea9eb687cd1237b341068

Scaling Ruby's defenses with AI

2026-04-29T00:00:00+00:00

On April 23rd, we submitted a vulnerability report to the Nokogiri maintainers. It was the first one our team has filed using AI-assisted scanning. The maintainers accepted the report and published it as GHSA-c4rq-3m3g-8wgx.

The same week, news broke that Mythos, Anthropic’s most capable security model, had been accessed by unauthorized users through a third-party vendor. According to Anthropic, Mythos has identified thousands of zero-day vulnerabilities across every major operating system and web browser, including a 17-year-old remote code execution flaw in FreeBSD and a 27-year-old bug in OpenBSD. Two stories on the same shift, one from each side of it. The capability gap between attackers and defenders just widened, and most open source ecosystems have nothing to close it with.

Anthropic is bringing some open source maintainers into Project Glasswing. Ruby is on the list, and agreements signed, but the access is not live yet. We cannot afford to be on the wrong side of that gap.

We have been working on the defender side. RubyGems hosts roughly 190,000 gems, and you cannot audit them all. The OpenSSF Criticality Score lets us focus on the gems whose compromise would cascade through the rest of the ecosystem. We’re looking at those first.

We are using Claude Opus 4.7 to surface candidate vulnerabilities. A human reviewer triages, verifies, and writes up every finding before anything reaches a maintainer. None of this work happens without backing. Alpha Omega, a project of the OpenSSF at the Linux Foundation, is sponsoring this work. Anthropic is providing the model access we need to operate at the scale it needs.

The bug we found in Nokogiri is a regex backtracking pathology in the CSS tokenizer. A short, unterminated attribute selector could hang the Ruby process indefinitely because the tokenizer’s regex tries to interpret each escape sequence two different ways and explores an exponential number of possibilities before giving up. Every public Nokogiri CSS entry point routes through this tokenizer. Most large consumers (Rails, Capybara, Loofah) pass developer-written selectors and were unaffected. But any application that lets user input flow into a CSS selector (scrapers, feed readers) was exposed to an unauthenticated denial-of-service via a payload small enough to fit in a request parameter.

ReDoS bugs are a sweet spot for model-assisted finding. They are hard to spot by reading code and easy to verify by running them. Opus 4.7 flagged the ambiguous STRING rule in the CSS tokenizer and proposed a payload to exercise it: an unterminated attribute selector followed by a run of \a escape sequences. I ran it. Parsing took 6ms at fifteen escape sequences and timed out past five seconds at twenty-four. Each added escape roughly quadrupled the runtime, which is what catastrophic backtracking looks like. I wrote up the report. The Nokogiri maintainers accepted it, patched the bug, and published the advisory. The fix is in.

Open source maintainers are already drowning in AI-generated security reports that don’t hold up. Each one wastes a maintainer’s day and makes the next legitimate report harder to act on. We are not going to be part of that.

Opus 4.7 is the most capable model we have access to right now, and it produced a real advisory in one of the most widely used gems in the ecosystem. We are working with Anthropic to gain access to Mythos through Project Glasswing. We did not need to wait for it to find this bug, and we will not wait to find the next one.

RubyCentral is hiring a small team of security engineers to scale this work. The job is to run AI-assisted reviews against the most critical gems on rubygems.org, verify findings, and earn the kind of relationship with maintainers where an advisory from us is taken seriously and acted on quickly. If you have done open source security work in any ecosystem and want to do it at scale, we would like to hear from you. Please reach out to oss@rubycentral.org.

We submitted our first report on April 23rd. There are 190,000 more gems to look at.

Update, 30 April 2026: An earlier version of this post said “Ruby is not in yet” in reference to Project Glasswing. We have been invited into the program, but the access is not live yet. The line has been clarified to reflect that.

rubygems.org has a public roadmap

2026-04-15T00:00:00+00:00

rubygems.org has been a busy project. This past year we shipped formal policies for the first time in the registry’s history, launched the Organizations private beta, and made some meaningful security improvements to how gems get validated and how compromised passwords get caught. A lot of that work happened quietly. If you wanted to know where things were headed, you had to catch the right conference talk or subscribe to the right newsletter, and even then you’d only get pieces. The roadmap puts it in one place.

The roadmap covers work at different stages, from Organizations moving toward general availability to longer-horizon work on security tooling, gem archival, and acceptable use policies. The full list is on the board.

As the registry has grown, the stakes of each change have grown with it. Those changes ripple out to gem authors, client maintainers, and anyone who depends on the ecosystem being stable. Getting that right requires input from people outside the core team. Contributors from both the RubyGems client team and Shopify are already working with us on making native gems a better experience for the Ruby community. A public roadmap makes more of that possible.

If you see something on the roadmap that affects your work, leave a comment on the issue. If something’s missing that you think should be there, open an issue.

The roadmap is public now. We’re curious what the community does with it.

Protecting rubygems.org from the outside in: DoS prevention and compromised passwords

2026-04-09T00:00:00+00:00

Every gem published to rubygems.org ends up running on someone’s computer. It’s up to rubygems.org to ensure that each gem contains what it claims, that its metadata is well-formed, and that the person who pushed it is who they say they are.

We’ve been chipping away at that. Over the past few months, we shipped two changes that tighten rubygems.org’s defences at very different layers: stronger validation of gem contents at push time, and integration with Have I Been Pwned to catch compromised passwords at login.

What rubygems.org checks when you gem push

A RubyGem is actually just a regular tar file, which contains 3 sections: the code, metadata, and checksums, which you can inspect for yourself.

$ gem fetch rails
Fetching rails-8.1.3.gem
Downloaded rails-8.1.3

$ tar -xvf rails-8.1.3.gem
x metadata.gz
x data.tar.gz
x checksums.yaml.gz

rubygems.org closely inspects all 3 of these files when a gem is published, but the ones we’re looking at are the metadata and checksums.yaml.

The checksums.yaml certifies the integrity hash of the data.tar.gz and metadata.gz with a sha256 after gem build. If someone tampers with the code directly, the checksums won’t match and rubygems.org rejects the push immediately. Checksums are the easy part.

metadata.gz has the serialised YAML of the gem metadata, generated from the gemspec during gem build.

 --- !ruby/object:Gem::Specification
name: rails
version: !ruby/object:Gem::Version
  version: 8.1.3
platform: ruby
authors:
- David Heinemeier Hansson
bindir: bin
cert_chain: []
date: 1980-01-02 00:00:00.000000000 Z
dependencies:
- !ruby/object:Gem::Dependency
  name: activesupport
  requirement: !ruby/object:Gem::Requirement
    requirements:
    - - '='
      - !ruby/object:Gem::Version
        version: 8.1.3
  type: :runtime
  prerelease: false
  version_requirements: !ruby/object:Gem::Requirement
    requirements:
    - - '='
      - !ruby/object:Gem::Version
        version: 8.1.3
...

When a gem is pushed, rubygems.org deserialises the YAML and reconstructs a Gem::Specification object from it. It then validates the result, checking that the name and version are well-formed, that the declared dependencies are valid, that the person pushing is authorised. This is where gem validation gets complex.

Exploiting the validation process

This process of reconstructing the gemspec YAML into a Gem::Specification object invites a class of exploitation called insecure deserialisation that would allow a crafted YAML to attack rubygems.org.

This isn’t a theoretical concern. In 2017, a security researcher discovered that rubygems.org was using a bare YAML.load to deserialise checksums inside gem files, a vulnerability that had potentially been present since 2012. The team patched it within hours by switching to YAML.safe_load, which restricts which Ruby objects can be instantiated from a document. But that only narrowed the problem. Even with a precise allowlist of classes and objects, malicious gems could still exploit the deserialisation process to exhaust memory or CPU before any validation even ran, causing rubygems.org servers to stop working.

Validating gems without `Gem::Specification`

The fix was to stop trusting the YAML to tell rubygems.org what to do with itself.

This was largely Aaron Patterson’s (tenderlove) work. He designed and built the AST-based approach from the ground up. Rather than handing the document to Ruby and letting it materialise objects, we traverse the parsed tree ourselves and extract only the values we expect to find. The YAML never gets to decide what gets instantiated. We also validate the structure against a schema derived from the real thing: Aaron audited all 180,000 gems published on rubygems.org and built a tool to validate them against it. Some very old gems turned up edge cases we deliberately chose not to handle. If those gems were pushed today, they’d be rejected, but these gems that haven’t seen a new version in years almost certainly never will be. His contribution here is greatly appreciated.

The result is that an entire class of exploitation (using malformed metadata to attack the push endpoint itself) is no longer possible. The attack surface doesn’t exist anymore.

Compromised passwords and the supply chain

Gem validation protects rubygems.org from what gets pushed. But there’s a separate persistent threat: who’s doing the pushing.

Package registries are high-value targets for credential stuffing. If an attacker gets hold of a developer’s reused password from an unrelated breach, they can log in as that developer and push a malicious version of a legitimate gem. The code is signed by a trusted account. The checksums match. Everything looks right, because as far as rubygems.org can tell, it is.

Have I Been Pwned (HIBP) is a service run by security researcher Troy Hunt that tracks passwords exposed in known data breaches. At the time of writing, it contains over 10 billion compromised passwords. rubygems.org now checks against it at login, registration and password resets.

Checking passwords without exposing them

The obvious concern with checking your password against a third-party service is privacy. rubygems.org never sends your password, or even a full hash of it, to HIBP.

Instead, it uses HIBP’s k-anonymity model. When you log in, rubygems.org computes a SHA-1 hash of your password and sends only the first 5 characters of that hash to the HIBP API. HIBP returns a list of all hashed passwords in its database that start with those 5 characters. rubygems.org then checks that list locally. Your full password hash never leaves our servers.

If your password appears in the results, rubygems.org blocks the session and shows a warning explaining your password has been found in a known breach. You’ll need to reset your password before you can log in again.

Since shipping, it’s detected 1,166 accounts with compromised passwords. Because rubygems.org hashes passwords with bcrypt, we’ve never been able to inspect the strength of passwords in the database directly. This is the first real window into how widespread the problem is, and a way to start course correcting it.

Shipping the work

rubygems.org serves almost a billion gem downloads every single day. Every Ruby application, from side projects to the infrastructure powering large parts of the internet, depends on the integrity of what we distribute.

These two changes address the supply chain at different layers: one at the moment a gem is built and pushed, the other at the moment a person logs in. Neither is glamorous. Validating YAML ASTs and hashing password prefixes don’t ship in a splash announcement. But this is the work: closing specific, real attack vectors before someone finds them for you. If you want to follow along or get involved, everything happens in the open at github.com/rubygems/rubygems.org.

4.0.10 Released

2026-04-08T00:00:00+00:00

RubyGems 4.0.10 includes enhancements and bug fixes and Bundler 4.0.10 includes enhancements and bug fixes.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.10

RubyGems Release Notes

Enhancements:

Ignore warnings with spec different platforms. Pull request #8508 by hsbt
Better algorithm for sorting gem version. Pull request #9421 by Edouard-chin
Update SPDX license list as of 2026-02-20. Pull request #9434 by hsbt
Installs bundler 4.0.10 as a default gem.

Bug fixes:

Register native extension files in default spec map. Pull request #9431 by hsbt
Fix NoMethodError in Gem.try_activate when activation conflicts occur. Pull request #9404 by hsbt

Bundler Release Notes

Enhancements:

Ignore warnings with spec different platforms. Pull request #8508 by hsbt
Improve error message when current platform is not in lockfile. Pull request #9439 by 55728
Cache package version selection. Pull request #9410 by Edouard-chin
Check happy path first when comparing gem version. Pull request #9417 by Edouard-chin
[feature] default_cli_command for config what command bundler runs when no specific command is provided. Pull request #8886 by jonbarlo
Introduce a fast path for comparing Gem::Version. Pull request #9414 by Edouard-chin

Bug fixes:

Restore rb_sys dependency for Rust. Pull request #9416 by bangseongbeom

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.10.tgz
6a225b7a8883de45d90c9b3f7ee14391759b286030ba1d1d77588cd7282e6cc7
rubygems-4.0.10.zip
edbb019691ef32e5e086595f54e1bc24bcfe5b9fe77e27aa893c7c752ef190d9
rubygems-update-4.0.10.gem
bd9dcd20076e809467739c868df95bcd628744f63e3b63d9df169d6223dabf6d

Temporarily disabling language support on rubygems.org

2026-04-07T00:00:00+00:00

I’m one of the operators of rubygems.org. Here’s what’s been happening over the past week, and a temporary change we’re making as a result.

For the past seven days, rubygems.org has been under sustained bot traffic from many different sources scraping data from every published gem. The volume has been large enough to force the site offline while we respond. The bots are deliberately bypassing the Fastly cache, hitting our origin servers directly.

The primary target has been our language locale pages, the translated versions of rubygems.org. Unfortunately, the locale system wasn’t designed to cache easily through a CDN. To protect site stability, we’re temporarily disabling language support while we rearchitect how locale pages are cached.

We’ll restore language support as soon as we have caching in place that can handle this volume. Thank you for your patience.

P.S. if you need gem and version data for a project, we publish regular database exports at https://rubygems.org/pages/data. We strongly recommend using those instead of scraping rubygems.org directly.

4.0.9 Released

2026-03-25T00:00:00+00:00

RubyGems 4.0.9 includes enhancements, bug fixes and documentation and Bundler 4.0.9 includes enhancements and bug fixes.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.9

RubyGems Release Notes

Enhancements:

Fix: include owner role in gem owner. Pull request #9403 by gjtorikian
Installs bundler 4.0.9 as a default gem.

Bug fixes:

Fix: Ensure trailing slash is added to source URIs added via gem sources. Pull request #9055 by zirni

Documentation:

[DOC] Fix link. Pull request #9409 by BurdetteLamar

Bundler Release Notes

Enhancements:

Check the git version only once per bundle install. Pull request #9406 by Edouard-chin
Normalize the number of workers when performing parallel operations. Pull request #9400 by Edouard-chin
Add exponential backoff to bundler retries. Pull request #9163 by ChrisBr
Introduce a priority queue. Pull request #9389 by Edouard-chin
Split the download and install process of a gem. Pull request #9381 by Edouard-chin

Bug fixes:

Retry git fetch without –depth for dumb HTTP transport. Pull request #9405 by hsbt

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.9.tgz
39b1e2c878946e420116c3c26e4e708c0ddbdf7cd4a13c48dd0fc0774c7add8d
rubygems-4.0.9.zip
d77dfd4baabcdc5b0a268f79332239bbbe2647f78d40778c243beace61d856a6
rubygems-update-4.0.9.gem
e1c0b84abaf481a4e0553d666986156090399afcc099aa18cac6fabbddc45514

4.0.8 Released

2026-03-11T00:00:00+00:00

RubyGems 4.0.8 includes enhancements and documentation and Bundler 4.0.8 includes enhancements and bug fixes.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.8

RubyGems Release Notes

Enhancements:

Use JSON for cargo metadata parsing. Pull request #9373 by hsbt
Fix NameError in Gem::Request.get_proxy_from_env when requiring rubygems/request directly. Pull request #9362 by afurm
Installs bundler 4.0.8 as a default gem.

Documentation:

Unify Compact Index API naming. Pull request #9372 by simi

Bundler Release Notes

Enhancements:

Add a new Bundler config to control how many specs are fetched #9363
Restrict GitHub Actions workflow permissions for newgem #9361

Bug fixes:

Fix plugin new version not registering #9355

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.8.tgz
b18663def26384e467f2594bf27190c580771df0ca7ba444afa1d76609881813
rubygems-4.0.8.zip
205198b7513521d2ba358e6b4df88924601be89b329d2b49fc0c0f55e41b167b
rubygems-update-4.0.8.gem
3465eef02174a0bbad1f8d343eff67a33e7fc6eeb84cf69f1d1ca77ce565045c

4.0.7 Released

2026-02-25T00:00:00+00:00

RubyGems 4.0.7 includes enhancements and documentation and Bundler 4.0.7 includes enhancements, bug fixes and documentation.

To update to the latest RubyGems you can run:

gem update --system [--pre]

To update to the latest Bundler you can run:

gem install bundler [--pre]
bundle update --bundler=4.0.7

RubyGems Release Notes

Enhancements:

Add Gem.disable_system_update_message in setup.rb. Pull request #9020 by hyuraku
Print message when signing in with an existing API key. Pull request #9312 by hsbt
Installs bundler 4.0.7 as a default gem.

Documentation:

Document gemspecs must be deterministic. Pull request #9321 by fxn
Remove “##” from a comment to require. Pull request #9306 by tompng

Bundler Release Notes

Enhancements:

Don’t check whether a plugin needs to be installed: #9328
[rust gem] Major improvements for gem scaffolding (rebased) #8455
Fix(bundler): only preload git sources for requested groups #9234
Raise error when gem contains capital letters #5432

Bug fixes:

Fix Bundler crashing when it tries to install plugin: #9335
Run git operations in parallel (take 2): #9323
Add support for help flag in plugin commands #9263

Documentation:

[DOC] Fix link in Bundler #9315

Manual Installation

To install RubyGems by hand see the Download RubyGems page.

SHA256 Checksums:

rubygems-4.0.7.tgz
80578da300518eca7abebb4c89ad26e5751ac8a77919f246b4fed67609f919e3
rubygems-4.0.7.zip
e6c46b17a7495a8fdeef91de1bf76d225e0ec4f164e6b88ea5f38f43ca531ba8
rubygems-update-4.0.7.gem
273c1291b85cd5882b10242e3c8463995164bcb2d37c2a92347ecd04fa5ae99a

Organizations Private Beta

2026-02-16T00:00:00+00:00

We’re excited to announce that the Organizations feature for RubyGems.org has entered private beta!

A long time coming

We started the Organizations work back in 2024 as announced in our June 2024 RubyGems update, where we shared our plans to bring organization accounts, memberships, and more precise gem permission controls to the platform. Since then, the team has been steadily building out the feature from refactoring our permissions models to introducing ownership roles, building the organization onboarding experience, and updating our guides to cover how Organizations work. After more than a year of development, Organizations is ready for real-world feedback.

Join the Private Beta

While ready for testing, it’s not ready for general release. We’re still refining some workflows and welcome feedback on any gaps you encounter. After talking to our friends at PyPI, we know that a public rollout of a feature like this will not be trivial. Instead, we’re adding a limited number of private beta organizations to help us refine the feature. We’ve already onboarded four organizations, with another four accepted into the program.

We envision Organizations primarily serving publishers with extended teams who manage gem publishing workflows. We’re especially interested in organizations that approach publishing in unusual or non-standard ways as these edge cases will help us build a better feature for everyone. If you’re interested in participating, please complete our interest form to get started.

What’s Next

We’ll be iterating on the feature based on what we learn from beta participants. Our goal is to open Organizations to the broader community once we’re confident the experience is solid. As we don’t have an anticipated timeline, stay tuned for updates.