Bad gems are still up on rubygems.org (invalid gemspec for clamp....")

[jordansissel]

An fpm user on IRC reported: "hm, just did a fresh gem install fpm on this ubuntu vm and I'm getting an invalid gemspec for clamp, invalid date format"

I know I've filed about this before, and the particular problem is fixed only in certain cases. The problem still exists in a very common case described below:

• The user has an older version of rubygems (say, the default ruby 1.8.7, rubygems 1.7.2 on Ubuntu 11.10)
• The user installs a gem that was built with a broken version of rubygems (ones causing the date or yaml problems)
• The user now gets a warning for every rubygems-using ruby invocation

Here are my proposed fixes, each are independent and complete and do not require the other proposals. These proposals below are not necessarily ones I would prefer, but are simply ideas I had:

Proposal #1: Patch all the rubygems published on rubygems.org that are currently observed as broken-after-install.
Proposal #2: Yank all bad versions of gems on rubygems.org and notify authors about it.

I understand that these perhaps sound a bit extreme - going in and patch every gem on rubygems.org which broken in the way described above. I am willing to help write the code that does this should the proposal be accepted.

[jordansissel]

The situation I am trying to resolve is having users report this exact same problem for the next 2 to 6 years (depending on which distro they are using, how frequently they upgrade, etc) without any ability on my end (or theirs, probably) to resolve it.

[evanphx]

Proposal #1 is much more likely to happen, there are a few ramifications:

The gemspecs are located in 2 places: the gemspec.rz file and within the .gem itself. Fixing the gemspec.rz file isn't too big of a deal, since it's basically a cache that we are free to manipulate. But the fixing the spec in the .gem file means manipulating the .gem itself. If we're comfortable altering .gem files, then that seems like the way to go, but we need to all decide that doing so is ok first.

[jordansissel]

Also, I think proposal 1 should extend to also modifying the 'gem push' intake process to fix (or reject) gems as they are published because lots of developers are still using bad versions of rubygems to buildand publish their gems.

[drbrain]

I agree with rejecting gems that contain incompatible YAML in their specs at push time. An easy way to do this would be to ensure the User-Agent is appropriately modern.

For proposal 1, we can only fix unsigned gems, so we'd need to have a way of notifying authors that their gem is broken. I think 1 is otherwise fine.

Do we have an idea of how many broken gems exist? Performing 2 or notifying authors of signed gems for older versions seems counterproductive, I am worried too many authors would ignore the message.

I think a better way to perform 2 would be to notify authors and yank the gem if the author does not post an update after a reasonable time period (and possibly only for older, unpopular gems). We'll need to lay some groundwork for 2 as there's a high probability of negative feedback.

[evanphx]

I think based on the fact that signing is not in wide usage, it's easy for us to put this in place now. Because we've now got a good handle on the problem, we can simply reject bad signed gems as well.

In order to ease this into place, I'd prefer to not reject bad gems on push, but instead fix their specs and inject the corrected spec into the .gem file. If we start rejecting gems on push, that will create a big support workload.

I'd like to reject gems eventually, but we should clearly communicate to the community when that will begin and what they need to do to make sure they're not subject to it.

[jordansissel]

I don't know how many gems are broken, but that shouldn't be too hard to figure out. I'll bring up a gem mirror of rubygems and see about doing that math.

[evanphx]

Check out the guantlet gem that Ryan Davis wrote. It's what you'll want to use to find out.

Evan Phoenix // evan@phx.io

On Wednesday, March 21, 2012 at 2:25 PM, Jordan Sissel wrote:

I don't know how many gems are broken, but that shouldn't be too hard to figure out. I'll bring up a gem mirror of rubygems and see about doing that math.

---

Reply to this email directly or view it on GitHub:
#302 (comment)

[drbrain]

No updates in 6 months, it must not be very important. Please reopen if this is still an issue.