9. Signing Your Gems
This chapter is provided by Paul Duncan, the author of the signing patch.
RubyGems version 0.8.11 and later supports adding cryptographic signatures to gems. The section below is a step-by-step guide to using signed gems and generating your own.
In order to start signing your gems, you’ll need to build a private key and a self-signed certificate. Here’s how:
# build a private key and certificate for email@example.com $ gem cert --build firstname.lastname@example.org
This could take anywhere from 5 seconds to 10 minutes, depending on the speed of your computer (public key algorithms aren’t exactly the speediest crypto algorithms in the world). When it’s finished, you’ll see the files “gem-private_key.pem” and “gem-public_cert.pem” in the current directory.
First things first: take the “gem-private_key.pem” file and move it somewhere private, preferably a directory only you have access to, a floppy (yuck!), a CD-ROM, or something comparably secure. Keep your private key hidden; if it’s compromised, someone can sign packages as you (note: PKI has ways of mitigating the risk of stolen keys; more on that later).
Now, let’s sign an existing gem. I’ll be using my Imlib2-Ruby bindings,
but you can use whatever gem you’d like. Open up your existing gemspec
file and add the following lines:
# signing key and certificate chain s.signing_key = '/mnt/floppy/gem-private_key.pem' s.cert_chain = ['gem-public_cert.pem']
(Be sure to replace “/mnt/floppy” with the ultra-secret path to your private key).
After that, go ahead and build your gem as usual. Congratulations, you’ve just built your first signed gem! If you peek inside your gem file, you’ll see a couple of new files have been added:
$ tar tf tar tf Imlib2-Ruby-0.5.0.gem data.tar.gz data.tar.gz.sig metadata.gz metadata.gz.sig
Now let’s verify the signature. Go ahead and install the gem, but add the following options: “-P HighSecurity”, like this:
# install the gem with using the security policy "HighSecurity" $ sudo gem install Imlib2-Ruby-0.5.0.gem -P HighSecurity
P option sets your security policy - we’ll talk about that in just
a minute. Eh, what’s this?
Attempting local installation of 'Imlib2-Ruby-0.5.0.gem' ERROR: Error installing gem Imlib2-Ruby-0.5.0.gem[.gem]: Couldn't verify data signature: Untrusted Signing Chain Root: cert = '/CN=gemmaster/DC=example/DC=com', error = 'path "/root/.rubygems/trust/cert-15dbb43a6edf6a70a85d4e784e2e45312cff7030.pem" does not exist'
The culprit here is the security policy. RubyGems has several different
security policies. Let’s take a short break and go over the security
policies. Here’s a list of the available security policies, and a brief
description of each one:
- NoSecurity – Well, no security at all. Signed packages are treated like unsigned packages.
- LowSecurity – Pretty much no security. If a package is signed then RubyGems will make sure the signature matches the signing certificate, and that the signing certificate hasn’t expired, but that’s it. A malicious user could easily circumvent this kind of security.
- MediumSecurity – Better than LowSecurity and NoSecurity, but still fallible. Package contents are verified against the signing certificate, and the signing certificate is checked for validity, and checked against the rest of the certificate chain (if you don’t know what a certificate chain is, stay tuned, we’ll get to that). The biggest improvement over LowSecurity is that MediumSecurity won’t install packages that are signed by untrusted sources. Unfortunately, MediumSecurity still isn’t totally secure — a malicious user can still unpack the gem, strip the signatures, and distribute the gem unsigned.
- HighSecurity – Here’s the bugger that got us into this mess. The HighSecurity policy is identical to the MediumSecurity policy, except that it does not allow unsigned gems. A malicious user doesn’t have a whole lot of options here; he can’t modify the package contents without invalidating the signature, and he can’t modify or remove signature or the signing certificate chain, or RubyGems will simply refuse to install the package. Oh well, maybe he’ll have better luck causing problems for CPAN users instead :).
So, the reason RubyGems refused to install our shiny new signed gem was because it was from an untrusted source. Well, my code is infallible (hah!), so I’m going to add myself as a trusted source. Here’s how:
# add trusted certificate gem cert --add gem-public_cert.pem
I’ve added my public certificate as a trusted source. Now I can install packages signed my private key without any hassle. Let’s try the install command above again:
# install the gem with using the HighSecurity policy (and this time # without any shenanigans) $ sudo gem install Imlib2-Ruby-0.5.0.gem -P HighSecurity
This time RubyGems should accept your signed package and begin installing. While you’re waiting for RubyGems to work it’s magic, have
a look at some of the other security commands:
Usage: gem cert [options] Options: -a, --add CERT Add a trusted certificate. -l, --list List trusted certificates. -r, --remove STRING Remove trusted certificates containing STRING. -b, --build EMAIL_ADDR Build private key and self-signed certificate for EMAIL_ADDR. -C, --certificate CERT Certificate for --sign command. -K, --private-key KEY Private key for --sign command. -s, --sign NEWCERT Sign a certificate with my key and certificate.
(By the way, you can pull up this list any time you’d like by typing “gem cert —help”)
Hmm. We’ve already covered the “—build” option, and the “—add”, “—list”, and “—remove” commands seem fairly straightforward; they allow you to add, list, and remove the certificates in your trusted certificate list. But what’s with this “—sign” option?
To answer that question, let’s take a look at “certificate chains”, a concept I mentioned earlier. There are a couple of problem s with self-signed certificates: first of all, self-signed certificates don’t offer a whole lot of security. Sure, the certificate says Yukihiro Matsumoto, but how do I know it was actually generated and signed by Matz himself unless he gave me the certificate in person?
The second problem is scalability. Sure, if there are 50 gem authors, then I have 50 trusted certificates, no problem. What if there are 500 gem authors? 1000? Having to constantly add new trusted certificates is a pain, and it actually makes the trust system less secure by encouraging RubyGems users to blindly trust new certificates.
Here’s where certificate chains come in. A certificate chain establishes an arbitrarily long chain of trust between an issuing certificate and a child certificate. So instead of trusting certificates on a per-developer basis, we use the PKI concept of certificate chains to build a logical hierarchy of trust. Here’s a hypothetical example of a trust hierarchy based (roughly) on geography:
-------------------------- | email@example.com | -------------------------- | ----------------------------------- | | ---------------------------- ----------------------------- | firstname.lastname@example.org | | email@example.com | ---------------------------- ----------------------------- | | | | --------------- ---------------- ----------- -------------- | alf@seattle | | bob@portland | | pabs@dc | | tomcope@dc | --------------- ---------------- ----------- --------------
Now, rather than having 4 trusted certificates (one for alf@seattle, bob@portland, pabs@dc, and tomecope@dc), a user could actually get by with 1 certificate: the “firstname.lastname@example.org” certificate. Here’s how it works:
I install “Alf2000-Ruby-0.1.0.gem”, a package signed by “alf@seattle”. I’ve never heard of “alf@seattle”, but his certificate has a valid signature from the “email@example.com” certificate, which in turn has a valid signature from the “firstname.lastname@example.org” certificate. Voila! At this point, it’s much more reasonable for me to trust a package signed by “alf@seattle”, because I can establish a chain to “email@example.com”, which I do trust.
And the “—sign” option allows all this to happen. A developer creates
their build certificate with the “—build” option, then has their
certificate signed by taking it with them to their next regional Ruby
meetup (in our hypothetical example), and it’s signed there by the
person holding the regional RubyGems signing certificate, which is
signed at the next RubyConf by the holder of the top-level RubyGems
certificate. At each point the issuer runs the same command:
# sign a certificate with the specified key and certificate # (note that this modifies client_cert.pem!) $ gem cert -K /mnt/floppy/issuer-priv_key.pem -C issuer-pub_cert.pem \ --sign client_cert.pem
Then the holder of issued certificate (in this case, our buddy “alf@seattle”), can start using this signed certificate to sign RubyGems. By the way, in order to let everyone else know about his new fancy signed certificate, “alf@seattle” would change his gemspec file to look like this:
# signing key (still kept in an undisclosed location!) s.signing_key = '/mnt/floppy/alf-private_key.pem' # certificate chain (includes the issuer certificate now too) s.cert_chain = ['/home/alf/doc/seattlerb-public_cert.pem', '/home/alf/doc/alf_at_seattle-public_cert.pem']
Obviously, this RubyGems trust infrastructure doesn’t exist yet (I just wrote the patch, for cripes sake!). Also, in the “real world” issuers actually generate the child certificate from a certificate request, rather than sign an existing certificate. And our hypothetical infrastructure is missing a certificate revocation system. These are
that can be fixed in the future… I’m sure your new signed gem has finished installing by now (unless you’re installing rails and all it’s dependencies, that is ;D). At this
point you should know how to do all of these new and interesting things:
- build a gem signing key and certificate
- modify your existing gems to support signing
- adjust your security policy
- modify your trusted certificate list
- sign a certificate
If you’ve got any questions, feel free to contact me at the email address below.
Here’s a brief summary of the certificate-related command line options:
gem install -P, --trust-policy POLICY Specify gem trust policy. gem cert -a, --add CERT Add a trusted certificate. -l, --list List trusted certificates. -r, --remove STRING Remove trusted certificates containing STRING. -b, --build EMAIL_ADDR Build private key and self-signed certificate for EMAIL_ADDR. -C, --certificate CERT Certificate for --sign command. -K, --private-key KEY Private key for --sign command. -s, --sign NEWCERT Sign a certificate with my key and certificate. <pre> A more detailed description of each options is available in the walkthrough above.
The .pem files generated by —build and —sign are just basic OpenSSL PEM files. Here’s a couple of useful commands for manipulating them:
# convert a PEM format X509 certificate into DER format: # (note: Windows .cer files are X509 certificates in DER format) $ openssl x509 -in input.pem -outform der -out output.der # print out the certificate in a human-readable format: $ openssl x509 -in input.pem -noout -text
And you can do the same thing with the private key file as well:
# convert a PEM format RSA key into DER format: $ openssl rsa -in input_key.pem -outform der -out output_key.der # print out the key in a human readable format: $ openssl rsa -in input_key.pem -noout -text
- right now I’m using Gem.user_home + ‘.gem/trust’ for the trusted cert list. There’s no way to define a system-wide trust list.
- custom security policies (from a YAML file, etc)
- Simple method to generate a signed certificate request
- Support for OCSP, SCVP, CRLs, or some other form of cert status check (list is in order of preference)
- Support for encrypted private keys
- Some sort of semi-formal trust hierarchy (see long-winded explanation above)
- Path discovery (for gem certificate chains that don’t have a self-signed root) — by the way, since we don’t have this, THE ROOT OF THE CERTIFICATE CHAIN MUST BE SELF SIGNED if Policy#verify_root is true (and it is for the MediumSecurity and HighSecurity policies)
- Better explanation of X509 naming (ie, we don’t have to use email addresses)
- possible alternate signing mechanisms (eg, via PGP). This could be done pretty easily by adding a :signing_type attribute to the gemspec, then add the necessary support in other places
- honor AIA field (see note about OCSP above)
- maybe honor restriction extensions?
- might be better to store the certificate chain as a PKCS#7 or PKCS#12 file, instead of an array embedded in the metadata. ideas?
- possibly embed signature and key algorithms into metadata (right now they’re assumed to be the same as what’s set inGem::Security::OPT)
Paul Duncan (firstname.lastname@example.org)