U:RDoc::NormalModule[iI"
Security:EFI"Gem::Security;F0o: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 <code>gem cert --add signing_cert.pem</code> 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"P<code>signing_key</code> and <code>cert_chain</code> in the gemspec before ;TI"packaging your gem:;T@o;;[I";s.signing_key = '/secure/path/to/gem-private_key.pem'
;TI"<s.cert_chain = %w[/secure/path/to/gem-public_cert.pem]
;T;0o;
;[I"RWhen you package your gem with these options set RubyGems will automatically ;TI"9load your key and certificate from the secure paths.;T@S;	;
i;I"&Signed gems and security policies;T@o;
;[I"PNow let's verify the signature.  Go ahead and install the gem, but add the ;TI"@following options: <code>-P HighSecurity</code>, 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 <code>-P</code> 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 <code>gem help cert</code>:;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 <code>--build</code> option, and the ;TI"Q<code>--add</code>, <code>--list</code>, and <code>--remove</code> 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" <code>--sign</code> 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 <code>--sign</code> option allows all this to happen.  A developer ;TI"Pcreates their build certificate with the <code>--build</code> 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",<code>~/.gem/gem-public_cert.pem</code>;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"<openssl rsautl -verify -inkey public_key.crt -certin \
;TI"+  -in data.tar.gz.sig > 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 <pabs@pablotron.org> ;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;F00o;;[o;
;[I"'Digest algorithm used to sign gems;T;@Ù
;0@Ù
@cRDoc::NormalModule0U;[iI"KEY_ALGORITHM;FI"!Gem::Security::KEY_ALGORITHM;F00o;;[o;
;[I":Algorithm for creating the key pair used to sign gems;T;@Ù
;0@Ù
@@è
0U;[iI"KEY_LENGTH;FI"Gem::Security::KEY_LENGTH;F00o;;[o;
;[I",Length of keys created by KEY_ALGORITHM;T;@Ù
;0@Ù
@@è
0U;[iI"KEY_CIPHER;FI"Gem::Security::KEY_CIPHER;F00o;;[o;
;[I"<Cipher used to encrypt the key pair used to sign gems. ;TI"<Must be in the list returned by OpenSSL::Cipher.ciphers;T;@Ù
;0@Ù
@@è
0U;[iI"
ONE_YEAR;FI"Gem::Security::ONE_YEAR;F00o;;[o;
;[I"One year in seconds;T;@Ù
;0@Ù
@@è
0U;[iI"EXTENSIONS;FI"Gem::Security::EXTENSIONS;F00o;;[o;
;[I"'The default set of extensions are:;T@o;;;;[o;;0;[o;
;[I"3The certificate is not a certificate authority;To;;0;[o;
;[I"KThe key for the certificate may be used for key and data encipherment ;TI"and digital signatures;To;;0;[o;
;[I"6The certificate contains a subject key identifier;T;@Ù
;0@Ù
@@è
0U;[iI"NoSecurity;FI"Gem::Security::NoSecurity;F00o;;[o;
;[I"CNo security policy: all package signature checks are disabled.;T;@Ü
;0@Ü
@@è
0U;[iI"AlmostNoSecurity;FI"$Gem::Security::AlmostNoSecurity;F00o;;[o;
;[I"OAlmostNo security policy: only verify that the signing certificate is the ;TI"Oone that actually signed the data.  Make no attempt to verify the signing ;TI"certificate chain.;T@o;
;[I"MThis policy is basically useless. better than nothing, but can still be ;TI",easily spoofed, and is not recommended.;T;@Ü
;0@Ü
@@è
0U;[iI"LowSecurity;FI"Gem::Security::LowSecurity;F00o;;[o;
;[I"OLow security policy: only verify that the signing certificate is actually ;TI"?the gem signer, and that the signing certificate is valid.;T@o;
;[I"NThis policy is better than nothing, but can still be easily spoofed, and ;TI"is not recommended.;T;@Ü
;0@Ü
@@è
0U;[iI"MediumSecurity;FI""Gem::Security::MediumSecurity;F00o;;[o;
;[I"PMedium security policy: verify the signing certificate, verify the signing ;TI"Pcertificate chain all the way to the root certificate, and only trust root ;TI"<certificates that we have explicitly allowed trust for.;T@o;
;[I"OThis security policy is reasonable, but it allows unsigned packages, so a ;TI"Mmalicious person could simply delete the package signature and pass the ;TI"gem off as unsigned.;T;@Ü
;0@Ü
@@è
0U;[iI"HighSecurity;FI" Gem::Security::HighSecurity;F00o;;[o;
;[	I"NHigh security policy: only allow signed gems to be installed, verify the ;TI"Nsigning certificate, verify the signing certificate chain all the way to ;TI"Ithe root certificate, and only trust root certificates that we have ;TI""explicitly allowed trust for.;T@o;
;[I"PThis security policy is significantly more difficult to bypass, and offers ;TI"Oa reasonable guarantee that the contents of the gem have not been altered.;T;@Ü
;0@Ü
@@è
0U;[iI"SigningPolicy;FI"!Gem::Security::SigningPolicy;F00o;;[o;
;[I"CPolicy used to verify a certificate and key when signing a gem;T;@Ü
;0@Ü
@@è
0U;[iI"
Policies;FI"Gem::Security::Policies;F00o;;[o;
;[I")Hash of configured security policies;T;@Ü
;0@Ü
@@è
0[[[I"
class;T[[:public[[I"alt_name_or_x509_entry;FI"lib/rubygems/security.rb;T[I"create_cert;F@Š[I"create_cert_email;F@Š[I"create_cert_self_signed;F@Š[I"create_key;F@Š[I"email_to_name;F@Š[I"re_sign;F@Š[I"
reset;F@Š[I"	sign;F@Š[I"trust_dir;F@Š[I"trusted_certificates;F@Š[I"
write;F@Š[:protected[[:private[[I"
instance;T[[;[[;[[;[[[U:RDoc::Context::Section[i0o;;[;0;0[
I"+lib/rubygems/install_update_options.rb;TI"lib/rubygems/package.rb;TI" lib/rubygems/package/old.rb;T@Ù
@Ü
I"$lib/rubygems/security/policy.rb;TI"$lib/rubygems/security/signer.rb;TI"'lib/rubygems/security/trust_dir.rb;TI"Gem;F@è