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

@dwradcliffe, @swalberg: I love the second idea of a cooling off period once a gem has been yanked before automatically releasing it... that would allow any critical gems to be exposed and fixed throughout most of the community while avoiding the needs and extra support requirements on the RubyGems team.

I'm strongly against the first step suggested. I still feel yanking any version of a gem is critical for security / mistake reasons (what if someone accidentally published a gem with their private key, granted it still needs replaced but they should also be able to yank it). Additionally, as a gem author, I really would prefer to be allowed to remove any / all of my gems from rubygems if I so desire. I don't see that ever happening, but I feel like publishing to RubyGems shouldn't give them the right to keep a copy and distribute it just because they want to. Granted, you could make that the case in the ToS, but I feel it's unnecessary if we gracefully solve this another way.

Good idea @swalberg, I've updated by comment above.

Can you watch the downloads trend? As long as there are X downloads per N time period the namespace remains locked. Once that drops below a certain threshold you add the cool down period of Y-days the open up the namespace.

@dwradcliffe I would only worry that a popular gem that is less than 1 month old that gets suddenly yanked would get its namespace grabbed. Option (ii) may be a better solution for all gems for overall safety.

Also, since this particular point hasn't been brought up, does RubyGems have a policy on "un-un-publishing" a gem? Can we get a clear policy in writing for the community one way or the other?

For the record, I'm strongly against un-un-publishing a gem, but if you are going to support that feature(?) then definitely get something in an official Terms of Service in writing to cover your butts. The RubyGems team is one of my favorites in this community and I want to make sure we keep you all protected legally with whatever decisions are reached through this discussion (which, by the way, thanks for having so openly!)

I believe the answer to that @stevenhaddox lies somewhere in how RubyGem decides handles "Code Commons". If half the community starts to falter because of a single library being unpublished I don't think we can honestly say that library isn't a part of a "de facto stdlib", regardless of what cruby & co. authorize.

As soon as we admit that there are just some libraries everyone needs to exist (through dependency chains as old as rubygems) we must take responsibility for those gems.

tl;dr: If RubyGems takes responsibility for a certain type of library, heavily depended upon, then while the author can unpublish the community has a right to ununpublish.

Note: This is my opinion, not RubyGems opinion.

@stevenhaddox We're working on finishing up the official policies

@pallan One a gem is yanked the downloads become unavailable, so we can't see download statistics.

For the record, I'm strongly against un-un-publishing a gem, but if you are going to support that feature(?) then definitely get something in an official Terms of Service in writing to cover your butts.

Most gems released to Rubygems.org will be under free software licenses, which grant the right to redistribute. The GPL, for example, gives an irrevocable right to redistribute verbatim copies of the work. When a gem version is yanked which is not under a free software license, well that's where things get interesting. Currently, I don't think Rubygems would have the legal grounds to un-unpublish that gem, since all rights would be retained by the copyright holder.

There seems to have been an older discussion on a Rubygems TOS. Worth putting into writing what will happen in a "kik wants the kik gem name" situation, since it appears to have happened before (something regarding Posterous linked in that thread, an old issue re: autotest, perhaps more).

I feel a simple, manual solution should be implemented at first - at least until we have a better idea of the problem's scope.

For example, a dead simple rule like "After a gem gets fully yanked, notify X and don't let anyone take over the namespace for Y days". Perhaps with some slight variation, depending on how old/popular the gem is.

See how it goes, then re-review the process in a while.

Also, I feel like it's worth a reminder that the best practice I've encountered in ruby world (as far I understand it) has always been to bundle package your gems to vendor/cache as part of your deployment process which helps prevent a lot of issues in production that I've seen some npm users having to deal with.

Realistically, if a Rubyist is deploying with bundle package, a gem yank shouldn't be a problem for a production app as long as there is no way to replace the gem namespace with malicious code before detection can be found. A 100 day namespace reservation policy (or even 30/60) should be adequate to expose huge issues with the gem being yanked and should also prevent malicious new gems from getting pushed into production environments while still giving adequate time to fix things in development before publishing again.

Granted, RubyGems probably needs to consider those not following best practices as well.

Most gems released to Rubygems.org will be under free software licenses, which grant the right to redistribute. The GPL, for example, gives an irrevocable right to redistribute verbatim copies of the work. When a gem version is yanked which is not under a free software license, well that's where things get interesting. Currently, I don't think Rubygems would have the legal grounds to un-unpublish that gem, since all rights would be retained by the copyright holder.

