@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.

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.

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.

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

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.

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.

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

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?

@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.

@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.

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?

@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 :)

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.

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.

@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.

What @dwradcliffe is suggesting in his second proposal sounds a lot like domain grace periods. This is a fairly defined space and would not be overly complex to implement - as opposed to defining a download threshold and tracking that, modifying the threshold etc. There probably isn't a need to reinvent the box, so a grace period sounds like a sane solution as long as its made abundantly obvious on the RubyGems page that it is in grace period.

@stevenhaddox Re: Signed Gems, user keys are trusted globally and authorization for a given key isn't tied to a given gem. A malicious user could just get you to trust their key for a different gem before uploading a compromised gem with a good signature from the wrong/invalid/new user.

For the record:

The Bundler team is actively working on a "local" gem server that can both host private gems and act as a pass-through cache for gems from other servers. It's called Gemstash, and you probably want to use it for production environments for speed reasons as well as giving you a copy of your dependencies that you control.

The problems with signed gems described by @grant-olson are some of the reasons that signed gems today are not really secure. :/ We plan to implement TUF on top of RubyGems in the future, and eventually deprecate the (not really secure) current gem signing system. In the meantime, treat signed gems with a large grain of salt.

@indirect: Not to get off-thread too much, but this is awesome. I missed the announcement on that and am glad to see this issue hasn't fallen to the wayside. Thanks for all you do (as always)!

@stevenhaddox:

Are your statements meant only for gems that are licensed under GPL, MIT, etc?

The opposite—as @nateberkopec pointed out, GPL already grants irrevocable rights. So if you release your Gem under GPL, you can't rescind that right. ("All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. [...] You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that..."). You can ask them not to distribute it anymore, and they can choose to not distribute it for any number of reasons, but you can't tell rubygems that they're not allowed to. Other licenses grant something similar; the left-pad package was distributed under WTFPL which states "You just DO WHAT THE FUCK YOU WANT TO", which pretty clearly allows NPM to ununpublish it.

What I'm advocating for is a rubygems TOS which explicitly grants rubygems an irrevocable right to distribute the source, in case it's released under a license which doesn't already grant that, or under no license at all. That way there's no question about whether a gem can be permanently yanked by an angry developer. This wouldn't preclude the existence of a "yank gem" feature; just that if rubygems feels it's more important for the gem to exist, they are licensed to release it anyway. But if you've released your gem under GPL, or MIT, or WTFPL, or probably most other open source licenses, then you've already granted them that permission.

@mark that's assuming that every gem pushed has an OSS license (they do
not) and the author intends it to be used publicly (not always the case!)
it would also mean that we would have explicit permission to republish
credentials, keys, etc that are pushed accidentally...which is one of the
main reasons "gem yank" exists.

I think if we were starting from scratch that kind of policy would be OK.
But given we have over a decade of gems, I don't feel comfortable with that
as the policy. In my opinion, authors own gems. Not the service.

(Our future policies should be clear about this: and please be aware this
is by no means a final decision, just my opinion)
On Thu, Mar 24, 2016 at 3:09 PM Mark Josef notifications@github.com wrote:

@stevenhaddox https://github.com/stevenhaddox:

Are your statements meant only for gems that are licensed under GPL, MIT,
etc?

The opposite—as @nateberkopec https://github.com/nateberkopec pointed
out, GPL already grants irrevocable rights. So if you release your Gem
under GPL, you can't rescind that right. ("All rights granted under this
License are granted for the term of copyright on the Program, and are
irrevocable provided the stated conditions are met. [...] You may convey
verbatim copies of the Program's source code as you receive it, in any
medium, provided that..."). You can ask them not to distribute it
anymore, and they can choose to not distribute it for any number of
reasons, but you can't tell rubygems that they're not allowed to.
Other licenses grant something similar; the left-pad package was
distributed under WTFPL which states "You just DO WHAT THE FUCK YOU WANT
TO", which pretty clearly allows NPM to ununpublish it.

What I'm advocating for is a rubygems TOS which explicitly grants rubygems
an irrevocable right to distribute the source, in case it's released under
a license which doesn't already grant that—or under no license at all. That
way there's no question about whether a gem can be permanently yanked by an
angry developer. This wouldn't preclude the existence of a "yank gem"
feature; just that if rubygems feels it's more important for the gem to
exist, they are licensed to release it anyway. But if you've released your
gem under GPL, or MIT, or WTFPL, or probably most other open source
licenses, then you've already granted them that permission.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1226 (comment)

@qrush:

that's assuming that every gem pushed has an OSS license (they do not)

If every gem pushed had an OSS license, then this whole conversation would be moot, since you would already be licensed to republish. Technically, gems that don't contain a license you don't have any right to publish at all.

and the author intends it to be used publicly (not always the case!)

Does rubygems have any way of indicating or enforcing that? I'm sure people do this, but if you don't want outsiders to have access to your source, releasing a gem seems like a really bad idea.

it would also mean that we would have explicit permission to republish credentials, keys, etc that are pushed accidentally

If a gem is GPL or MIT or (I assume) most other OSS licenses, you already have that explicit permission; thankfully you choose not to exercise that right, and I don't foresee that changing in the future.

In my opinion, authors own gems. Not the service.

