RFC: Increase the level of trust in released gem files

[flavorjones]

When we start officially distributing precompiled libraries for Linux (see #1983), I worry a bit about how people will know to trust those binary files in their production environments. I would like to think about how we might improve the trust situation.

One option is to cryptographically sign the released gem file, as described in the Rubygems Security Guide. This seems reasonable to me, but I've opened this issue to ask for other folks' opinions and check if there are other ideas on how to prove that the gem being installed was created by a trusted Nokogiri core maintainer.

[larskanis]

The pg.gem uses signatures since many years. All official releases are signed with the key of the original author, which is Michael Granger. He's the only one who has the private key. The certificate with the public key is stored in the repository here: https://github.com/ged/ruby-pg/blob/master/certs/ged.pem
Sometimes I push prereleases to rubygems.org - they are unsigned then.

Nothing really fancy, but it works so far.

[tenderlove]

TL;DR: a shasum in a PGP signed announcement email or blog post gives me more confidence than RubyGems signatures

I think part of the issue is that there is no signature for the gem as a whole. Signing the gem means adding a checksum to each of the components within the gem file. If someone MITM's rubygems, the signed gem could be replaced by an unsigned gem, so it would require folks to enable HighSecurity which would insist that all gems they install are signed (but IRL not all gems are signed).

Another thing I'm not sure about is how RubyGems knows a particular signature works with a particular gem. IOW, could I sign the PG gem with my signature and have RubyGems install it even though I'm not the owner? I haven't investigated if this is possible, but if we're just installing "trusted certs", it certainly seems possible (I could trick you to install a cert by having you install a gem where the extconf helpfully installs the cert for you, or even replaces ged's cert with my cert).

For Rails, we try to publish checksums of the gems out of band with the gem itself. For example, push to the Rails weblog with signed git commits, or sending an announcement email with a PGP signature. If you trust that the blog post commit wasn't tampered with, or you trust my PGP signature for the email, you can trust that the checksums weren't tampered with. I'm not sure if RG can make the same guarantees. These are some of the reasons we haven't bothered with signatures for Rails. The down side is that it's not automatic, like HighSecurity is automatic. But HighSecurity can't practically be enabled anyway. The upside is that it's harder to MITM, and much easier to explain "compare your shas with the ones in the blog post" (which is something people actually do, and I know this because I messed them up once).

[mensfeld]

If someone MITM's rubygems, the signed gem could be replaced by an unsigned gem

I keep a constant eye on this with automation so I would not worry about this that much.