Is allowing "gem yank" to free the gem namespace a security concern?

[nateberkopec]

Problem

Once you've yanked all versions of a gem the namespace is free for others to use. If you accidentally pushed the wrong name once yank it and it'll be free for others to use.

Yesterday, a programmer with over 200+ modules on npm yanked all of their modules from NPM, freeing the module namespaces.

The vast majority of those freed module names (most of which are very generic - names like alert and attr) have been claimed by a single person. I believe I know who this person is (they didn't really try to hide), and they do not appear to be affiliated in any way with NPM or the original author of these modules, Azer Koçulu. This name-claimer, ~nj48, has pushed new versions of all the affected modules, replacing their source code with what appear to be basically blank modules.

Of course, the question is, what if they hadn't pushed blank modules, and instead pushed things like rimrafall?

As far as I can tell, there is nothing stopping this scenario from occurring on Rubygems.org, either. Please correct me if I'm wrong. In fact, I think it's even worse with Rubygems.org - imagine the following scenario:

• Major gem author ragequits and yanks all version of all of their gems from Rubygems.org. Let's say the gem is called shmails. Let's say version 4.2.6 of this gem is the current version, and receives 1 million downloads per month.
• Anyone may now claim the shmails gem name. An attacker pushes a gem called shmails with the gemspec version of 4.2.6. This gem runs system("rm -rf /").
• What happens now?

EDIT: @qrush commented below that you couldn't re-push 4.2.6 in this scenario. You could push any version that hadn't already been pushed though, such as 4.2.7.

Solutions

I'm not sure. Author namespacing may help. rails becomes rails/rails, etc etc.

[evanphx]

@nateberkopec It's certainly a concern though in that case I think that the responsibility for the situation would lay with the ragequitter and the attacker. But thats not a satisfactory answer because the question is rather what can/should Rubygems.org do to mitigate that case.

The ragequitter has basically forfeit the name entirely even though he/she knows that the gem is heavily used. That person has already betrayed those users in my eyes. But again, opening up all potential users to an attack is equally horrible.

My feeling is that this case is almost too isolated and rare to develop policy around. Every time this would happen, it would be radically different than the previous time, so anything automated we put into place would either not catch it or would have been a constant source of pain for users (like never releasing gem names back).

The best case scenario would be an alert of some kind to the rubygems.org team to tell them that a gem has been forfeit. Then they could check what the ramifications of that might be.

[qrush]

Anyone may now claim the shmails gem name. An attacker pushes a gem called shmails with the gemspec version of 4.2.6

This isn't possible thanks to the way RubyGems.org is designed. Gem versions are immutable even after all versions are yanked.

I feel a heuristic should be interested to decide when a gem is "depended on" that is a mix of download count + number of dependencies. If that heuristic is true for a gem - then if all gem versions are yanked, "freeing" the namespace, then we won't allow pushing of any new versions.

We should do this as minimum for any stdlib ("blessed") gems, and any gems that are over several million downloads/critical to the Rails/Rack infrastructure.

[qrush]

Was reminded of this, too: Namespaces and subdomains have been proposed a few times. They didn't seem to have worked out. Lots of backstories here:

https://groups.google.com/forum/#!topic/rubygems-org/mER9nLiJito
#91
https://groups.google.com/forum/#!msg/rubygems-org/Srfo_mO0GrU/EqXC2IY3iAEJ
http://rubyforge.org/pipermail/rubygems-developers/2009-August/004897.html

Granted, this doesn't mean they aren't on the table. But it would be a big shift + a lot of work - more so than figuring out how to "bless" gems.

[evanphx]

namespaces fundamentally change how rubygems works so it's not really a change I want to do.

[nateberkopec]

npm has published their post-mortem.

There are technical and social aspects to this problem. Any reasonable course of action must address both of these.

We will make it harder to un-publish a version of a package if doing so would break other packages.

We are still fleshing out the technical details of how this will work. Like any registry change, we will of course take our time to consider and implement it with care.

We will make it harder to maliciously adopt an abandoned package name.

If a package with known dependents is completely unpublished, we’ll replace that package with a placeholder package that prevents immediate adoption of that name. It will still be possible to get the name of an abandoned package by contacting npm support.

We are updating our internal policies to help our team stay in sync and address community conflict more effectively.

[qrush]

Yesterday @drbrain floated the idea where we would require someone to contact us via help.rubygems.org to take over a gem that has been fully yanked.

Usually this happens anyway- someone wants to give a namespace over so we will add the new owner with their permission via the Help site. Of course, this would be less self service and be subject to the same delays our support queue has already (and historically our response time isn't stellar).

I think this approach requiring a human invention may be more time consuming but would guard better than a heuristic determining gem importance.

Overall I think the immutability of gems once pushed has been a boon for the community. Any policy that furthers that goal and also keeps malicious actors from pushing dangerous code into a previously safe/trusted gem namespace in the event of a mass deletion would be a good one.

[sgrif]

Is a gem being fully yanked and then transferred a common enough occurrence that the support burden is a major concern?

[stevenhaddox]

Just out of curiosity, say the Ruby community (or any Rubyist) started using signed gems, would a new author pushing a new version of a yanked gem install automatically through bundler or would the key changing to a new user's signature (or a lack of signature) prevent that gem from being installed?

[qrush]

@sgrif it's rare, but historically our response time can very from weeks to over a month.

@stevenhaddox I think signed gems is an orthogonal problem. As noted above gems are immutable, so it's not possible ever to overwrite a gem version.

[stevenhaddox]

@qrush: right, I meant more so would the removal of a signature or the changing of a signature from a new gem version (when one existed previously) cause the gem install process to fail automatically until the new signature (or lack thereof) was explicitly approved (in the current code base)? Sorry if I wasn't more clear about the scenario, definitely talking about a new version of a previously existing gem that's been yanked.

[derekprior]

Is prohibiting yanking all together something we should consider?

The problems that yanking solves seem to be:

1. Giving over ownership of of squatted/little-used gem name to someone else for a different project.
2. Pulling a release that ha drastic problems (security issue, bad release or something).
3. This relatively new "I quit and don't want anything I do associated with your package manager" phenomenon.

Are there any other use cases for yanking? are these all use cases we care to or even should support or should we take an immutable approach?

[stevenhaddox]

@derekprior: I'm a huge fan of being able to yank versions for security concerns and feel this supercedes any other issues that could occur as a result.

I'm also a huge fan of being able to remove my code from RubyGems should I ever want to quit. Just because it's OSS doesn't mean I necessarily want it published on RubyGems and I should be allowed to remove it as the author if I so choose. Also remember a lot of gems retain copyrights / IP while still publishing to RubyGems and I don't think RubyGems necessarily has the legal right to retain it should I change my mind about it existing there unless the ToS were updated to reflect that condition (I'm not sure if they read that way currently or not, but I'd discourage such a clause personally).

Just my thoughts as a regular developer :)

[qrush]

IMO removing yanking is not on the table. It's a community requested and vetted feature that we have iterated on over the years, most recently to add permadeletion and keep an audit trail.

[dwradcliffe]

I have two proposals:

• Gem yanks will only be allowed if the version has less than 15,000 downloads. This will allow relatively unused gems to be yanked freely, while popular gems will have a shorter period of time to realize they have a legit reason to yank. (We can iterate on this threshold if it is not quite right.)
  ​
• When a gem author yanks all versions of a gem, one of three things will happen:
  1. If the gem is less than a month old, we will open the namespace and allow anyone to claim the gem name. (This is what happens for all gems now.)
  2. If the gem is more than a month old, we will lock the namespace and prevent anyone from pushing any versions for 100 days. We will display a message on the website informing users that this gem name might be available, but they will need to contact support for assistance. We can then verify on a case by case basis.
  3. After 100 days, this namespace will become available. This should be enough time for the community to realize something has happened and we can step in and fix it. Or it is not a problem and someone else can have the gem name.

[swalberg]

@dwradcliffe Rather than requiring operator intervention to take over a namespace that's been abandoned, what about an N-day waiting period? It would give people who use it a chance to raise it as a problem, and if the waiting period expires, it was probably not a well used gem anyway.