This isn't an ownership issue, it's a "you've released this gem, now what does that mean?" I don't think holding gem authors to a set of expectations is unethical. Gem exists so people can share code with others; that shouldn't grant you the right to mess with their projects.

I think if we were starting from scratch that kind of policy would be OK.

Definitely putting in a TOS wouldn't affect any of the gems that are already out there, which means you're still open to this problem no matter what. Maybe a warning when you download an unlicensed or non-OSS gem to the effect of "the author of this gem can revoke permission at any point, do not depend on it"?

@krainboltgreene:

the "ownership" debate wasn't actually dealt with at all by this left-pad issue, since the author's library was MIT and also he gave complete permission up front to anyone wanting to fork & park

It was WTFPL: https://www.npmjs.com/package/left-pad, but point still stands. Had he released it under a restrictive license, or no license at all—and then not let someone else take ownership of it, then NPM would have been in an even bigger mess.

Is there an alternative solution where a gem's 'lineage', regardless of name, is published to rubygems and able to be accessed by other programs like bundler when they fetch info from rubygems. This can in turn warn a user on an operation like bundle update / bundle install that the gem occupying that name is not part of the gem-of-records lineage?

I think a solution like this could completely work around the authorship and rights issues others are bringing up and focus on the central danger, the potential for silent and malicious switching of a deep dependency.

npm has a published a new policy for dealing with "unpublish" events: http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy

I highlighted interesting parts:

If the version is less than 24 hours old, you can unpublish it. The package will be completely removed from the registry. No new packages can be published using the same name and version.

If the version is older than 24 hours, then the unpublish will fail, with a message to contact support@npmjs.com.

If you contact support, they will check to see if removing that version of your package would break any other installs. If so, we will not remove it. You’ll either have to transfer ownership of the package or reach out to the owners of dependent packages to change their dependency.

If every version of a package is removed, it will be replaced with a security placeholder package, so that the formerly used name will not be susceptible to malicious squatting.

If another member of the community wishes to publish a package with the same name as a security placeholder, they’ll need to contact support@npmjs.com. npm will determine whether to grant this request. (Generally, we will.)

I think the security placeholder is an interesting idea for "all versions yanked" scenario (if that's even a plausible scenario). It's the security angle, not really the "break the internet" angle.

I'm more interested in the 24-hour locking idea. Not because I think it's a good idea. I don't know the average Time-to-Yank but it's probably within 24 hours. I just think it's an interesting idea. It makes me want to work on the reverse dependency API to identify the most depended on gems and ensure that they:

• have licenses (hopefully "good" ones)
• are/should be signed
• etc.

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

I'd love to see this possible. My favourite pet peeve is the gem called
"configuration". :)

I'd love to be able to use my gems on rubygems.org but also call that
gem "configuration", as an option. The topnamespace also is module
Configuration. Obviously this can clash if someone else defines the
same name. But I don't even get to this step in the first place since
the name "configuration" is already blocked there. The workaround is
to simply rename the project, and call it otherwise - this is how I sort
of started to call some of my projects "_paradise" as suffix. Simply
because the name is pretty, and I can workaround this. :P (Like,
ftp_paradise, I actually had a shorter name in the past, similar for
other projects - nowadays I like this name anyway because it helps
me instantly identify what is "mine" :P; I also hate clogging up namespaces
for projects that I no longer use, so I once proposed to simply no longer
list projects that were all yanked by an author. If they are available by
someone else, that is fine by me, I just did not want to continue on
projects that I abandoned. Usually this meant that I would integrate that
project into another project by the way - I very rarely every throw away
code that has worked. But I do like to rename things when this seems to
make sense to me. )

I am not sure if this is solely a problem that rubygems alone can fix, since
require 'name' is a really trivial way to import something. But perhaps in
the upcoming ruby 3.x era, we can look at ways to integrate things better
and more flexible (if we host our projects all on github, and use bundler,
then we can freely use concurrent namespaces I think; but I am not
100% sure. I just remember that you can use bundler + github; in the old
days, you even could host gems on github too.)

I think one problem may be that ruby itself does not allow a more fine
grained control here.

For instance, if I do:

require 'configuration'

Then it will always look for the file configuration.rb first right? And
there can only ever be one file like that on a local filesystem.

What perhaps might work is an additional way to require or import
projects into another project.

Gemfiles have gem 'name','version-clause' I think.

Would be nice if we could specify something like that, perhaps on
a per-project basis instead. But as I wrote above, I think a part of
this problem is related to ruby itself. There even was a time without
any gems, so distributing has been harder back then.

I highlighted interesting parts:

The email requirement is really really really stupid. I don't understand it either.

If they get contacted, either they will:

(a) remove it after they were contacted anyway. In this case, why need a human interaction (provided that it is a human who reads anything and not just bots)

or

(b) not do anything, in which case YOU WASTED YOUR TIME CONTACTING THEM.

I feel that this is a huge failure on NPMs part and I hope that others don't follow this.

In my opinion, it seemed as if they did more PR cleanup after the breakup rather than
try to fix the issue that this can happen in the first place.

This is still a security concern for NPM, and it looks to still be one here too: https://github.com/npm/registry/issues/255

Given the security situation, why bother supporting the transfer of a gem name to a new owner? That use case implies a mentality of gem names being like a trademark or brand, but it seems more important for the identifier to have consistent semantics than to be catchy or descriptive.