3 ms·

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 truste

by 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.
  - moe 14y ago
    It's always sad to have people chime in like that. The changes I specified are, indeed, about a 10 line patch. You change the default for '-P' (1 line) and you inspect pushes to rubygems.org for a signature and reject them if they lack one. I'd be very surprised if the latter exceeds 9 lines. All you have to do is look for s.cert_chain in the gemspec, so it would actually likely be closer to 3 lines. You may disagree with what I proposed and demand additional changes, or you may prefer the superior (albeit more complex) PGP approach. But you should not go ad hominem over a basic fact when you obviously have no idea what you're talking about. (disclaimer: one of us two has actually read the code involved with gem signing just a few days ago - and I'm pretty sure it wasn't you...)
    - technomancy 14y ago
      I'm not disputing that this change is a step in the right direction, but the implication that it solves roughly the same problem as the existing OpenPGP-based infrastructure is very misleading. [Edit: if you din't mean to imply this by your post then I apologize; it was not clear from how I read it.] Same with the idea that you can "just apply a 10-line patch" without considering the background in documentation, tooling, and educating the community that such a change would require--it implies that the current rubygems maintainers are ignorant or lazy for not having done this easy fix already. (I spoke at length on a PGP-based approach to this same problem at the 2012 Clojure Conj conference if you would like to talk about credentials: https://www.youtube.com/watch?v=sBSUIKMdQ4w https://www.youtube.com/watch?v=sBSUIKMdQ4w)
      - moe 14y ago
        I didn't claim it solves "roughly the same problem", only a very relevant subset of the problem (integrity) closely related to the unfortunate situation rubygems is in right now. What you call background (docs, tooling, education) is an argument in favor of the simple approach, which is already implemented and just not enforced - in contrast to whipping up new infrastructure of significantly higher complexity from scratch. Also I didn't imply the maintainers are ignorant or lazy, they were merely oblivious. So I'll repeat: The PGP approach is obviously superior, but comes with serious complexity and implementation concerns (there is no native PGP-library in ruby). Consequently it might make sense to add basic security right now, in a minimally intrusive fashion, while a more complete solution is developed. This, by the way, is part of the discussion that the rubygems team is having right now[1]. [1] https://github.com/rubygems-trust/rubygems.org/wiki/Overview https://github.com/rubygems-trust/rubygems.org/wiki/Overview

by kgo 14y ago

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.
- moe 14y ago
  It's always sad to have people chime in like that. The changes I specified are, indeed, about a 10 line patch. You change the default for '-P' (1 line) and you inspect pushes to rubygems.org for a signature and reject them if they lack one. I'd be very surprised if the latter exceeds 9 lines. All you have to do is look for s.cert_chain in the gemspec, so it would actually likely be closer to 3 lines. You may disagree with what I proposed and demand additional changes, or you may prefer the superior (albeit more complex) PGP approach. But you should not go ad hominem over a basic fact when you obviously have no idea what you're talking about. (disclaimer: one of us two has actually read the code involved with gem signing just a few days ago - and I'm pretty sure it wasn't you...)
  - technomancy 14y ago
    I'm not disputing that this change is a step in the right direction, but the implication that it solves roughly the same problem as the existing OpenPGP-based infrastructure is very misleading. [Edit: if you din't mean to imply this by your post then I apologize; it was not clear from how I read it.] Same with the idea that you can "just apply a 10-line patch" without considering the background in documentation, tooling, and educating the community that such a change would require--it implies that the current rubygems maintainers are ignorant or lazy for not having done this easy fix already. (I spoke at length on a PGP-based approach to this same problem at the 2012 Clojure Conj conference if you would like to talk about credentials: https://www.youtube.com/watch?v=sBSUIKMdQ4w https://www.youtube.com/watch?v=sBSUIKMdQ4w)
    - moe 14y ago
      I didn't claim it solves "roughly the same problem", only a very relevant subset of the problem (integrity) closely related to the unfortunate situation rubygems is in right now. What you call background (docs, tooling, education) is an argument in favor of the simple approach, which is already implemented and just not enforced - in contrast to whipping up new infrastructure of significantly higher complexity from scratch. Also I didn't imply the maintainers are ignorant or lazy, they were merely oblivious. So I'll repeat: The PGP approach is obviously superior, but comes with serious complexity and implementation concerns (there is no native PGP-library in ruby). Consequently it might make sense to add basic security right now, in a minimally intrusive fashion, while a more complete solution is developed. This, by the way, is part of the discussion that the rubygems team is having right now[1]. [1] https://github.com/rubygems-trust/rubygems.org/wiki/Overview https://github.com/rubygems-trust/rubygems.org/wiki/Overview