6 ms·

When will people start signing their gems? And gem/bundler warn if the signature is not present or invalid?

mratzloff 14y ago
I'd wager that most gem developers don't understand how it works, and there are basically no resources out there on it. Here's the chapter on it in the RubyGems manual: http://docs.rubygems.org/read/chapter/21 http://docs.rubygems.org/read/chapter/21 And that's all that I can find. Try to find something else, like a blog tutorial.
- Xylakant 14y ago
  Even if most gem developers would understand, there's still a problem with the trust model: If you choose "high security", you cannot install a single gem without signature - so things won't work unless _all_ authors sign their gems. Gem signing would have to be a requirement, similar to packages on ubuntu's ppa. If you choose a lower security setting, a gem may just be repackaged and signed again by the attacker or the signature removed.
  - mratzloff 14y ago
    A solution that doesn't solve 100% of the problem is still not a bad solution. The most popular gems would all be signed, thereby dramatically reducing attack vectors.
    - Xylakant 14y ago
      No, as I said, this doesn't help. You would need to sign the most popular gems and all their dependencies and the dependencies dependencies. Given that a pretty much standard rails app can easily pull in hundred or more gems that's quite a bit of work. It's doable, but I only see that coming if for example rubygems requires a key and gem signatures. Then there's still the unsolved problem of providing key trust - the current implementation relies on self-signed certificates.
moe 14y ago
And gem/bundler warn if the signature is not present or invalid? The problem seems to be that work on the trust infrastructure has been dormant since 2011. The basic signing functionality is in place[1], but it's not enforced and consequently nobody is using it. I hope this event will remind the people in charge to finish what they started. Otherwise it's a matter of time until something Really Bad™ happens. The code underlying rubygems[.org] is the stuff nightmares are made of (Marshal...). [1] http://docs.rubygems.org/read/chapter/21 http://docs.rubygems.org/read/chapter/21
- davebuster 14y ago
  It is very possible that something Really Bad™ has already happened, and we don't know about it. If it were me, I wouldn't let it out that I had essentially an unlimited backdoor to every system that installs gems.
technomancy 14y ago
On a related note, we are working on adding this requirement to Clojars, the Clojure equivalent of Rubygems. It's a lot of work and requires significant community buy-in, but would really pay off in moments like these. https://groups.google.com/group/clojars-maintainers/browse_thread/thread/77c1cd77e478bb0f https://groups.google.com/group/clojars-maintainers/browse_t...
davebuster 14y ago
When rubygems.org requires signed gems by developers whose keys have been put into the approved keyring, and denying access to everyone else. Until then, nobody will bother.
lawrencepit 14y ago
Won't make a difference, it's possible to sign a gem with a metadata file that contains an exploit.
- jrochkind1 14y ago
  No, you miss the point. The idea is that if, say, Rails were signed, someone wiht an exploit couldn't attack rubygems to _modify rails_ without it being discovered, because they wouldn't be able to sign their modified rails. The point of signing gems is not that any signed gem is neccesarily trustworthy. It's that any signed gem is neccesarily what the signature owner distributed, and has not been modified by someone else since. But to make that so requires a bunch of things, it's not quite as simple as 'everyone just has to sign their gems'. But that's the idea.

I'd wager that most gem developers don't understand how it works, and there are basically no resources out there on it. Here's the chapter on it in the RubyGems manual: http://docs.rubygems.org/read/chapter/21 http://docs.rubygems.org/read/chapter/21 And that's all that I can find. Try to find something else, like a blog tutorial.

Xylakant 14y ago
Even if most gem developers would understand, there's still a problem with the trust model: If you choose "high security", you cannot install a single gem without signature - so things won't work unless _all_ authors sign their gems. Gem signing would have to be a requirement, similar to packages on ubuntu's ppa. If you choose a lower security setting, a gem may just be repackaged and signed again by the attacker or the signature removed.
- mratzloff 14y ago
  A solution that doesn't solve 100% of the problem is still not a bad solution. The most popular gems would all be signed, thereby dramatically reducing attack vectors.
  - Xylakant 14y ago
    No, as I said, this doesn't help. You would need to sign the most popular gems and all their dependencies and the dependencies dependencies. Given that a pretty much standard rails app can easily pull in hundred or more gems that's quite a bit of work. It's doable, but I only see that coming if for example rubygems requires a key and gem signatures. Then there's still the unsolved problem of providing key trust - the current implementation relies on self-signed certificates.

moe 14y ago

And gem/bundler warn if the signature is not present or invalid? The problem seems to be that work on the trust infrastructure has been dormant since 2011. The basic signing functionality is in place[1], but it's not enforced and consequently nobody is using it. I hope this event will remind the people in charge to finish what they started. Otherwise it's a matter of time until something Really Bad™ happens. The code underlying rubygems[.org] is the stuff nightmares are made of (Marshal...). [1] http://docs.rubygems.org/read/chapter/21 http://docs.rubygems.org/read/chapter/21

davebuster 14y ago
It is very possible that something Really Bad™ has already happened, and we don't know about it. If it were me, I wouldn't let it out that I had essentially an unlimited backdoor to every system that installs gems.

technomancy 14y ago

On a related note, we are working on adding this requirement to Clojars, the Clojure equivalent of Rubygems. It's a lot of work and requires significant community buy-in, but would really pay off in moments like these. https://groups.google.com/group/clojars-maintainers/browse_thread/thread/77c1cd77e478bb0f https://groups.google.com/group/clojars-maintainers/browse_t...

davebuster 14y ago

When rubygems.org requires signed gems by developers whose keys have been put into the approved keyring, and denying access to everyone else. Until then, nobody will bother.

lawrencepit 14y ago

Won't make a difference, it's possible to sign a gem with a metadata file that contains an exploit.

jrochkind1 14y ago
No, you miss the point. The idea is that if, say, Rails were signed, someone wiht an exploit couldn't attack rubygems to _modify rails_ without it being discovered, because they wouldn't be able to sign their modified rails. The point of signing gems is not that any signed gem is neccesarily trustworthy. It's that any signed gem is neccesarily what the signature owner distributed, and has not been modified by someone else since. But to make that so requires a bunch of things, it's not quite as simple as 'everyone just has to sign their gems'. But that's the idea.