Revocation lists

[nyarly]

At present, Rubygems provides no way to distribute revocations, and even if it did the only value would be in preventing new installations of bad gems.

So: needed is a means to disseminate CRLs, respect paid to revocation in Gem::Security::Policy.verify_gem and subcommands of gem to re-verify installed gems.

[nyarly]

Also: changing security policies won't boot now-unacceptable gems.

[tarcieri]

Copypasta from my previous reply:

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.

What form would this actually take? TBD. I think the details here are less important than whether or not there's enough (ongoing) community support to actually implement #8 successfully.

[Geal]

Frankly, I think the details of revocation are important.

Having spent considerable time on handling certificate authorities, I can tell you that revocation is not the easy part. Distributing a root key/certificate is easy. Signing a key/issuing a certificate is easy. because those actions are done once. With revocation, you must repeatedly distribute revocations status securely to a lot of different actors.

Moreover, there's something that was not discussed much: we issue certificates for developers, but developers sign gems. So there are two types of items needing revocation.

There are two ways of invalidating these tokens:

• waiting for the expiration date to come (assuming the gem signatures would have an expiration date)
• distributing revocation status

And there are three ways of distributing revocation:

• hardcoded in the next rubygems update. Yes, that's ugly, but that will be a good idea anyway, because right after installing rubygems for the first time, you would have a working (but not up to date) revocation list
• with a CRL: easy to distribute (it's just a file, and you can sign it with the root), but grows a lot over time. Vulnerable to MITM. The rubygems client could check on each install or update command if the CRL has changed, download it automatically and run a check.
• with a protocol like OCSP (or an API): more flexible, but that means you have to manage yet another single point of failure. What happensif it gets hacked? What happens if it is unavailable?

Those issues should be addressed right now, because it is an important problem.

[tarcieri]

grows a lot over time

So does the Bitcoin block chain, but that's been doing just fine

Vulnerable to MITM

Sign the CRL with the CA's private key

[Geal]

The Bitcoin block chain doesn't really work that way, and downloading the chain the first time can be very long. But the CRL could be distributed in small increments, yes.

And the CRL can be signed, but there are more ways to tamper with the data in a MITM: I could always send the same old CRL, blocking the new versions. It is still signed and recognized by the client, but obsolete.

[tarcieri]

And the CRL can be signed, but there are more ways to tamper with the data in a MITM: I could always send the same old CRL, blocking the new versions. It is still signed and recognized by the client, but obsolete.

Already covered this in item number 4 of #8's attack surface, but glad we're thinking along similar lines ;)

[Geal]

Ah yes, I remembered seeing this idea somewhere else in the issues, but couldn't remember which one :)