Add cryptographic signatures for each gem

[cheald]

In light of the recent Rubygems security issues, I think it would be prudent to add a signature to the gem and include it in releases. This isn't something I can issue a PR for, since the project owner would need to own the cert files.

The how-to is here:

http://docs.rubygems.org/read/chapter/21

TL;DR:

1. gem cert --build your@email.com

2. Copy the private key somewhere safe

3. Add the public key to the repo (git add gem-public_cert.pem)

4. Update the gemspec with something like:

   s.signing_key = '/home/chris/.gemcert/gem-private_key.pem'
   s.cert_chain = ['gem-public_cert.pem']

5. Push and rake release

While this would be a self-signed certificate, the presence of the pubkey in the canonical repo will allow people verify that the gem they installed from Rubygems (or where ever) was signed by the project maintainer, and has not been altered.

[guilleiguaran]

This isn't something I can issue a PR for, since the project owner would need to own the cert files.

In Rails, project owner = 13 core members with permission to push to rubygems

[cheald]

Yup. I opened this issue on several projects. :)

In the Rails case, the private key would need to be shared among the team members with gem publication permissions.

[carlosantoniodasilva]

In the Rails case, the private key would need to be shared among the team members with gem publication permissions.

This is true for tons of other projects, not only Rails =/

[cheald]

You could also just have a master key for the project, and then sign each individual team member's key with the master key.

Per the doc:

gem cert -K /mnt/floppy/issuer-priv_key.pem -C issuer-pub_cert.pem \
  --sign client_cert.pem

Then, each team member could maintain their own certificate which is trusted by the Rails root certificate. There's no revocation strategy in place (though there is some good work happening on the rubygems.org-trust project in that regard), but this allows for knowing both a) who specifically released a gem, and b) that the gem release is trusted by the Rails project.

[FooBarWidget]

Rails should use PGP to sign files, as described at https://www.rubygems-openpgp-ca.org. We at Phusion are already signing all our gems with PGP.

You may not necessarily trust the rubygems-openpgp-ca.org CA, but that is fine. By signing with PGP users can still verify files from your key directly, and if rubygems.org ever starts an official CA they can sign the Rails keys without requiring actions from the Rails side.

PGP provides many benefits over the X509 certificates that RubyGems supports by default:

• It works with the "web of trust" model, which is decentralized. It requires no existing CA infrastructure, and allows CA infrastructure to be built after the fact. X509 requires an existing CA infrastructure.
• X509 tooling is very awkward. GPG is comparatively easy to use.

https://www.rubygems-openpgp-ca.org/blog/gem-signing-x509-and-openpgp.html explains it better.

[cheald]

Evan Phoenix of the Rubygems project has stated that a PGP-based solution is a non-starter for Rubygems integration since it relies on things outside of the Ruby stdlib. If Rubygems isn't going to support it, then its chances of gaining wide adoption are slim. x509 is going to be more futureproof, IMO.

[FooBarWidget]

Evan Phoenix's statement was from 2 years ago before anyone believed that rubygems.org being hacked was a serious problem. Clearly times have changed.

X509 is already a non-starter because there's no CA. Its tooling sucks so much that few developers want to bother with signing. So this leaves PGP. PGP has excellent tooling, is already widely used in the Linux packaging community, and a CA can be built after the fact.

I don't see rejecting a system just because it relies on things outside the Ruby stdlib to be a good reason. This is security we're talking about. If there's one thing that I've learned from my computer security master and from all my professors, it's that security is hard and you shouldn't try to reinvent security systems and cryptosystems. Furthermore:

• Writing a PGP implementation in Ruby from scratch is asking for problems. There will be vulnerabilities. GnuPG is a secure, established implementation.
• GnuPG is available on all major platforms. Binaries are easily and readily available.
• RubyGems can use GnuPG when it's available, falling back to no-op when it's not. It does not have to be a required dependency for normal operation.

[cheald]

No, he last said it on Feb 3. https://twitter.com/evanphx/statuses/298201886908088320

[grant-olson]

Full disclosure, I'm the author of rubygems-openpgp, so it's probably clear what signing technology I prefer.

I wanted to point out that the pgp signatures were specifically designed to be compatible with the X.509 certs. They are not mutually exclusive. There's no technological reason a gem couldn't be signed with both and let users pick-and-choose how to authenticate.

Of course this adds a more of an administrative overhead on the official builds.

[FooBarWidget]

Tweets redirected me to this thread on rubygems-trust: https://t.co/BgTg88xxzE

[rafaelfranca]

I'll close this issue since it is more a discussion that a real issue.