5 ms·

A Practical Guide to Using Signed Ruby Gems - Part 1: Bundler

29 points by bradleybuda 14y ago

bradleybuda 14y ago
The bundler_signature_check code that accompanies the article is available on Github: https://github.com/bradleybuda/bundler_signature_check https://github.com/bradleybuda/bundler_signature_check
hakaaaaak 14y ago
imo, the only way to make this work is going to be to force it, and boy are you going to make a lot of people very unhappy if that happens.
- borisjabes 14y ago
  The eternal dilemma. It will be interesting to see where the community goes on this. Peer pressure can go a long way!
- yxhuvud 14y ago
  Does anyone know how CPAN handles this?
- crazydiamond 14y ago
  Why are people going to be unhappy? Users or creators ? Will gem creation time significantly increase ? Will gem install time significantly increase ?
crazydiamond 14y ago
So how do we sign our gems ?
- potshot 14y ago
  RubyGems has a guide: http://docs.rubygems.org/read/chapter/21 http://docs.rubygems.org/read/chapter/21
  - scraplab 14y ago
    This guide also talks a little more about the trust model behind it, which is interesting. It sounds like it might be slightly out of date though, as it refers to the author as having just landed the patch, which happened 8 years ago.
- bradleybuda 14y ago
  I'm going to go through that in part 2 (part 1 was getting a little long already) - but the guide that potshot linked to is a good start - it's easy to understand and correct.
stormbrew 14y ago
As a meantime thing, since getting gems properly signed is probably going to take a while, it might be nice if bundler could at least recognize if a gem downloaded after being added to the Gemfile.lock had changed. A hash of the .gem file or the git head sha and an alert if it doesn't match the lock's stored hash would go a long way to at least detecting that a breach may have happened. Basically ssh's known_hosts for packages.
- derefr 14y ago
  Or, more generally: sign gems with a PGP public key (not a signing certificate); and then, while generating a Gemfile.lock, also store the key fingerprints for each gem in a "Gemfile.keys" or somesuch. Thereafter, disallow re-bundling if Gemfile.keys exists and any of the fingerprints don't match the new ones (and make sure to ping the keyserver to check key revocation, too.) When bundling fails, head out to Google to see if something happened (in other words, pay manual attention), and then, if it was just a revocation and they switched to a new key because of a breach or something, delete your Gemfile.keys and let it get regenerated. But really now: why is everyone so intent on centralized CA-based signing, when you don't even know 99% of the time who made the thing in the first place, but only care that it's the same person who made the ones before it?
  - bradleybuda 14y ago
    One interesting thing I've learned about most rubygems keys is they don't have chains back to CAs - they tend to be self-signed, and the docs encourage this. In fact, AFAICT there aren't any default trusted CAs for rubygems (unlike, say, the list your browser or OS has) - every signer has to be trusted manually with `gem cert --add`. So you end up with a PGP-like trust model on top of X.509 certs. I don't know exactly what this rationale was behind this model - I plan to explore this further in subsequent posts. I'm a relative neophyte to code signing - part of the reason I'm writing these posts is to teach myself how things work.
    - kgo 14y ago
      Basically because a proper X.509 implementation requires a CA to be in place first, so you have a place to submit a CSR, but there is no CA, so you're forced to self sign. I've written a rant on the topic here: http://www.rubygems-openpgp-ca.org/blog/gem-signing-x509-and-openpgp.html http://www.rubygems-openpgp-ca.org/blog/gem-signing-x509-and... I've been trying to get people to sign with OpenPGP because that can be done first and then you can put an authentication system into place after the fact. You can't do this with X.509, if/when a CA comes into play all gems would need to be resigned and republished.
crazydiamond 14y ago
Do other languages such as python, perl or lua etc have a signing facility ?

29 points by bradleybuda 14y ago

The bundler_signature_check code that accompanies the article is available on Github: https://github.com/bradleybuda/bundler_signature_check https://github.com/bradleybuda/bundler_signature_check

hakaaaaak 14y ago

imo, the only way to make this work is going to be to force it, and boy are you going to make a lot of people very unhappy if that happens.

borisjabes 14y ago
The eternal dilemma. It will be interesting to see where the community goes on this. Peer pressure can go a long way!
yxhuvud 14y ago
Does anyone know how CPAN handles this?
crazydiamond 14y ago
Why are people going to be unhappy? Users or creators ? Will gem creation time significantly increase ? Will gem install time significantly increase ?

crazydiamond 14y ago

So how do we sign our gems ?

potshot 14y ago
RubyGems has a guide: http://docs.rubygems.org/read/chapter/21 http://docs.rubygems.org/read/chapter/21
- scraplab 14y ago
  This guide also talks a little more about the trust model behind it, which is interesting. It sounds like it might be slightly out of date though, as it refers to the author as having just landed the patch, which happened 8 years ago.
bradleybuda 14y ago
I'm going to go through that in part 2 (part 1 was getting a little long already) - but the guide that potshot linked to is a good start - it's easy to understand and correct.

stormbrew 14y ago

As a meantime thing, since getting gems properly signed is probably going to take a while, it might be nice if bundler could at least recognize if a gem downloaded after being added to the Gemfile.lock had changed. A hash of the .gem file or the git head sha and an alert if it doesn't match the lock's stored hash would go a long way to at least detecting that a breach may have happened. Basically ssh's known_hosts for packages.

derefr 14y ago
Or, more generally: sign gems with a PGP public key (not a signing certificate); and then, while generating a Gemfile.lock, also store the key fingerprints for each gem in a "Gemfile.keys" or somesuch. Thereafter, disallow re-bundling if Gemfile.keys exists and any of the fingerprints don't match the new ones (and make sure to ping the keyserver to check key revocation, too.) When bundling fails, head out to Google to see if something happened (in other words, pay manual attention), and then, if it was just a revocation and they switched to a new key because of a breach or something, delete your Gemfile.keys and let it get regenerated. But really now: why is everyone so intent on centralized CA-based signing, when you don't even know 99% of the time who made the thing in the first place, but only care that it's the same person who made the ones before it?
- bradleybuda 14y ago
  One interesting thing I've learned about most rubygems keys is they don't have chains back to CAs - they tend to be self-signed, and the docs encourage this. In fact, AFAICT there aren't any default trusted CAs for rubygems (unlike, say, the list your browser or OS has) - every signer has to be trusted manually with `gem cert --add`. So you end up with a PGP-like trust model on top of X.509 certs. I don't know exactly what this rationale was behind this model - I plan to explore this further in subsequent posts. I'm a relative neophyte to code signing - part of the reason I'm writing these posts is to teach myself how things work.
  - kgo 14y ago
    Basically because a proper X.509 implementation requires a CA to be in place first, so you have a place to submit a CSR, but there is no CA, so you're forced to self sign. I've written a rant on the topic here: http://www.rubygems-openpgp-ca.org/blog/gem-signing-x509-and-openpgp.html http://www.rubygems-openpgp-ca.org/blog/gem-signing-x509-and... I've been trying to get people to sign with OpenPGP because that can be done first and then you can put an authentication system into place after the fact. You can't do this with X.509, if/when a CA comes into play all gems would need to be resigned and republished.

crazydiamond 14y ago

Do other languages such as python, perl or lua etc have a signing facility ?