rubygems.org
rubygems.org copied to clipboard
rubygems
List of gems we need to request for yanking
Some operating systems may have case insensitive filesystem. Following gems are ordered by number of downloads of their counter part having number of downloads > 100_000. I have excluded gems where owners were same.
- [ ] rack: Rack
- [ ] websocket: WEBSocket
- [ ] rvm: rVM
- [ ] macaddr: MACAddr
- [ ] Platform: platform
- [ ] jruby-openssl: JRuby-OpenSSL (probably same owner)
- [ ] flipper: Flipper
- [ ] writeexcel: WriteExcel
- [ ] Saikuro: saikuro
- [ ] O_o: O_O
- [ ] GeoRuby: georuby
- [ ] RubyApp: rubyapp
- [ ] gdata: GData
- [ ] opal: Opal
- [ ] XMLCanonicalizer: xmlcanonicalizer (Downloads in same range)
- [ ] Selenium: selenium (Downloads in same range)
- [ ] base62: Base62
- [ ] SQS: sqs
As you would go down the list mentioned above, it becomes unclear whether any action is needed at all. For ex: Cases where there has been no active development on either of gems for years.
You can find complete list of 183 gems here.
Some blacklisted gems/namespace exist on rubygems.org. Probably because gem was pushed before the namespace was blacklisted. coverage digest english etc expect fiber logger matrix monitor observer prettyprint prime profile profiler ruby sync thread timeout un webrick
I noticed this is quite an old conversation. What is the goal of this issue?
Are you trying to determine a game plan? Or looking for help on people to do the leg work? Or just trying to figure out if this is an attack vector/issue that we even care about?
Many of the gems listed above like prime, timeout and JRuby-OpenSSL are from recognizable people. (I just randomly clicked on a few) So mentioning it to them looks like it could quickly remove a few.
Has someone reached out the authors of the conflicting gems where the authors are the same? Are you looking for volunteers for this part of the effort?
The options that I see are:
- ask the author to yank the gem (and possibly push with a different name - but probably not)
- just drop/yank the gem ourselves
- merge the gems (not sure if this is viable)
When looking I also noticed the user name namespace on a few of these gems (saikuro). I remember why we ended up there, but sure wish we could drop a bunch of these. But again, that changes this into a much larger project.
My initial thought was if it is old, just drop the gem.
But clicking on one of the gems on the list, I noticed that it relied upon riot (from 2013) - but reverse dependency on that shows rabl (from 2022). So while riot is "old", it looks like someone is using it. So my initial though on using date to determine relevance is flawed. I think you alluded to this.
We have a wonderful community. Any time I have had a gem that I needed but was rotting, I just reached out to the author and they worked with me to revive it and just take the keys. (I won't pretend that some haven't rotted under my stewardship either)
Feels like many of the entries in this list could handles with a couple of emails. Just curious what the possible action items are so everyone is on the same page
@kbrock the list at https://github.com/rubygems/rubygems.org/issues/1356#issuecomment-253784132is outdated, a lot of stdlibs were gemified and properly pushed.
I can't remember, do the database dumps have the userid list of owners in them? And some form of download information besides counts (like the date of last download)?
feel like grouping the owners together and hitting the popular contributors could solve this. (or maybe it was already solved?)
I can't remember, do the database dumps have the userid list of owners in them? And some form of download information besides counts (like the date of last download)?
feel like grouping the owners together and hitting the popular contributors could solve this. (or maybe it was already solved?)
this is the logic behind dump - it exposes only listed tables
https://github.com/rubygems/rubygems.org-db-backups/blob/ca66539b93c92c0f43f1416dfb8d4abfae4c6902/config/public_postgresql.rb#L19