I strongly support adding a TOS which includes granting rubygems an irrevocable right to redistribute verbatim copies of the work. Having to figure out the licensing terms of how your gem dependencies—and your gem dependencies' dependencies—released their code, especially in the (presumably usual) case where the authors don't particular care about the details, isn't worth requiring developers to do. Especially when it only supports the "I'm taking all my toys and going home" use case.

I strongly support adding a TOS which includes granting rubygems an irrevocable right to redistribute verbatim copies of the work.

@mark: The problem with this scenario is that technically you've just voided the purpose of yanking a gem, period. RubyGems could republish a version of a gem with a security issue or a private key without your consent and there'd be no recourse. I'm not saying that shouldn't be an option, but there's more to the scenario than just "if they rage-quit." And describing rage-quit in legalese is a bit tricky as the policy has to be the same for a single gem vs. 100 by the same author. A user can technically rage-quit while owning only one gem, but how do you prove that's what happened?

RubyGems could republish a version of a gem with a security issue or a private key without your consent and there'd be no recourse.

If I didn't trust them not to do that, I wouldn't push a gem in the first place.

describing rage-quit in legalese is a bit tricky [...] how do you prove that's what happened?

Why would you need to describe rage quitting in legalese? If you grant rubygems an irrevocable right to redistribute your gem, they can choose whether to exercise that right or not. I have confidence that if I accidentally pushed my AWS private key into a gem, and yanked that gem, rubygems wouldn't distrubute it anymore. Granting them such a right doesn't mean that they can't have a "yank gem" feature, just that yanking a gem doesn't remove their legal right to publish the gem, and if it's necessary, they can re-publish it. Whether they do so or not is something that they can decide in a case-by-case basis.

@mark: That's great that trust them, but not everyone will. What if you had a following out with someone on the RubyGems team?

I'm saying that the policy will have to be the same for every gem and you can't easily specify scenarios (legally) like a rage-quit.

When I yank a gem I expect the code to be erased from RubyGems' S3 / servers currently (I'd like to hope they wouldn't keep a security risk gem or private code on their servers after it's been requested to pull it). The change you're suggesting would essentially require them to keep all versions of a gem ever published so they could have the ability to re-publish it (and still have authoritative knowledge it wasn't tampered with, I remember that being an issue a year or two ago too).

Also, I have no idea if the scenario above is what happens currently or not, just what I would think would happen from the exposure I have.

Update: It looks like the gem is yanked, but versioning is implemented in S3 in case something critical needs to be restored (as per the post Nick linked to earlier that I just read finally).

The change you're suggesting would essentially require them to keep all versions of a gem ever published so they could have the ability to re-publish it

What? No—reread the terms of the license:

The GPL, for example, gives an irrevocable right to redistribute verbatim copies of the work.

What this means is: you're granting them a right (to redistribute...), and you can't revoke that right. Once you publish the gem, you can't turn around and tell them that they can't. It makes no requirement of them; they can choose whether or not to redistribute, so long as they don't change it (verbatim copies).

@mark: Not all gems on RubyGems are GPL. There are copyrighted gems distributed through RubyGems still. Are your statements meant only for gems that are licensed under GPL, MIT, etc? If so that negates my counterpoints. I was referencing all gems of varying license types.

Anyway, I think I've voiced my opinion pretty loudly. I'll probably bow out now to avoid too much clutter from others who want to contribute. Sorry I spammed so much, that certainly wasn't my intent and thanks so much to everyone for sharing opinions and thoughts on this important topic (and esp. the RubyGems team for being so open and engaging on the matter).

I appreciate and love all that rubygems has done.

I think that the cooldown period is a great idea.

This is a bit off topic, but personally, I would suggest that people use a proxy in front of rubygems source if their business relies on a set of gems. There have been many cases where I had relied on a gem hosted on rubygems. The gem one day disappeared from a 'rage-quit' or other reason and I was left recreating the gem from scratch or finding an alternative solution. Since then I have started pointing all of my sources to a private geminabox host that I control. All of them gems I care about are stored there and uses rubygems as a fallback in the event that I do not currently have that gem/version. In the event that someone does yank a gem that I relied on, I still have a copy within my proxy. Not to mention that bundling is much faster since everything is happening within my local network instead of having to download similar sources; reducing load on rubygems.

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.

@grant-olson thanks for the clarification.

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)

Agreed. If we are to remain an ethical service I believe authors must have total control over their libraries.

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

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