[CentOS] A couple of minutes on GnuPG and signing files

There has been a notice of a breach (see: CVE-2007-4752) as to 
some binary content upstream of CentOS. I do not address that 
matter here beyond stating that the CentOS team have responded 
to the matter, and will continue this review process:

 	updated 22 Aug 2008 CentOS acknowledge CVE-2007-4752 and are
 	reviewing our build and signing processes and hosts for signs
 	of tampering subsequent to retrieval of SRPMs

It can be hard for a person to get a capsule writeup on signed 
content, and how to verify that it is indeed authentic.  I 
have placed clearsigned content addressing this process at my 
personal domain webserver:

 	http://www.herrold.com/import-key-howto.txt.asc

and as an attachment to this email. I have verified that the 
copy at my site verifies.  this email.  Hopefully this attched 
writeup will transit the CentOS mailing list manager intact. 
I also include it inline below, but this may mangle the 
signature.

-- Russ herrold

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



A few minutes on using detached and clearsigned content.

In light of today's CVE-2007-4752 by the CentOS project's upstream:
      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4752
I issue this brief piece on using GnuPG


1. View a proposed key to use, at the MIT keyserver

from: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x650D5882


2. Copy and create a local instance

[herrold at centos-5 redhat]$ vi rht-key

[herrold at centos-5 redhat]$ gpg --import rht-key
gpg: key 650D5882: duplicated user ID detected - merged
gpg: key 650D5882: public key "Red Hat, Inc. (Security Response Team)
<secalert at redhat.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0  valid:   2  signed:   5  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1  valid:   5  signed:   2  trust: 0-, 0q, 0n, 1m, 4f, 0u
gpg: next trustdb check due at 2009-03-14


3. Compute a local fingerprint of the candidate

[herrold at centos-5 redhat]$ gpg --fingerprint  650D5882
pub   1024D/650D5882 2001-11-21
       Key fingerprint = 9273 2337 E5AD 3417 5265  64AB 5E54 8083 650D 5882
uid                  Red Hat, Inc. (Security Response Team)
<secalert at redhat.com>
sub   2048g/7EAB9AFD 2001-11-21

[herrold at centos-5 redhat]$


4. Compare and validate the fingerprint of the candidate against the RHT
statement of the same fingerprint:

 	http://www.redhat.com/security/team/key/


5. You do NOT need to accept a key permanently to check signed content
purportedly with it; consider the Red Hat notice at:
 	http://www.redhat.com/security/data/openssh-blacklist.html


6. We can retrieve the checking script

 	wget https://www.redhat.com/security/data/openssh-blacklist-1.0.sh

and the (presumptively) signed checksum of that file

 	wget https://www.redhat.com/security/data/openssh-blacklist-1.0.sh.asc

This is called a detached signature


7. And then we can validate ('--verify') that the signature and the file were
signed by a person in possession of the private key.

Hopefully that private key is itself protected, as behind one way firewalls,
and with a 'pass phrase' which matches a known public (which we retrieved
and added earlier).  This procedural security process is followed by me [one
way firewalls, and pass phrases, and other CentOS team members], along with
other measures.

[herrold at centos-5 redhat]$ gpg  --verify openssh-blacklist-1.0.sh.asc \
 	openssh-blacklist-1.0.sh
gpg: Signature made Fri 22 Aug 2008 05:02:29 AM EDT using DSA key ID
650D5882
gpg: Good signature from "Red Hat, Inc. (Security Response Team)
<secalert at redhat.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 9273 2337 E5AD 3417 5265  64AB 5E54 8083 650D 5882
[herrold at centos-5 redhat]$


8. As we have not indicated to gpg that we permanently trust this key, gpg
adds the WARNING -- this is expected and correct under this outline.  The
validation checks out.


9. This file can be clearsigned -- the process we will follow is this:

[herrold at centos-5 .gnupg]$ gpg --clearsign import-key-howto.txt

You need a passphrase to unlock the secret key for
user: "R P Herrold <herrold at owlriver.com>"
1024-bit DSA key, ID 9B649644, created 2003-02-09

File 	`import-key-howto.txt.asc' exists. Overwrite? (y/N) y
[herrold at centos-5 .gnupg]$


10. That is, import-key-howto.txt is clearsigned, and a new file, 
import-key-howto.txt.asc, is produced.  As I did it twice, to add this text,
the warning about Overwriting a file appeared.


11. This is a non-detached (clearsigned, file, and might also be tested by
retrieving the indicated key contents, and doing a '--verify'


12. As I have previously certified my own key, I can do it more simply
locally:

[herrold at centos-5 .gnupg]$ gpg --verify import-key-howto.txt.asc
gpg: Signature made Fri 22 Aug 2008 12:37:39 PM EDT using DSA key ID
9B649644
gpg: Good signature from "R P Herrold <herrold at owlriver.com>"
[herrold at centos-5 .gnupg]$

Note that the TIME of the signing will vary, as I have to resign the file
after adding this content.


13. Previously (prior to 22 Aug 2008), I have included my PGP details in
every piece of email I send.  Starting today, as to email originate; I will
add another line with my GPG details as well.  I will send this document to
the main centos mailing list.

Date: Thu, 21 Aug 2008 17:43:28 -0400 (EDT)
From: R P Herrold <herrold at owlriver.com>
To: trading-shim general mailing list <ts-general at trading-shim.org>
Subject: segmentation faults
In-Reply-To: <1219351509.12150.18.camel at gb07>
Message-ID: <alpine.LRH.1.999.0808211742100.2443 at arj.bjyevire.pbz>
References: <200808202117.m7KLH4rf011059 at pippin.first.lan>
     <20080820224216.GA11712 at localhost>
     <alpine.LRH.1.10.0808202147340.28881 at arj.bjyevire.pbz>
     <1219351509.12150.18.camel at gb07>
User-Agent: Alpine 1.999 (LRH 1145 2008-08-19)
X-M: Go Blue
X-OpenPGP-Key-ID: 0x7BFB98B9
MIME-Version: 1.0


In pine (alpine), one does this with Customized X-headers:

Customized Headers                  = X-M: Go Blue
                                       X-GnuPG-GPG-Key-ID: ox9B649644
                                       X-OpenPGP-Key-ID: 0x7BFB98B9

This piece intentionally does not address CentOS response; a preliminary
statement on this has been posted in the /topic of the IRC channel #centos
on irc.freenode.org, and I have done a blog losting which is up at:
http://planet.centos.org/


- -- Russ herrold
         herrold at owlriver.com
         herrold at centos.org
         security at centos.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFIru4fMRh1QZtklkQRAgj6AJ9PDJFL59L2WEpzq3f5t93jUf2SrQCePAjm
k8mX//167cFOTV0oF6TJFR8=
=LFRY
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: import-key-howto.txt.asc
URL: <http://lists.centos.org/pipermail/centos/attachments/20080822/cbe1ba1b/attachment.asc>