Hacker News Reader

Comment by josephlord | Hacker News Reader

All the RubyGems stuff is happening at a high rate and I understand that over 90% of the Gems are now verified and it looks like nothing was backdoored but I couldn't find a good summary of the current situation so I have a couple of questions.

1) Is it currently safe to "bundle update" and be confident that only verified Gems will be provided? I don't mind errors on any unverified ones but don't want to download them.

2) Is there a drop in replacement for RubyGems? The problems that have occurred this month would have been multiplied if RubyGems was unavailable at the time Rails had an apocalyptic bug.

View on HN

Pretty good breakdown going on here [1]. To be honest, while the chosen tool to provide the update is odd, it is one of the best post-mordems that I've seen and applaud the volunteers for taking it so seriously.

1. I wouldn't say so. Not until they're all the way through.

2. Not at the moment, but general guidance is that we should all have local gem repos that we maintain ourselves and only rely on external sources when needed. It is something I'm going to look into ASAP.

[1] https://docs.google.com/document/d/10tuM51VKRcSHJtUZotraMlrM...

It is extensive and up to date but it is lacking a brief status of the current situation and whether the site is safe to download from. The answer is currently "no", 90% safe is unsafe.

It's a shame that they seem to have put the service back up in an unsafe mode, I would have hoped that they could have quarantined the unverified Gems.

Edit: Looking at the status page the API is down so it can't be accessed from Bundler so they are doing it the good/safe way.

Regarding #2, you could use gems from the github repositories (just specify the tag) instead of relying on gems hosted on RubyGems.

Obviously then it is up to you to verify everything, including that you're using the right versions and what not.

Probably not safe enough as most of them probably list external dependencies that will fall back to rubygems.

Good point.

I'm not sure of the best way to go about it, but if all the dependency gems are also on Github, a script might be able to pull the SHAs from the right version of each dependency and return the proper entries for a Gemfile.

gemspecs/Gemfiles rarely list the gh repo, so you'll likely have to get it from a source which is probably rubygems. If it's compromised, they could update the gh repo location as well.

I guess, at least for the most common gems, there could be an independent list which maps gem names to their Github repos. Of course, that list would have to be trustworthy. It would be nice to solve that mapping problem anyway, because sometimes it's not entirely clear which Github repo is the official source for a project.

Reply on news.ycombinator.com