On 5/26/2011 9:09 PM, Nick Quaranto wrote: > Just interjecting my opinion in here! > > This feature was requested a while ago: > > https://github.com/rubygems/gemcutter/issues/96 > > But I think the actual "CA" stuff could be an entirely different app > than Gemcutter...in a different repo. but at something like > https://ca.rubygems.org or https://security.rubygems.org ...something! > :) >
Basically with OpenPGP you get this for free. There are already keyservers all over the world that have everyone's keys. pool.sks-keyservers.net has like 50 active nodes run by different people. The last outage was because of DNS problems, and now there are multiple computers in different regions controlling the DNS. Still, if you knew the names of the individual nodes, you could connect to the individual servers even while the pool.sks-keyservers.net DNS entry wasn't resolving. Evan expressed some concern about uptime and relying on third parites, so you could install your own sks-keyserver and sync with the pool, possibly round-robining between this server, pool.sks-keyservers.net, pgp.mit.edu, etc. In this scenario, the gem maintainer creates a key and pushes it to one of the keyservers. Within a few hours it's on all of them. This is a one time operation. After this they can sign all the gems they want with that key. Once that's done, the gem user can retrieve the key from the client, without anything special going on at a website. So like I said, that feature basically gets handled automatically with OpenPGP. There's nothing to do on the server-side, except possibly setting up another keyserver. But the *real problem* is authentication. That's where you'd need some sort of security.rubygems.org app. A little background info: The X509/OpenSSL model imposes a hierarchical model. You've got one master certificate that you trust. Its just an a priori assumption that this top-level certificate is valid. In something like a web browser, it's (basically) hard-coded into the app. From there you can verify that the next level is certified to approve certificates, and the gems signed by those certificates. OpenPGP uses a web-of-trust. That's more like six-degrees-of-Kevin-Bacon. There are a bunch of bogus keys out there for presid...@whitehouse.gov: http://pgp.mit.edu:11371/pks/lookup?search=president%40whitehouse.gov&op=index That might look like a security problem, but it's not. Because there's no path from you to these bogus keys. Assuming one of them was real, then maybe it's signed by Joe Biden's key. And your uncle is on Joe Biden's bowling team, so he signed that key. And you of course know your uncle, so you know the key is good by following the path: Me -> My Uncle -> Joe Biden -> presid...@whitehouse.gov. In comp-sci terms, the X509 model is a tree, and the OpenPGP model is a graph. But trees are subsets of graphs. And that's where the rubygems.org app would come in. It becomes the equivalent of your uncle or Joe Biden in the above scenario. It provides the connection between you and the gem maintainer: Me -> security.rubygems.org -> thought-bot It can't verify that the app isn't malicious. It can't verify that you're really the presid...@whitehouse.gov. What it can verify is that the gem you have was (1) created by the appropriate rubygems user account, and that (2) it hasn't been tampered with. It can verify that the gem isn't signed by a bogus thought-bot key that a malicious user created on their machine and published to the keysevers. This malicious key becomes a single point disconnected from the web of trust. To do this, it needs to verify that the user controls their email address and the key. The original post describes how this is done. It signs the thought-bot key by performing some reasonable checks. You sign the rubygems key either because that's hard-coded into the app, like an X509 certificate, or because you've done it manually after (for example) verifying the key fingerprint on the rubygems website. That's why i lean towards tying this signature directly to your rubygems account, because that account is a somewhat authoritatively tied to the gem maintainer. I can still see the advantage of setting this up as a separate app, especially when we're not even sure if people will sign gems even with an end-to-end system in place. -- Grant _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
