Namespace policy on a package registry sounds like a dry administrative topic until a prominent project has its gem name squatted by an unrelated party, and then it becomes the most important thing in the world for the week it takes to resolve. RubyGems.org has operated with a first-come, first-served naming policy for most of its history, tempered by an ad-hoc reserved-names list and a manual dispute-resolution process. The policy has been updated several times over the years, most recently with clarifications in February 2024 that addressed how the registry handles inactive gems held by maintainers who have disappeared. This post walks through the current state of that policy, the corners where it creates friction, and what maintainers can do when they run into it.
The topic matters for supply-chain security because namespace control sits upstream of almost every other protection. If a malicious actor can register a name close to a popular gem, none of the downstream 2FA or signing controls do much to protect consumers who accidentally install the wrong thing.
What is on the reserved names list?
The reserved names list is maintained in a private Ruby Central repository, with entries added based on a mix of operator judgment and formal requests. The public part of the policy, documented on the RubyGems.org help pages, states that names are reserved when they match a trademark held by an organization that has communicated with the registry, when they match a core Ruby standard library module, or when they have been flagged as confusingly similar to an existing popular gem. In practice the third category is the one that generates disputes.
The list is estimated to contain about 2,100 reserved names as of early 2024, based on community reverse-engineering of the registration error messages. Attempting to register a name that hits the list returns a generic "this name is reserved" error. The registry does not publish the full list, which is a point of ongoing friction because legitimate maintainers sometimes discover the name they wanted is reserved only after investing time in their gem.
How does trademark enforcement work?
A trademark holder can file a dispute request through the RubyGems.org support channel, providing evidence of their mark and the gem name they want addressed. The policy requires the holder to be the registered owner of the trademark in at least one major jurisdiction, and to show that the current gem under that name is either unmaintained, actively infringing, or registered in bad faith. Bad faith is not precisely defined, which is deliberate because the registry needs discretion.
The turnaround on disputes has historically varied widely. A clean case with an obvious trademark match and an unmaintained gem typically resolves in 2 to 4 weeks. A contested case where the current maintainer pushes back, or where the mark holder does not have clean documentation, can drag on for months. The 2023 dispute over the elastic gem name, which was ultimately transferred to Elastic N.V. after a process that took about five months, was a public example. The previous owner had registered the gem in 2012 and published only one version but remained contactable, which complicated the case.
What about abandoned gems?
The February 2024 policy clarification addressed abandoned gems, which had been a persistent source of disputes. Under the new policy, a gem is considered abandoned if the most recent version is more than 5 years old, the gem has fewer than 10,000 total downloads, and the maintainer has not responded to three contact attempts over a 30-day window. If all three conditions are met, the name becomes eligible for reassignment through the normal dispute process.
The thresholds are deliberately conservative because the registry wants to avoid reassigning names that belong to niche but still-useful gems. A gem like net-ftp that is stable and rarely updated should not be eligible for reclaim just because it has not seen a release recently. The 10,000-download threshold filters out the hobby projects that were briefly pushed and forgotten, which make up the majority of the eligible-for-reclaim pool.
The community response to the policy has been mostly positive but with legitimate concerns about edge cases. A maintainer who has stepped away from open source but would return if their gem were under threat has no mechanism to register continued interest. The RubyGems.org team has committed to expanding the contact-attempt process to include public GitHub notifications in addition to email, which should catch a meaningful fraction of these edge cases.
Where does typosquat-adjacent naming fit in?
The reserved names list is only loosely connected to typosquat prevention. A name that is a visually confusable variant of a popular gem, rspec-mocks-helper versus the legitimate rspec-mocks, is not on the reserved list by default. The registry relies on reactive flagging from the community rather than proactive blocking. This is a policy choice that reflects the operational reality: maintaining a comprehensive list of every possible variant of every popular gem would require full-time staff that RubyGems.org does not have.
In practice, the flagging works well when a typosquat hits a gem popular enough to have an active community, but it breaks down for mid-popularity gems. The 2024 incident involving activerecord-postgres-adapter, which was squatting on activerecord-postgresql-adapter, was caught within 72 hours because Rails community members spotted it quickly. A similar squat on a less-trafficked gem could sit for months before being noticed. There is ongoing discussion about implementing automated Levenshtein-distance checks on new registrations, but the false-positive rate has made this hard to land.
What should maintainers do?
If you maintain a gem under a name that is important to your project or your organization's brand, there are several defensive moves. Register common typosquat variants yourself, even if you do not plan to publish to them. An empty namespace-owner gem that does nothing but claim the name is enough to block an attacker from doing the same. The common variants are well-known: swapping hyphens for underscores, adding or removing a trailing -rails or -ruby, pluralizing or singularizing the base name, and common misspellings. For a gem named foo-bar, the variants worth pre-registering are foo_bar, foobar, foo-bar-ruby, foo-bars, and a handful of single-character typos of the dominant words.
If you are an organization with a registered trademark that matches a gem name currently held by someone else, start the dispute process early. The timeline is long enough that waiting until you have shipped a product named after the gem will leave you with a messy release. A pre-emptive filing before your public launch gives you negotiating room.
If you are a consumer, the practical defense is to pin gem names explicitly in your Gemfile rather than relying on inferred names from application code. A gem "rspec-mocks" line is less susceptible to a confusing substitution than a dynamic lookup based on a string in your config. Combine this with SBOM-based monitoring that flags gems in your lockfile whose names are a short edit distance from a popular gem, which is a lightweight check that catches a meaningful fraction of typosquat exposure.
How does this compare to other registries?
Other package registries have moved in different directions on namespace policy. npm introduced scoped packages in 2014, which lets an organization claim a namespace prefix and register any name under it. PyPI does not have namespaces but has more proactive name-squatting prevention, with automated checks for common variants. Maven Central requires a reversed-domain-name prefix, which sidesteps the problem entirely by giving each group its own sub-namespace.
RubyGems.org has discussed scoped names several times, most recently in a 2023 RFC that ultimately did not land. The argument against is that retrofitting scoped names onto a registry with fifteen years of flat-namespace history creates migration complexity that outweighs the benefit. The argument for is that it is the only durable solution to the organizational-namespace problem. For now, the flat namespace with reactive dispute resolution is what the Ruby community has, and it is unlikely to change in the next couple of years.
How Safeguard Helps
Safeguard monitors your Gemfile.lock for gem names that are close variants of popular gems, flagging potential typosquat exposure before an install happens. We correlate gem ownership changes, new registrations of similar-named gems, and reserved-name policy events so your team has early warning of namespace-related supply-chain risk. When your organization's trademark is affected by a gem registration, we surface it alongside the standard dispute documentation so you can move quickly. The goal is to turn registry namespace policy from a reactive fire drill into a monitored, predictable part of your security posture.