U:RDoc::NormalModule[iI" Security:EFI"Gem::Security;T0o:RDoc::Markup::Document: @parts[o;;[lS:RDoc::Markup::Heading: leveli: textI"Signing gems;To:RDoc::Markup::BlankLineo:RDoc::Markup::Paragraph;[I"RThe Gem::Security implements cryptographic signatures for gems. The section ;TI"Pbelow is a step-by-step guide to using signed gems and generating your own.;T@S; ; i; I"Walkthrough;T@S; ; i; I"Building your certificate;T@o; ;[I"QIn order to start signing your gems, you'll need to build a private key and ;TI",a self-signed certificate. Here's how:;T@o:RDoc::Markup::Verbatim;[I"9# build a private key and certificate for yourself: ;TI"($ gem cert --build you@example.com ;T: @format0o; ;[ I"RThis could take anywhere from a few seconds to a minute or two, depending on ;TI"Jthe speed of your computer (public key algorithms aren't exactly the ;TI"Pspeediest crypto algorithms in the world). When it's finished, you'll see ;TI"Nthe files "gem-private_key.pem" and "gem-public_cert.pem" in the current ;TI"directory.;T@o; ;[I"OFirst things first: Move both files to ~/.gem if you don't already have a ;TI"Rkey and certificate in that directory. Ensure the file permissions make the ;TI"Fkey unreadable by others (by default the file is saved securely).;T@o; ;[I"RKeep your private key hidden; if it's compromised, someone can sign packages ;TI"Oas you (note: PKI has ways of mitigating the risk of stolen keys; more on ;TI"that later).;T@S; ; i; I"Signing Gems;T@o; ;[I"RIn RubyGems 2 and newer there is no extra work to sign a gem. RubyGems will ;TI"Pautomatically find your key and certificate in your home directory and use ;TI"&them to sign newly packaged gems.;T@o; ;[ I"OIf your certificate is not self-signed (signed by a third party) RubyGems ;TI"Owill attempt to load the certificate chain from the trusted certificates. ;TI"MUse gem cert --add signing_cert.pem to add your signers as ;TI"Mtrusted certificates. See below for further information on certificate ;TI" chains.;T@o; ;[I"PIf you build your gem it will automatically be signed. If you peek inside ;TI"Eyour gem file, you'll see a couple of new files have been added:;T@o;;[ I"$ tar tf your-gem-1.0.gem ;TI"metadata.gz ;TI"metadata.gz.sum ;TI"*metadata.gz.sig # metadata signature ;TI"data.tar.gz ;TI"data.tar.gz.sum ;TI"&data.tar.gz.sig # data signature ;T;0S; ; i; I"Manually signing gems;T@o; ;[ I"PIf you wish to store your key in a separate secure location you'll need to ;TI"@set your gems up for signing by hand. To do this, set the ;TI"Psigning_key and cert_chain in the gemspec before ;TI"packaging your gem:;T@o;;[I";s.signing_key = '/secure/path/to/gem-private_key.pem' ;TI"-P HighSecurity, like this:;T@o;;[I"E# install the gem with using the security policy "HighSecurity" ;TI"1$ sudo gem install your.gem -P HighSecurity ;T;0o; ;[I"NThe -P option sets your security policy -- we'll talk about ;TI"-that in just a minute. Eh, what's this?;T@o;;[I"4$ gem install -P HighSecurity your-gem-1.0.gem ;TI"@ERROR: While executing gem ... (Gem::Security::Exception) ;TI"5 root cert /CN=you/DC=example is not trusted ;T;0o; ;[ I"NThe culprit here is the security policy. RubyGems has several different ;TI"Ksecurity policies. Let's take a short break and go over the security ;TI"Npolicies. Here's a list of the available security policies, and a brief ;TI"description of each one:;T@o:RDoc::Markup::List: @type: BULLET: @items[ o:RDoc::Markup::ListItem: @label0;[o; ;[I"NNoSecurity - Well, no security at all. Signed packages are treated like ;TI"unsigned packages.;To;;0;[o; ;[ I"ILowSecurity - Pretty much no security. If a package is signed then ;TI"?RubyGems will make sure the signature matches the signing ;TI"Gcertificate, and that the signing certificate hasn't expired, but ;TI"Gthat's it. A malicious user could easily circumvent this kind of ;TI"security.;To;;0;[o; ;[I"HMediumSecurity - Better than LowSecurity and NoSecurity, but still ;TI"Bfallible. Package contents are verified against the signing ;TI"Gcertificate, and the signing certificate is checked for validity, ;TI"Iand checked against the rest of the certificate chain (if you don't ;TI"Gknow what a certificate chain is, stay tuned, we'll get to that). ;TI"EThe biggest improvement over LowSecurity is that MediumSecurity ;TI"Bwon't install packages that are signed by untrusted sources. ;TI"CUnfortunately, MediumSecurity still isn't totally secure -- a ;TI"Hmalicious user can still unpack the gem, strip the signatures, and ;TI"!distribute the gem unsigned.;To;;0;[o; ;[ I"BHighSecurity - Here's the bugger that got us into this mess. ;TI"HThe HighSecurity policy is identical to the MediumSecurity policy, ;TI"Dexcept that it does not allow unsigned gems. A malicious user ;TI"Edoesn't have a whole lot of options here; they can't modify the ;TI"Ipackage contents without invalidating the signature, and they can't ;TI"Emodify or remove signature or the signing certificate chain, or ;TI"IRubyGems will simply refuse to install the package. Oh well, maybe ;TI"Ithey'll have better luck causing problems for CPAN users instead :).;T@o; ;[I"RThe reason RubyGems refused to install your shiny new signed gem was because ;TI"Rit was from an untrusted source. Well, your code is infallible (naturally), ;TI"5so you need to add yourself as a trusted source:;T@o;;[I"# add trusted certificate ;TI"/gem cert --add ~/.gem/gem-public_cert.pem ;T;0o; ;[I"PYou've now added your public certificate as a trusted source. Now you can ;TI"Pinstall packages signed by your private key without any hassle. Let's try ;TI"%the install command above again:;T@o;;[ I"I# install the gem with using the HighSecurity policy (and this time ;TI" # without any shenanigans) ;TI"4$ gem install -P HighSecurity your-gem-1.0.gem ;TI")Successfully installed your-gem-1.0 ;TI"1 gem installed ;T;0o; ;[I"MThis time RubyGems will accept your signed package and begin installing.;T@o; ;[I"RWhile you're waiting for RubyGems to work it's magic, have a look at some of ;TI"Gthe other security commands by running gem help cert:;T@o;;[I"Options: ;TI"C -a, --add CERT Add a trusted certificate. ;TI"L -l, --list [FILTER] List trusted certificates where the ;TI"@ subject contains FILTER ;TI"N -r, --remove FILTER Remove trusted certificates where the ;TI"@ subject contains FILTER ;TI"J -b, --build EMAIL_ADDR Build private key and self-signed ;TI"C certificate for EMAIL_ADDR ;TI"G -C, --certificate CERT Signing certificate for --sign ;TI"B -K, --private-key KEY Key for --sign or --build ;TI"H -s, --sign CERT Signs CERT with the key from -K ;TI"D and the certificate from -C ;T;0o; ;[ I"DWe've already covered the --build option, and the ;TI"Q--add, --list, and --remove commands ;TI"Nseem fairly straightforward; they allow you to add, list, and remove the ;TI"Jcertificates in your trusted certificate list. But what's with this ;TI" --sign option?;T@S; ; i; I"Certificate chains;T@o; ;[ I"KTo answer that question, let's take a look at "certificate chains", a ;TI"Gconcept I mentioned earlier. There are a couple of problems with ;TI"Rself-signed certificates: first of all, self-signed certificates don't offer ;TI"Ra whole lot of security. Sure, the certificate says Yukihiro Matsumoto, but ;TI"Rhow do I know it was actually generated and signed by matz himself unless he ;TI"'gave me the certificate in person?;T@o; ;[ I"QThe second problem is scalability. Sure, if there are 50 gem authors, then ;TI"LI have 50 trusted certificates, no problem. What if there are 500 gem ;TI"Mauthors? 1000? Having to constantly add new trusted certificates is a ;TI"Mpain, and it actually makes the trust system less secure by encouraging ;TI"6RubyGems users to blindly trust new certificates.;T@o; ;[ I"RHere's where certificate chains come in. A certificate chain establishes an ;TI"Parbitrarily long chain of trust between an issuing certificate and a child ;TI"Qcertificate. So instead of trusting certificates on a per-developer basis, ;TI"Rwe use the PKI concept of certificate chains to build a logical hierarchy of ;TI"Ptrust. Here's a hypothetical example of a trust hierarchy based (roughly) ;TI"on geography:;T@o;;[I"4 -------------------------- ;TI"3 | rubygems@rubygems.org | ;TI"4 -------------------------- ;TI"' | ;TI"7 ----------------------------------- ;TI"7 | | ;TI"E ---------------------------- ----------------------------- ;TI"E | seattlerb@seattlerb.org | | dcrubyists@richkilmer.com | ;TI"E ---------------------------- ----------------------------- ;TI"? | | | | ;TI"G--------------- ---------------- ----------- -------------- ;TI"G| drbrain | | zenspider | | pabs@dc | | tomcope@dc | ;TI"G--------------- ---------------- ----------- -------------- ;T;0o; ;[I"QNow, rather than having 4 trusted certificates (one for drbrain, zenspider, ;TI"Fpabs@dc, and tomecope@dc), a user could actually get by with one ;TI":certificate, the "rubygems@rubygems.org" certificate.;T@o; ;[I"Here's how it works:;T@o; ;[ I"QI install "rdoc-3.12.gem", a package signed by "drbrain". I've never heard ;TI"Fof "drbrain", but his certificate has a valid signature from the ;TI"Q"seattle.rb@seattlerb.org" certificate, which in turn has a valid signature ;TI"Pfrom the "rubygems@rubygems.org" certificate. Voila! At this point, it's ;TI"Qmuch more reasonable for me to trust a package signed by "drbrain", because ;TI"JI can establish a chain to "rubygems@rubygems.org", which I do trust.;T@S; ; i; I"Signing certificates;T@o; ;[ I"LThe --sign option allows all this to happen. A developer ;TI"Pcreates their build certificate with the --build option, then ;TI"Phas their certificate signed by taking it with them to their next regional ;TI"MRuby meetup (in our hypothetical example), and it's signed there by the ;TI"Rperson holding the regional RubyGems signing certificate, which is signed at ;TI"Pthe next RubyConf by the holder of the top-level RubyGems certificate. At ;TI"1each point the issuer runs the same command:;T@o;;[ I"A# sign a certificate with the specified key and certificate ;TI"2# (note that this modifies client_cert.pem!) ;TI"J$ gem cert -K /mnt/floppy/issuer-priv_key.pem -C issuer-pub_cert.pem ;TI" --sign client_cert.pem ;T;0o; ;[ I"QThen the holder of issued certificate (in this case, your buddy "drbrain"), ;TI"Ocan start using this signed certificate to sign RubyGems. By the way, in ;TI"Morder to let everyone else know about his new fancy signed certificate, ;TI":"drbrain" would save his newly signed certificate as ;TI",~/.gem/gem-public_cert.pem;T@o; ;[ I"OObviously this RubyGems trust infrastructure doesn't exist yet. Also, in ;TI"Nthe "real world", issuers actually generate the child certificate from a ;TI"Mcertificate request, rather than sign an existing certificate. And our ;TI"Mhypothetical infrastructure is missing a certificate revocation system. ;TI"1These are that can be fixed in the future...;T@o; ;[I"NAt this point you should know how to do all of these new and interesting ;TI" things:;T@o;;;;[ o;;0;[o; ;[I",build a gem signing key and certificate;To;;0;[o; ;[I" adjust your security policy;To;;0;[o; ;[I")modify your trusted certificate list;To;;0;[o; ;[I"sign a certificate;T@S; ; i; I""Manually verifying signatures;T@o; ;[I"MIn case you don't trust RubyGems you can verify gem signatures manually:;T@o;;: NUMBER;[ o;;0;[o; ;[I"Fetch and unpack the gem;T@o;;[I"gem fetch some_signed_gem ;TI"%tar -xf some_signed_gem-1.0.gem ;T;0o;;0;[o; ;[I")Grab the public key from the gemspec;T@o;;[I"5gem spec some_signed_gem-1.0.gem cert_chain | \ ;TI"J ruby -ryaml -e 'puts YAML.load_documents($stdin)' > public_key.crt ;T;0o;;0;[o; ;[I",Generate a SHA1 hash of the data.tar.gz;T@o;;[I"0openssl dgst -sha1 < data.tar.gz > my.hash ;T;0o;;0;[o; ;[I"Verify the signature;T@o;;[I" verified.hash ;T;0o;;0;[o; ;[I"+Compare your hash to the verified hash;T@o;;[I"#diff -s verified.hash my.hash ;T;0o;;0;[o; ;[I"$Repeat 5 and 6 with metadata.gz;T@S; ; i; I"OpenSSL Reference;T@o; ;[I"MThe .pem files generated by --build and --sign are PEM files. Here's a ;TI"=couple of useful OpenSSL commands for manipulating them:;T@o;;[ I"># convert a PEM format X509 certificate into DER format: ;TI"F# (note: Windows .cer files are X509 certificates in DER format) ;TI"?$ openssl x509 -in input.pem -outform der -out output.der ;TI" ;TI"=# print out the certificate in a human-readable format: ;TI"/$ openssl x509 -in input.pem -noout -text ;T;0o; ;[I"EAnd you can do the same thing with the private key file as well:;T@o;;[ I"5# convert a PEM format RSA key into DER format: ;TI"F$ openssl rsa -in input_key.pem -outform der -out output_key.der ;TI" ;TI"5# print out the key in a human readable format: ;TI"2$ openssl rsa -in input_key.pem -noout -text ;T;0S; ; i; I"Bugs/TODO;T@o;;;;[o;;0;[o; ;[I"7There's no way to define a system-wide trust list.;To;;0;[o; ;[I"5custom security policies (from a YAML file, etc);To;;0;[o; ;[I";Simple method to generate a signed certificate request;To;;0;[o; ;[I"KSupport for OCSP, SCVP, CRLs, or some other form of cert status check ;TI"%(list is in order of preference);To;;0;[o; ;[I"'Support for encrypted private keys;To;;0;[o; ;[I"KSome sort of semi-formal trust hierarchy (see long-winded explanation ;TI" above);To;;0;[o; ;[ I"NPath discovery (for gem certificate chains that don't have a self-signed ;TI"Proot) -- by the way, since we don't have this, THE ROOT OF THE CERTIFICATE ;TI"PCHAIN MUST BE SELF SIGNED if Policy#verify_root is true (and it is for the ;TI".MediumSecurity and HighSecurity policies);To;;0;[o; ;[I"GBetter explanation of X509 naming (ie, we don't have to use email ;TI"addresses);To;;0;[o; ;[I"0Honor AIA field (see note about OCSP above);To;;0;[o; ;[I"!Honor extension restrictions;To;;0;[o; ;[I"KMight be better to store the certificate chain as a PKCS#7 or PKCS#12 ;TI"8file, instead of an array embedded in the metadata.;To;;0;[o; ;[I"KFlexible signature and key algorithms, not hard-coded to RSA and SHA1.;T@S; ; i; I"Original author;T@o; ;[I"&Paul Duncan ;TI"http://pablotron.org/;T: @fileI"lib/rubygems/security.rb;T:0@omit_headings_from_table_of_contents_below0o;;[;I"&lib/rubygems/security/policies.rb;T;0;0;0[[U:RDoc::Constant[iI"DIGEST_ALGORITHM;FI"$Gem::Security::DIGEST_ALGORITHM;T00o;;[o; ;[I"'Digest algorithm used to sign gems;T;@Ù;0@Ù@cRDoc::NormalModule0U;[iI"KEY_ALGORITHM;FI"!Gem::Security::KEY_ALGORITHM;T00o;;[o; ;[I":Algorithm for creating the key pair used to sign gems;T;@Ù;0@Ù@@è0U;[iI"KEY_LENGTH;FI"Gem::Security::KEY_LENGTH;T00o;;[o; ;[I",Length of keys created by KEY_ALGORITHM;T;@Ù;0@Ù@@è0U;[iI"KEY_CIPHER;FI"Gem::Security::KEY_CIPHER;T00o;;[o; ;[I"