it looks like someone has tried to steal rubygems.org db and other credentials. bundle update is now dangerous because you might get trojaned files.

But don't applications have to explicitly install this gem? If not, then I am incorrect.

Qrush, one of the guys behind Rubygems tweeted that the credentials of every yml file ended up on pastie: https://twitter.com/qrush/status/296638346283868160

> Someone posted http://rubygems.org 's config/*.yml to pastie. Didn't include the S3 bucket secret key, but going to reset everything anyway.

We don't know the extent to which Rubygems was compromised yet. In a scenario like this, it's best to err on the safe side and avoid trusting the source for the time being.

I think you're right, the title is inaccurate.

Running `$ bundle update` will not inject this into your app.

You'd have to intentionally add `gem "exploit", "~> 22.31.31"` to your Gemfile.

Couldn't all gems fetched from Rubygems be infected?

Yes, but the attacker would need to inject code into every .gem file that's pushed to rubygems.org. Because that source code would be highly visible, it would be simple to figure out what they're trying to do.

A more hidden attempt would be to simply alter the existing .gem files on S3. Once they have the access tokens from the configuration YAML files, they can do that from anywhere, not just the rubygems.org host. That keeps their activity under the radar and is slightly harder to track.

In that case, only newly installed gems in your system that were uploaded to rubygems.org before this incident would be at risk. If you run bundle update and pull in gems built from today onward, there is not as much to worry about. If you're updating gems and the bundle is pulling in gems from a few days ago, then you are at high risk.

I'm not disputing anything here, but I just want to emphasize that if they have the S3 credentials, replacing any gem is trivial. And they wouldn't need to replace every gem. Picking the 10 most popular ones would have pretty big fallout.

And, if like most people you don't verify your installed gems (not that you really can if they're not signed), you're going to have a very bad day. The "tracking" aspect is a situation where it doesn't matter because at that point, you're hosed anyway.

Also, walking S3 is not particularly fast. So if the plan is to walk all gem files to verify them, expect that to take a while. Hopefully they have bucket logging enabled.