Sign future gems with PGP

[FooBarWidget]

Please sign your future gem releases with PGP, as described at https://www.rubygems-openpgp-ca.org. This allows attackers who forge Paperclip releases to be easily detected. We at Phusion are already signing all our gems.

I realize that you may not necessarily trust this 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 your keys without requiring actions from your side.

[djcp]

If we were to sign our gems, why would we use gpg over the existing openssl implementation? http://docs.rubygems.org/read/chapter/21

[FooBarWidget]

• The existing implementation uses X509 certificates. Because there is currently no official RubyGems CA yet, certificates must be self-signed. Having a CA makes verification for the user easier: if they trust the CA they can indirectly trust you.
• PGP allows a CA to be constructed after the fact, and allows other CAs to sign your certificate without requiring action on your side. Suppose that rubygems-openpgp-ca one day shuts down, or suppose you don't trust rubygems-openpgp-ca. A more suitable CA can take over, requiring no or minimal action from your side. This is unfortunately not as easy with X509 certificates:
• PGP has better tooling than X509. The OpenSSL commands are awkward compared to GnuPG. GnuPG has excellent GUIs, also on OS X. As far as I know, OpenSSL/X509 has none. Maintaining the GnuPG key ring is easier than maintaining X509 certificates.
• PGP is already widely used on Linux, the main production OS of choice for Ruby apps.

[mike-burns]

Of note, we now have a company-wide PGP key: 0xBE7FEF18.

[calebhearth]

I'm in favor of signing gem releases, but the gem utility would need to support the underlying tool used to sign, meaning that for PGP we'd want gem to support PGP signing, fetching keys, verifying keys, etc.

That gets us as far as "someone has signed this gem", after which point it is still desirable to have that someone in our WoT so that the signature is meaningful.

[grant-olson]

The rubygems-openpgp adds all the PGP functionality, but hasn't been widely adopted.

[calebhearth]

Nice. Looks like it could use a bit of UI polish.

For example, getting the key seems like a reasonable default
prerequisite to installing (aptitude does this).

On Tue, Jan 06, 2015 at 09:05:54AM -0800, Grant Olson wrote:

The rubygems-openpgp adds all the PGP functionality, but hasn't been widely adopted.

---

Reply to this email directly or view it on GitHub:
#1195 (comment)

[maclover7]

@jyurek Are you up for doing this?

[tute]

@calebthompson do we sign any of our releases? Do we have the tooling you describe, or does it need to be built? How can we start doing this?

[calebhearth]

carefully.

Easiest, least useful way is to create a .asc of the .gem and distribute that on GitHub releases. End goal is to replace the bundled sigs with gpg sigs instead of bespoke TLS certificate signatures.

❯ tar -tf ~/.rvm/gems/ruby-2.2.2@jellyfish/cache/pg-0.18.1.gem
metadata.gz
metadata.gz.sig
data.tar.gz
data.tar.gz.sig
checksums.yaml.gz
checksums.yaml.gz.sig

Before someone does that, convinces Matz to merge it, convinces people to start signing gems with gpg, and we have a better rubyland WoT, there’s no way to have the gem command do gpg verification.

A gem plugin could be built to do a lot of it, I suspect, but it wouldn’t be part of the default ruby installations.

The very first step I outlined at least gets us as far as being able to verify downloaded gem archives, manually, before installing them. Something like this:

gem fetch capybara-webkit
# visit github, thoughtbot.com/gems, wherever and download signatures
gpg --verify capybara-webkit-x.y.z.gem
gem install capybara-webkit-x.y.z.gem

That's nowhere near a good process, but it is at least a possible process, and not much more difficult than, say, installing GPGTools from their website and verifying the package's signature. It's even slightly more secure since you get the package and the signature from different sources.

I've looked at the plugin @grant-olson mentioned, but it's pretty user unfriendly. I'd love to usurp the extant gem commands to something along the lines of what https://github.com/ruby/ruby/blob/ca6b174078fa15f33655be704d9409fdbc4f9929/lib/rubygems/security.rb provides, but without centralized trust.

https://speakerdeck.com/calebthompson/what-is-this-pgp-thing-and-how-can-i-use-it?slide=31 is some of my thoughts about this from a RailsConf lab. There'll be a video eventually.

[tute]

Thanks for the writeup @calebthompson. This doesn't seem like a solved issue, and I don't see what can we do to improve the situation for paperclip. I have a PGP key, a few coworkers trust it with high confidence. Will paperclip users do too?

[calebhearth]

This doesn't seem like a solved issue

No

Will paperclip users do too?

Dunno. It's valuable just to verify the signature even without trust, but only about as valuable as checking the shasum from rubygems.

I don't see what can we do to improve the situation for paperclip.

The current situation can't get worse, so there's plenty of things you can do.

