search

rubygems-trust / rubygems.org

The Ruby community's gem hosting service.
https://rubygems.org
MIT License
16 stars 2 forks source link

Cryptographic continuity #14

Open nyarly opened 11 years ago

nyarly commented 11 years ago

@cheald brought up the important issue that - having trusted gem-0.1.0, current installation processes pretty much automatically would install gem-0.1.1. If the beginning and end of gem security is "cert signed by someone I trust" (especially if the default is "I trust the Rubygems root, and they sign anything") then there's the risk of an attacker putting up a sub-version bump of a gem signed by a regular gem author cert.

This attack presumes that we've bypassed Rubygems.org (or other gem host's) gem ownership checks on gem push.

Basically, two possiblities exist to recover from this:

A) Rubygems revokes the signature. Current Gem::Security makes no allowances for revocation, so that would have to be added. Different issue.

B) A chain of authorship is established - Basically, every gem would need to be, in the simplest case, signed by the same key as the original gem push. To allow for teams or transitions of projects, gem handoffs would need to be added and attached and maintained somewhere.

I don't think that B can really be handled by attaching gem signing metadata to the gem itself.

cheald commented 11 years ago

My original proposal (#3) handles this by establishing the concept of an append-only trust history, both locally and on a queryable platform physically separate from the gem distribution platform. This handles things like validation of cryptographic continuity, project hand-offs, addition and removal of authorized signers to and from a project, and the like.

In the upgrade case, the local history would reject the upgrade unless a cert change authorization is signed by an existing cert on the gem. In the install case, the installer could query the trust history server to validate that the signer on the copy of the gem they hold matches the last authorized signer list on the project.

tarcieri commented 11 years ago

My proposal (#8) handles this by having a central authority tasked exclusively with gem security, with the assumption that it would provide some sort of CRL API which would be consulted prior to installing any new gems. Of course malicious gems wouldn't automatically show up in the CRL, they would need to be detected first and certificates revoked appropriately, but once that is happened these gems would be blocked.