5 ms·

Is there anything gem authors should be doing?

by adelevie 14y ago

timdorr 14y ago
Sign your gems before pushing them: http://docs.rubygems.org/read/chapter/21 http://docs.rubygems.org/read/chapter/21
- kgo 14y ago
  The trouble is self-signed X.509 certificates are pretty worthless. X.509 certs are built around the concept that they're issued by a trusted provider. I tried to get together a proposal to introduce OpenPGP signed gems and wrote some proof-of-concept code so there could be a proper Web-of-Trust for rubygems: https://github.com/grant-olson/rubygems-openpgp https://github.com/grant-olson/rubygems-openpgp But the developers were resistant (and understandably so) to having gpg as a dependency for gem verification, and I didn't trust myself to write the crypto and a decent keyring validation algorithm from scratch.
  - Xylakant 14y ago
    Even with pgp you'd need a whole lot of infrastructure. Where to get the public key from etc. Ubuntu requires pgp keys for their ppa and provides a keyserver. Since a lot of gems seem to use github nowadays, maybe an option to provide a pgp key on github would be great. That would allow to trust at least the most interesting projects - rails, db-layers, rack, etc. which could limit the fallout of an attack against rubygems.org
    - kgo 14y ago
      My proposal was that rubygems would create a simulated certificate authority that operates similarly to the PGP Global Directory, which would allow registered users to have their keys signed by an authorized RubyGems.org signing key. (This is covered on the bottom of the page on the link above.) In addition more active developers who go to conferences and what not would do all the proper WoT stuff to ensure that the RubyGems.org key being used was indeed the authentic one, and that gems in their circle of friends/co-workers were signed by the correct keys.
      - Xylakant 14y ago
        Yes, in general I think the proposal is sound. I just wanted to add that GH might be in a position to add "trust" quickly since the accounts already contain a little bit of information. Many people there have a paid account and so are at least known by credit card. It's not much and by no means perfect, but it's more than we have now.
  - moe 14y ago
    The trouble is self-signed X.509 certificates are pretty worthless. I disagree. If you obtain the public key from a second location that is not rubygems.org (e.g. from gem.homepage) then that raises the bar for a potential attacker. He now has to either compromise two sites in order to inject a malicious gem, or trick you into obtaining the public_key from a forged location. I hope 'bundler' and 'gem' hear the wakeup-call and will start displaying a visible warning on unsigned gems (please also print the homepage-url to make it less of a pain for the user to hunt down the public key). After a grace period the default should be switched to -P HighSecurity (reject unsigned gems). Yes, it's is not perfect, users may still import keys without thoroughly checking that the source is legit. However, it'll be a huge improvement over what we have now and greatly reduce the chance of a compromised gem to go unnoticed.
    - kgo 14y ago
      Point taken, but my day-job rails project, which isn't even that big, has 461 gems in my Gemfile.lock. (which lists all the explicitly included gems, as well as their dependencies, if you're not familiar.) That is a lot of self-signed certificates to track down, attempt some form of verification, and manually add as trusted. My proposal would allow people who want a medium-level of security to verify that whoever uploaded the gem has (1) valid credentials to rubygems.org, and (2) control of the account owner's email, without requiring all that manual installation. And it would allow people who wanted to set higher standards of verification to do so, basically for free, by configuring their settings in gpg.
      - moe 14y ago
        I think your approach is problematic because it hinges on the integrity of rubygems.org (the very host that is compromised right now). I do see your concern about having a large number of gems, but I believe that is a bootstrapping problem which could be relatively easily mitigated. Trusted entities (rubygems team, 37signals etc.) could publish signed versions of their keyrings, i.e. public_keys that they trust. So, if you trust 37signals, you'd just download their ring, validate their signature, and import it. And that will probably cover most of your 400 gems.
  - tptacek 14y ago
    You can deploy X.509 in the same configurations as you can OpenPGP; X.509 is just a certificate encoding format, and the semantics are up to the application . Ruby has better support for X.509 PKI than it does for OpenPGP, so using OpenPGP seems kind of silly in this case.
    - kgo 14y ago
      Yep, you can do WoT with X.509 if you write the semantics from scratch, and you can also do a CA approach with OpenPGP. The thing is, for years no-one has stepped in and actually gone through the pesky little details of implementing all those semantics for rubygems via X.509 even though it's come up repeatedly. But maybe someday some expert will come along and fix things. If you actually read the rubygems documentation on signing gems, it's pretty much "Okay generate your own self-signed key, then sign it with your self-signed key." That leaves a lot to be desired vs best practices. There isn't even an attempt to describe how you get your self-signed keys to users. I just think leveraging the existing OpenPGP semantics, ecosystem, and battle-hardened gnupg codebase, is a lot easier than implementing an entire system from scratch on X.509 just because openssl is already installed everywhere and ruby has better bindings and gnupg is not and does not. I'm just trying to take the approach you usually preach: Don't roll your own crypto code and leave the real work to the pros, and it seems like gpg offers a lower path of resistance.
      - tptacek 14y ago
        Using OpenPGP is a bad idea here. All the mainstream rubies have access to high-quality X.509 in their mainline distros without a third-party gem. Both OpenPGP and X.509 are going to require a little of fiddley semantic details that will take time to hash out. The bottleneck here isn't the technology. I like, and routinely recommend, OpenPGP for solving app crypto problems. X.509 makes a lot more sense here.