Go to more keysignings. Help people build keys and exchange signatures with them. Encourage them to do the same, especially at their places of work, conferences and meetups. Get the thoughtbot sub-set closer to a connection to the Debian maintainer set by finding a linux meetup and participating in their keysigning. Build the gem plugin. Start signing gem releases and attaching them to releases here. Document a way to verify the package, even if it was installed by bundler and not automatically checked.

[grant-olson]

Hey I'm open to suggestions to make my plugin more friendly, but the work flow you listed above is exactly the way rubygems-openpgp works:

master-blaster:verify-test grant$ gem install rubygems-openpgp
Fetching: gpg_status_parser-0.4.0.gem (100%)
Successfully installed gpg_status_parser-0.4.0
...
Installing ri documentation for rubygems-openpgp-0.6.0
3 gems installed
master-blaster:verify-test grant$ gem fetch openpgp_signed_hola
Fetching: openpgp_signed_hola-0.0.0.gem (100%)
Downloaded openpgp_signed_hola-0.0.0
master-blaster:verify-test grant$ gem verify openpgp_signed_hola-0.0.0.gem 
Verifying openpgp_signed_hola...
Signature for data.tar.gz from user Grant T. Olson (Personal email) <kgo@grant-olson.net> key 0xE3B5806F is GOODSIG, VALIDSIG and TRUST_ULTIMATE
Signature for metadata.gz from user Grant T. Olson (Personal email) <kgo@grant-olson.net> key 0xE3B5806F is GOODSIG, VALIDSIG and TRUST_ULTIMATE
Owner check indicates kgo@grant-olson.net is owner per rubygems.org...
master-blaster:verify-test grant$ gem install openpgp_signed_hola
Successfully installed openpgp_signed_hola-0.0.0
Parsing documentation for openpgp_signed_hola-0.0.0
Installing ri documentation for openpgp_signed_hola-0.0.0
1 gem installed

I also did try to operate a proof-of-concept certificate authority that acted as a hybrid to bridge the gap for people who can't get in to the Web-of-Trust, where I validated a key holder owned the key and actually was a gem author in an attempt to bootstrap some more practical authentication, but stopped that due to lack of use. Detailed post on the experience here.

I do acknowledge that both the plugin and the CA had some usability issues, but I found myself in a bit of a chicken-and-egg position. If no-one was using the software, then I didn't know how much time should be spent improving usability. There was also the problem that most suggestions to improve usability involved doing a lot of things automatically, which basically gets back to the problem that real key authentication just doesn't happen and opens all sorts of exploits.

If there's anything I can do to make my software more useful for you guys, please let me know.

[calebhearth]

http://desolate-spire-6189.herokuapp.com/

Oh neat, didn't realize that was you. Good work on that man. Sorry it didn't work out. I think a central CA is a reasonable starting place for this.

the work flow you listed above is exactly the way rubygems-openpgp works:

Nice. Like I said, this is a really good starting point but ultimately what I think would help drive adoption is these steps happening during gem install and bundle install automatically based on configuration of behavior (warn/fail, verify/trust, don't bother).

There was also the problem that most suggestions to improve usability involved doing a lot of things automatically

Yeah. Automated works for Debian, where you trust that only keys trusted by the debian package maintainers are allowed into the system, then allow apt to automatically do the verification (it still dumps gpg output). I wonder if it does any trust checking? I'd want that eventually.

You're right, though, the plugin is basically what I want. I guess either my desires or the plugin have changed and I didn't re-check. I apologize.

[grant-olson]

I've spent a lot of time thinking about this, and this is actually getting a little bit beyond this actual ticket, but the difference between Debian and rubygems is that there is a concept of being an official Debian contributor. You've been vouched for and are part of a tight-knit community. In that case it makes sense to keep a separate keyring that starts with the master Debian keys and goes from there, where those keys are a list of 'made men' so to speak. OTOH, anyone can become a rubygems contributor, and you've got more of a loose confederation of random people, so there are no social checks that the author of a gem is not a bad actor. That complicates matters with regards to automatically trusting keys from all gem authors.

I'm not opposed to rubygems-openpgp having it's own keyring that load up a few pre-approved pre-existing trusted master keys, such as the CA keys listed above, but that once again gets back to the chicken-and-egg problem that this is only useful once people are (1) signing gems, and (2) have gotten their key signed off on by one of the master keys.

[tute]

I don’t see any action we can take on paperclip to take care of this issue, and if there is, we will apply it to every other rubygem we release.

There is no standard way using RubyGems to attach the PGP signature to the release. However, we started signing tags and GitHub releases.

@sikachu also started uploading detached signatures of the gem, for example to sprockets-redirect. I may start doing this on my upcoming releases (note to myself: https://github.com/sikachu/shasign).

I'll close this issue for now. Doing so doesn't mean that the underlying problem is solved.

Thank you all for your time discussing this.