5 ms·

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

by 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.
- davebuster 14y ago
  Debian and Ubuntu solve this problem by having an archive signing key that is regularly rolled over and requires multiple people to re-assemble. The entire archive is cryptographically signed by this archive signing key, and each of the individual pacakges that are made up of that archive have been signed by the keys of the people who have been approved to be part of the keyring. This provides a cryptographic verification model that goes all the way up allowing you to verify each package comes from the right place. This would be a huge improvement over what there is now. No, it doesn't solve every problem in the universe, but let us use this opportunity to improve the infrastructure.
- kgo 14y ago
  We're basically on the same page, but coming from different directions. Once you start having people import lists of trusted X.509 signatures from other trusted sources (e.g. 37 Signals) what you end up doing is basically creating the Web Of Trust that already exists in OpenPGP. That is, instead of simulating a X.509 Certificate Authority in OpenPGP like I want to do, you're now simulating a OpenPGP web of trust in X.509 land. I would have the rubygems OpenPGP key be the default for people who would want moderate security. Although a compromise could affect new users, all existing user would have the old key when they installed rubygems. That would immediately set off flags when gems signed by a forged key only were installed by the millions of users with the uncompromised install. In addition, the more security conscious could trust for example 37signals or a co-worker and create a proper Web of Trust for validation. This is the way OpenPGP works by default. You can even different trust levels automatically with this approach. Simply a rubygems.org signature would make the gem moderately trusted. Two additional signatures from two other trusted sources (37signals and a co-worker) would make the gem show up as highly trusted. But rather than manually importing in an ad hoc fashion, you just sign the 37signals key locally, and gpg already takes care of enforcing all the rules, building the chain of trust, publishing peoples signatures to keyservers distributed world-wide, performing security calculations based on a user's custom preferences, etc. So if you want the web-of-trust approach, best to just start with OpenPGP, instead of trying a NIH approach with X.509 certs.
  - moe 14y ago
    Yup, we seem to agree in principle. Your approach is definitely more complete but also seems to require fairly substantial code changes (OpenPGP?). My approach should be doable with a mere ~10 lines patch; Gem and bundler should default to '-P HighSecurity' and rubygems.org should reject pushes of unsigned gems. Anyway, whichever implementation strategy they choose, I hope they will do it soon.
    - technomancy 14y ago
      > My approach should be doable with a mere ~10 lines patch If you actually believe this can be accomplished in 10 lines of code you are not qualified to be giving security advice.

by kgo 14y ago

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.

davebuster 14y ago
Debian and Ubuntu solve this problem by having an archive signing key that is regularly rolled over and requires multiple people to re-assemble. The entire archive is cryptographically signed by this archive signing key, and each of the individual pacakges that are made up of that archive have been signed by the keys of the people who have been approved to be part of the keyring. This provides a cryptographic verification model that goes all the way up allowing you to verify each package comes from the right place. This would be a huge improvement over what there is now. No, it doesn't solve every problem in the universe, but let us use this opportunity to improve the infrastructure.
kgo 14y ago
We're basically on the same page, but coming from different directions. Once you start having people import lists of trusted X.509 signatures from other trusted sources (e.g. 37 Signals) what you end up doing is basically creating the Web Of Trust that already exists in OpenPGP. That is, instead of simulating a X.509 Certificate Authority in OpenPGP like I want to do, you're now simulating a OpenPGP web of trust in X.509 land. I would have the rubygems OpenPGP key be the default for people who would want moderate security. Although a compromise could affect new users, all existing user would have the old key when they installed rubygems. That would immediately set off flags when gems signed by a forged key only were installed by the millions of users with the uncompromised install. In addition, the more security conscious could trust for example 37signals or a co-worker and create a proper Web of Trust for validation. This is the way OpenPGP works by default. You can even different trust levels automatically with this approach. Simply a rubygems.org signature would make the gem moderately trusted. Two additional signatures from two other trusted sources (37signals and a co-worker) would make the gem show up as highly trusted. But rather than manually importing in an ad hoc fashion, you just sign the 37signals key locally, and gpg already takes care of enforcing all the rules, building the chain of trust, publishing peoples signatures to keyservers distributed world-wide, performing security calculations based on a user's custom preferences, etc. So if you want the web-of-trust approach, best to just start with OpenPGP, instead of trying a NIH approach with X.509 certs.
- moe 14y ago
  Yup, we seem to agree in principle. Your approach is definitely more complete but also seems to require fairly substantial code changes (OpenPGP?). My approach should be doable with a mere ~10 lines patch; Gem and bundler should default to '-P HighSecurity' and rubygems.org should reject pushes of unsigned gems. Anyway, whichever implementation strategy they choose, I hope they will do it soon.
  - technomancy 14y ago
    > My approach should be doable with a mere ~10 lines patch If you actually believe this can be accomplished in 10 lines of code you are not qualified to be giving security advice.