Is there anything gem authors should be doing?

timdorr 14y ago

Sign your gems before pushing them: http://docs.rubygems.org/read/chapter/21 http://docs.rubygems.org/read/chapter/21

kgo 14y ago
The trouble is self-signed X.509 certificates are pretty worthless. X.509 certs are built around the concept that they're issued by a trusted provider. I tried to get together a proposal to introduce OpenPGP signed gems and wrote some proof-of-concept code so there could be a proper Web-of-Trust for rubygems: https://github.com/grant-olson/rubygems-openpgp https://github.com/grant-olson/rubygems-openpgp But the developers were resistant (and understandably so) to having gpg as a dependency for gem verification, and I didn't trust myself to write the crypto and a decent keyring validation algorithm from scratch.
- Xylakant 14y ago
  Even with pgp you'd need a whole lot of infrastructure. Where to get the public key from etc. Ubuntu requires pgp keys for their ppa and provides a keyserver. Since a lot of gems seem to use github nowadays, maybe an option to provide a pgp key on github would be great. That would allow to trust at least the most interesting projects - rails, db-layers, rack, etc. which could limit the fallout of an attack against rubygems.org
  - kgo 14y ago
    My proposal was that rubygems would create a simulated certificate authority that operates similarly to the PGP Global Directory, which would allow registered users to have their keys signed by an authorized RubyGems.org signing key. (This is covered on the bottom of the page on the link above.) In addition more active developers who go to conferences and what not would do all the proper WoT stuff to ensure that the RubyGems.org key being used was indeed the authentic one, and that gems in their circle of friends/co-workers were signed by the correct keys.
    - Xylakant 14y ago
      Yes, in general I think the proposal is sound. I just wanted to add that GH might be in a position to add "trust" quickly since the accounts already contain a little bit of information. Many people there have a paid account and so are at least known by credit card. It's not much and by no means perfect, but it's more than we have now.
- moe 14y ago
  The trouble is self-signed X.509 certificates are pretty worthless. I disagree. If you obtain the public key from a second location that is not rubygems.org (e.g. from gem.homepage) then that raises the bar for a potential attacker. He now has to either compromise two sites in order to inject a malicious gem, or trick you into obtaining the public_key from a forged location. I hope 'bundler' and 'gem' hear the wakeup-call and will start displaying a visible warning on unsigned gems (please also print the homepage-url to make it less of a pain for the user to hunt down the public key). After a grace period the default should be switched to -P HighSecurity (reject unsigned gems). Yes, it's is not perfect, users may still import keys without thoroughly checking that the source is legit. However, it'll be a huge improvement over what we have now and greatly reduce the chance of a compromised gem to go unnoticed.
  - kgo 14y ago
    Point taken, but my day-job rails project, which isn't even that big, has 461 gems in my Gemfile.lock. (which lists all the explicitly included gems, as well as their dependencies, if you're not familiar.) That is a lot of self-signed certificates to track down, attempt some form of verification, and manually add as trusted. My proposal would allow people who want a medium-level of security to verify that whoever uploaded the gem has (1) valid credentials to rubygems.org, and (2) control of the account owner's email, without requiring all that manual installation. And it would allow people who wanted to set higher standards of verification to do so, basically for free, by configuring their settings in gpg.
    - moe 14y ago
      I think your approach is problematic because it hinges on the integrity of rubygems.org (the very host that is compromised right now). I do see your concern about having a large number of gems, but I believe that is a bootstrapping problem which could be relatively easily mitigated. Trusted entities (rubygems team, 37signals etc.) could publish signed versions of their keyrings, i.e. public_keys that they trust. So, if you trust 37signals, you'd just download their ring, validate their signature, and import it. And that will probably cover most of your 400 gems.
- tptacek 14y ago
  You can deploy X.509 in the same configurations as you can OpenPGP; X.509 is just a certificate encoding format, and the semantics are up to the application . Ruby has better support for X.509 PKI than it does for OpenPGP, so using OpenPGP seems kind of silly in this case.
  - kgo 14y ago
    Yep, you can do WoT with X.509 if you write the semantics from scratch, and you can also do a CA approach with OpenPGP. The thing is, for years no-one has stepped in and actually gone through the pesky little details of implementing all those semantics for rubygems via X.509 even though it's come up repeatedly. But maybe someday some expert will come along and fix things. If you actually read the rubygems documentation on signing gems, it's pretty much "Okay generate your own self-signed key, then sign it with your self-signed key." That leaves a lot to be desired vs best practices. There isn't even an attempt to describe how you get your self-signed keys to users. I just think leveraging the existing OpenPGP semantics, ecosystem, and battle-hardened gnupg codebase, is a lot easier than implementing an entire system from scratch on X.509 just because openssl is already installed everywhere and ruby has better bindings and gnupg is not and does not. I'm just trying to take the approach you usually preach: Don't roll your own crypto code and leave the real work to the pros, and it seems like gpg offers a lower path of resistance.
    - tptacek 14y ago
      Using OpenPGP is a bad idea here. All the mainstream rubies have access to high-quality X.509 in their mainline distros without a third-party gem. Both OpenPGP and X.509 are going to require a little of fiddley semantic details that will take time to hash out. The bottleneck here isn't the technology. I like, and routinely recommend, OpenPGP for solving app crypto problems. X.509 makes a lot more sense here.