"latest and greatest" disease

RIMM, the maker of the popular 'Blackberry' smartphone, seems to have forgotten what we all have known for a long, long time. In recent models, they moved from a roller clickwheel at the right thumb position, to a set of 'up and down' buttons, or a trackball.

Less precise, and less capable: The clickwheel could be operated by touch alone; the new variants cannot.

Making matters worse, seemingly no-one at RIMM ever is in a environment where their hands pick up grime. This grime, of course, transfers to the trackball.

The trackball is not field cleanable; compare contra the 'remove and clean' capabilities of a computer mouse. I see: Broken BlackBerry Blues over at thestreet.com today.

Time to 'stock up' with a couple unlocked '8700's off ebay, in advance of the day I lose or damage my current device.

Bus test

A recent questioner in the CentOS forums complained about the decision to carry older versions of Unix network services, rather than the 'latest and greatest'.

That person said the package was:
> dead stable
as though it was a criticism. CentOS is not and will never be anything but boring, predictable, and dead stable.

The use case was:
> it will be used as an email server for a small business
without any rationale on why a later version is needed. Security matters are backported, as part of the CentOS upstream's approach on an Enterprise grade operating system. CentOS dutifully issues said updates after a quick trip of a SRPM through the build process (trade mark elidement, signing, and other validity checking; announcement), and sends it off to the 'updates' mirror network, for yum to find.

One goal of consulting for third party clients is to hold costs down and yet meet requirements. Anything more, and the consultant may be learning, but the client's best interest is not being served.

Either the client is being charged while the consultant 'plays', or if not being charged, their business is (unknowingly) being used as a 'crash test dummy' venue for such exploration. Not good.

Consider the 'bus test':

What happens when a bus sideswipes the consultant, who is then out of commission for a month during recovery? [I know of other formulations of the 'bus test', of a more gruesome nature, but they are not needed for this hypothetical ;) ]

By forking as little as possible, nothing bad happens to the client.

Seems like a win to me.

Now, where did my coffee cup disappear to?

'whipped like a rented mule'

... pretty well describes the way I felt most of last week.

One of my children commented that I had 'racoon eyes' when they stopped by the house; I was collapsing on the couch after dinner, only to awaken after nightfall, and retire to bed.

Finally the weekend arrived, and I made up the sleep deficit a bit. Made a run to the liquor store as well. I was looking for Seagram's 7 Crown, a favorite Blended Canadian Whisky, for a tall, cool '7 and 7'

None to be found. The store had a 'special rebate coupon' on Canadian Club in the 1.75 L size, so I picked up that instead as a 'tide me over', and a Wild Turkey 101, my sentimental favorite for an 'on the rocks' drink.

The store does have Lagavulin 16 at a fairly reasonable price, but in taking inventory before my trip to the store, I have two pleasant 'straight up' choices, and three bottles of less appealing Scotch to work through first. Truth be known, those last three will probably be consigned to the kitchen for holiday 'Scotch ball' cookies.

... later ... that Canadian Club is drinkable, but not something I'll be buying over 7 Crown. At least there is that rebate.

Adding a signing key to RPM

A common (and commonly ignored) step when rebuilding Source RPMs from a remote archive is that of verification of the authenticity of the content.

An archive maintainer may choose to sign, or to not sign RPM (and thus SRPM) content it releases. Implicitly, an archive which does sign its content provides a way for a consumer of that content, remote in time or at another site, to verify the authenticity, integrity, and provenance of that package. An earlier post discussed using GPG to verify signed content generally.

The RPM package manager has long had the ability (similar to GnuPG) to receive GPG public keys into its trusted store, and then to test assertions about the presence, absence, and validity of a given signing. It can retrieve a remote key with the usual RPM network retrieval capabilities, or perhaps better to avoid MitM ('Man in the Middle') compromises across a network, from the local filesystem, or a local piece of immutable media, such as a CD which has had its md5sum verified.

Hughesjr covered it when 'near' to the install process. I covered CentOS key imports, but did not there mention checking key fingerprints and adding keys for other archives, which provoked some grouchiness later in that thread.

Let's take another swing at it here, and work an example, to manually retrieve a Red Hat 'RawHide' signing public key, of which the matching private key was assumedly used to 'sign' a package from the RawHide archive. This article uses the term: we to mark steps which the reader might safely attempt on their local box. From following Fedora, and from prior work on the old RHL testers-list team, we may believe that Fedora signatures on Red Hat content in RawHide are not unexpected. Let's be a bit more formal.

[herrold@centos-5 rpmlint]$ rpm -Kv rpmlint-0.82-3.fc9.src.rpm
rpmlint-0.82-3.fc9.src.rpm:
    Header V3 DSA signature: OK, key ID 4f2a6fd2
    Header SHA1 digest: OK (8d753729ecfc59620fca2ccc1018e767787da9a6)
    MD5 digest: OK (7d8b212cc68ff675fd64b124d832c423)
    V3 DSA signature: OK, key ID 4f2a6fd2
[herrold@centos-5 rpmlint]$

So RPM informs us that the the 'fingerprint' of the keypair element which was used to sign that package is: 0x4f2a6fd2 Please note that in this piece, as with hexadecimal numbers generally, upper and lower A through F are interchangeable. Also, this piece flags 'hex' numbers with the conventional: 0x

Part of the RPM package signing process requires unlocking a GPG private key (if so protected with a passphrase), and so to permit RPM to sign content using that key. If a private key were NOT so protected with a passphrase, even more obvious (and potentially undetectable) problems exist, as a non-passphrase protected key might be silently copied and thereafter used by a malicious third party.

Aside on passphrases and signing keys: In recent days, both Red Hat and Fedora have recently revoked many of their signing keys, due to separate potential compromises of the signing processes for these two entities.

Some press reports suggest that an unauthorized insertion was made into the Red Hat CVS server [a trapdoor bypass after the 'pam' authentication checking return], and that a binary RPM package containing that exploit was presented to, and made it through the signing process. One might speculate that a developer may have unknowingly used least one cracked sshd server [consider, say, e.g., via a 'small sshd keyspace' Debian gateway, then exploited] through which passwords, passphrase keystrokes and so forth may have transited. For a person with 'root' level access to a Linux host, it is reasonably straightforward to add a malicious silent capability to also silently log keystrokes.

Later on, with credentials in hand, doing a malicious CVS commit in the account rights of another is trivial; non-trivial to understand is how a build came to be enqueued to the signing process was authorized and happened and a signing occurred on the Enterprise product at Red Hat. It further appears from some statements that the signed trojaned binary was accessible within the general internal network at Red Hat, and may have been able to 'escape into the wild' or was harvested by persons presently unknown. Under such a possible fact pattern, the revocation of the signing keys is a wholly responsible and proper response by Red Hat. The Fedora details are less well explained publicly presently, but one hopes a more complete description will emerge as time passes.

Using Google and the search argument: 4f2a6fd2 key fingerprint, I find a seemingly authoritative statement of Fedora keys, matching the key fingerprint of the package in question. A check of the domain registration indicates that it is under the control of Red Hat (owner of the Fedora project):

[herrold@centos-5 ~]$ whois fedoraproject.org
[Querying whois.publicinterestregistry.net]
[whois.publicinterestregistry.net]
   ... snip ... 
Domain ID:D101496757-LROR
Domain Name:FEDORAPROJECT.ORG
Created On:24-Sep-2003 10:32:11 UTC
Last Updated On:10-Jun-2008 20:25:33 UTC
Expiration Date:24-Sep-2009 10:32:11 UTC
Sponsoring Registrar:Network Solutions LLC (R63-LROR)
Status:CLIENT TRANSFER PROHIBITED
Registrant ID:41295926-NSI
Registrant Name:Red Hat, Inc.
Registrant Organization:Red Hat, Inc.
Registrant Street1:1801 Varsity Drive
Registrant City:Raleigh
Registrant State/Province:NC
Registrant Postal Code:27606
Registrant Country:US
Registrant Phone:+1.919754370
Registrant FAX:+1.919754370
Registrant Email:domainadmin@redhat.com
   ... snip ... 

Both new and former keys seem to be enumerated at that webpage. The SSL certificate respecting this website seems to have been counter-signed by a commercial third party in the business of running a certificate Authority, Equifax. At the date of writing, this signing and the certificat itself are each unrevoked.

As such, we can reasonably conclude this is an authoritative website.

The Fedora project administrators additionally published a key yielding that fingerprint to the GPG keyserver network. Querying with: 0x4F2A6FD2, we are offered both the key content, and also a record of countersigning of persons asserting that they have been furnished sufficient credible evidence that the Fedora key is authentic.

Let's retrieve a candidate key into a local file:

[herrold@centos-5 rpmlint]$ wget -O Fedora-key \
    "http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4F2A6FD2"
[herrold@centos-5 rpmlint]$ 

We locally compute the 'fingerprint' of that key file, to give us some assurance that there was not some hostile MitM when we did this non-SSL retrieval.

[herrold@centos-5 rpmlint]$ gpg Fedora-key
pub  1024D/4F2A6FD2 2003-10-27 Fedora Project 
sub  1024g/FB939E34 2003-10-27
[herrold@centos-5 rpmlint]$

and the anticipated 'pub' fingerprint value is returned: 0x4F2A6FD2

But is it really, really that of Fedora? Looking further at the MIT keyserver website, I see that I 'know' and trust another of the cross-signers of that key:

Public Key Server -- Verbose Index ``0x4F2A6FD2 ''

Type bits /keyID    Date       User ID
pub  1024D/4F2A6FD2 2003/10/27 Fedora Project 
   ... snip ...
sig        DB42A60E             Red Hat, Inc 
 ... snip ...

I happen to have a chain of pressed original distribution CDs from Red Hat (which have carried its then current key on that immutable media for many years, over many generations). It makes sense, at a trade show, to obtain and keep such a CD, often handed out as a 'sample' for the key it contains. Since Red Hat Security is a endorsing signer of that Fedora key, and since I can verify an unbroken chain forward to the present values at the Red Hat Security key page, I am comfortable at the authenticity of the key offered at the MIT keyserver under that fingerprint.

That is, I am now willing to concur that content signed with a key producing that fingerprint is authentic content from the Fedora project.

As such, we temporarily assume root rights to get write access to the RPM database, and import the key held in a local file into that RPM database:

[herrold@centos-5 rpmlint]$ sudo rpm --import  Fedora-key
[herrold@centos-5 rpmlint]$

[herrold@centos-5 rpmlint]$ rpm -qa gpg\*
gpg-pubkey-e8562897-459f07a4
gpg-pubkey-4f2a6fd2-3fcdf8c9
[herrold@centos-5 rpmlint]$ rpm -qi gpg-pubkey-4f2a6fd2-3fcdf8c9
Name        : gpg-pubkey                   Relocations: (not relocatable)
Version     : 4f2a6fd2                          Vendor: (none)
Release     : 3fcdf8c9                      Build Date: Tue 09 Sep 2008 12:52:19 PM EDT
Install Date: Tue 09 Sep 2008 12:52:19 PM EDT      Build Host: localhost
Group       : Public Keys                   Source RPM: (none)
Size        : 0                                License: pubkey
Signature   : (none)
Summary     : gpg(Fedora Project )
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.4.2 (beecrypt-4.1.2)

mQGiBD+dnTsRBACwnlz4AhctOLlVBAsq+RaU82nb5P3bD1YJJpsAce1Ckd2sBUOJD11NUCqH
8c7EctOquOZ5zTcWxHiWWbLyKQwUw2SUvnWa5SSbi8kI8q9MTPsPvhwtgMrQMLenMO+nsrxr
SaG6XcD+ssfJNxC7NQVCQAj3pvvg9rKi3ygsM7CXHwCghgsqX6TOr55HE90DbEsoq3b/jjsD
/i8aIZ6urUgrpAkQslcakXdJLKgSdwjRUgVZgvYZb7kAx1iPq0t/AhB3NJw3zW4AAKJohGg3
xj5K4V8PJEZrSIpoRYlF43Kqlfu2p5ghWT89SP4YAlWPeTqf0+dTYUYz3b144k2ZFOdRuXIR
xunoYNAUr9oMrxBXbJ/eY+0UQX3pBACYzKizyY4JJgd0zFJmNkcdK9nzcm+btYFnYQo33w5G
SE686UNr+9yiXt9tmPRvNEbj3u+xoAX8B/5k3aZ5NbUhV64/VcKlUdRIxNlFCG7I9KgxeHWA
Ywi7yqOGXM3T/v6o7GLdQEB0ChFqS7kUlqmwLV+C3QhlrFe/Cuk26i+Q6rQiRmVkb3JhIFBy
b2plY3QgPGZlZG9yYUByZWRoYXQuY29tPokCHAQQAQIABgUCQCztZwAKCRDdE2MqcWVuaC26
D/0abz5VhIh2eOsTpI3vTlHJQpe3Cx5qyLJ5oFaUFbjVIU0L5Vt9dcrmXvzAoa4czZxtPcbo
7wWvENCA3tpcdB83zPqaD9VDEZrjoFzNLL8pK2Kl73/IcMkf/UHGpcJCWoftag0Zq5AngZgH
0Voe6YAreVPBYFSIaZhSCEaYEb8ejOwdAeYc7b01e/43TLfRmoeQMFoH/rZUqcLJXfHyi3Kk
CGZXWfwYkQiGsy5pMT7c4WzIwNZju7QaRJcNcB9y1FHGnkaz6we4dkh79sqRvn82dxgXbLa1
rR/m6g20m/uuOrhHle7gsMtmmQAmaUTes54HDdlDe2JdL7dTqOhXX8mF3rf4j9BVv/Vz2y4E
wBE7JVqPYHT7HDolQ80OxEamJDuo3h5hgPxsmPZ2JZRLzZKeuq43xz8gJlcB4vpS6Q7j15FB
5trQ6iKTIWzWSqV5zBahG6qJ4RN1ubJzSzOgNIycJ0uFZZ5rnYIyowqTwmzGU8VZphrz3436
lYlQ4sDnluIlYB8mxZHZz2+k3E38PHgqobXa7Al/5kSQ4owTyfo7+IvxHkSbIA5yQpdWmV8/
QJpp7PlcvBlYyvwzXNgj6hGu1XOjSw4AxXtHgmQOya4Q+ktARfWL0wfP/ocdvdkHajiRv9sp
59C/Ir5/zmTmgQeEudous19MaMP43AKqj3Z2/IicBBABAgAGBQJB3c/dAAoJEJhqQe8YjLfJ
fTcEAKQ6q/+LuNxz5X4nX0S+6s8pxshdUUTcFQnN013ZdJ7HBJIt/GZSbyXm5dsWdmvne9vA
2Gfo2glP4HtVvEBbmT9vCKC/V8aI1QF/aTcVwdUaXzIj2rG9dl63LCLl/o9hBa3zPOL80kaS
yjPGMuKBM/UzRAVFjVihd0G8gPsopGSuiEYEEBECAAYFAj+e2OAACgkQKdW6JI31bQVRJQCg
meuid7gnSjUcyRHP7qD0pW47YXIAnRfJ5s7NWYj1Tk7I5+c2ZhXTCdByiEYEEBECAAYFAkBp
vjQACgkQcdLUaCBIxSjrhwCeMzGZSA+xfgL03obWLbZN6QtlnpoAnj4aA0MkT6/oqiJOEQp0
3uh7KMrciEYEEBECAAYFAkCo71wACgkQXanJZSIKP4/TKQCfUQmD5oobxJQKCoy/g9aHryQQ
q/QAnjK7ql0wBaO6Z45yggecwHAP5Wm2iEYEEBECAAYFAkEU8TsACgkQ3GVW6BHmDogH4QCf
Y4tpxjMm9EYa98IWaPwaFW59OvkAoMynGza4cvZOTSrvFV9teWfv5r7AiEYEEBECAAYFAkEU
8U4ACgkQZGYqnQA+HZ26AwCfVW71WRotzZI74EKmclttXve6WHgAnj8GrScGsOyLUbcGaiPN
yu1NWdRGiEYEEBECAAYFAkEU8VoACgkQiEVN9vr2r+PzUQCfSKSK0ZJ/cf+YdvrHyxcABg8p
WZwAn1FnhKQ1AW90BLXkhGpNy7nNO+ZaiEYEEBECAAYFAkEU8WUACgkQ0ptfRip0+Q2JBwCg
ksE9QoxWQwaRJApr+Qp/k4K8VnwAoKYlK6AvAdeiOKOHlM+eCQ7F3ZBniEYEEBECAAYFAkF6
JkgACgkQUdrzTXusf2wqsQCgiLp1BCmfVnOjDeis49xCIMPNmCcAoILl+XvzwO6Fp3JHCghn
dJ3SCycbiEYEEBECAAYFAkG0c74ACgkQ+lAXgUiSypriPACdHwfmU390R8YWPg3f9uHzWP+i
CaIAoIOXgZDN2JimS8za9+IFjzz+xQ/SiEYEEBECAAYFAkHdz30ACgkQ9tuOJwRFhLVkgwCg
v/57BB269RcFh6fTucG1Q9kfVTgAn2z6rYMpbmodRUlbV1zifctGIKBUiEYEEBECAAYFAkIN
VnAACgkQhfn5/UKaxrY0NwCg3QZqs09BvyYFmLssuEhH0fN1h9MAoNjfBazVPxZRLZSZpPPZ
mF/AUCv+iEYEEBECAAYFAkJA1zIACgkQ/RiBB2NcQIpPRACfUSPNfj8tJLky/QT0c425M/4a
6QsAn1wARHuu4Ns0AkQJ7qA3uHc619dGiEYEEBECAAYFAkJdM08ACgkQaajtSerafFlzwQCg
tKtlxNPhH4TUj+qOg/7Gul9fLIAAnj5Xz8m83GclDmhmpPNXkTWuetugiEYEEBECAAYFAkLW
jJ8ACgkQbGUs+HTfTWsOUgCgik2nqZNx7DbYYHB001sOVTMzIRwAn2vL3TUQmdELn+0yizuf
L0ANHL3tiEYEEBECAAYFAkRf5AoACgkQi9gubzC5S1zlxQCfehVXfZ7C4VoEoEkorx5i+oWP
4u4AnjF1CdHeHnUEtn+ar1Q4HKkuDU1biEYEEBECAAYFAkTkVbwACgkQ5aYV37hLgJBEPgCg
g3qHa3Au96/Ycj45/t5pjSN4/f4Ani3cFmiDRiOU7wZxe9zPaqpD6KdmiEYEEBECAAYFAkU5
xIMACgkQZ/MxGm4PtJQBdgCfZunvqtB1/ff6wgWRWqtVsMlenDAAn2shRndxeHiGuxgu+4N8
jxwsDNG3iEYEEBECAAYFAkgqa5cACgkQqSqC6eLqddzxiwCg3Y8xkNqD6PjQSOnYNfOdkOaR
gvwAoMyPPodPiG0UWaI0QEOn4HyLMeJ+iEYEEBECAAYFAkgqjg8ACgkQkJzmEqJDFafvewCe
OQd94hh3qpwHipHSiW0UUeYktt4An1Z8kMmKDkguN37mDf7tSisRyi6DiEYEEBECAAYFAkgu
+XsACgkQQCs+6R9AL7PGRACfVLrQTbFiNZSgX/VoWY8FLqq62zQAn01T3vlZIt06drH5KxEQ
MaAtTiKjiEYEEBECAAYFAkhtX00ACgkQyWxhJQVn2jBzMACeNKy+fpw3WVvi6F1SAQdEaaoX
4T4An2TiBkC481Nx2wNYv/JKjUUASePIiEYEEBECAAYFAkin7wwACgkQhxvahRvLsuoMaQCg
wbXkVPkmj4aYnu6NYjvWFM1H0aUAoIGN1C6GN8r5Z7d5G2VEhXZYFyRMiEkEEBECAAkFAkg8
OiMCBwAACgkQDBjyzmcOGgP62ACeKuEzZQkiVSiMfYmbFJNre8eocMIAni177NaTvfpslcpJ
d4rxNIrnCSRyiEYEERECAAYFAkKy80MACgkQQk6z7JKZxYfXfgCguWu/c5bkOADFOrH6pXP7
H3U16MsAoIEki0PHq1W2W/Y45o1KKIBSBHvWiQIcBBIBAgAGBQJBkP08AAoJEAvXRWEqdVnV
uG8P/i3IKnskOMtyBrgyoad3OFLxIyg9c7m5YhVpOutZU5V91ngpk35T/WcxSx1AdIDeFiZS
DK69RU6cke+J38QpGqfImdqSRxY417AF1AbkB+csf/V9wdHVZh1PbrA0ZGxaRxQ6EAErLWzS
9FVR/d2NjEtTaGfQWU7HIeHER1JUZha9C77sEdjOjVpbEpXZD5L3iB5hpvKVx84ouuNXUelS
tCsgU401Qbl9/VZYKka0GeQKrzMTDXfiXtISFqA8BsSE5DcKOjMZUx8n0kreNqVgRtC+PKOB
OTrKoypelcbYs2VQtuztaCtOhn48HpSP9N+or6vovIBfoPsmA0pPQ1l5n4pfN6gAYmSi/U/E
G3uLQ5xBsejH4PQtQwRKvwXRJrR3r/U5r5ZMVKiUGSNy9oT9ZRicjf/J7vUni8c1l6YRv48b
D3yBSpZcJC6aEV9V1A9jPpPatBLI5+EtDPtr+Wuh5tEe8T9t6rXUWpf0KGxSV4diLQwaInPs
u7qAW7RWQbaMwCfoc4EqwCvIHnmhC+S1dTQVjaUYJE4vc5cTZo0wVu1h/fg4QMdZygK1R6c5
5H+efsm9izybCYGHCNIDIeK6+Nm3X/lab8NFCTbdsURvXXXrWaNu1Gif8kuLz1y1RR4RVdW2
PU41qO01OBIGiNGGhPJgar3O4i3raVT0CRQACPUkiEYEEhECAAYFAj/eLnYACgkQ9jVtZM9G
Vc8gkQCZAXjWVuzO56JGARz87PRMEaejp7oAn1CUrc36G5aWEeFa313zajqV9n7miEYEEhEC
AAYFAkCpRCcACgkQXtn1Qb6VBHJYNACdGpDwlw+sCf2Ec4/yK13Dg+615iMAoIXONz0rmpgX
ItEREAdyWMHbBI3FiEYEEhECAAYFAkH2jfUACgkQgrin/Ace1CYzyACfVf+0d1sd3KwuK4ir
lH/0weW7rjAAn2b9E1JyreDk4kgkmWZlqD4BCxPqiEYEEhECAAYFAkH2nJYACgkQZL0IoGae
D6MiPgCgxGB9CzWLPpF7EefUB72pPklteR8An2N+TGjV7MPx3TP31t0k6ijE/2hTiEYEEhEC
AAYFAkZe+BQACgkQ4J/vJdlkhKw/FQCeOJNnc1uReGQ+lDRK/fbMWsyNSQgAn3I4/JN0LCH9
ilfpr2987DYi+HC0iQEcBBMBAgAGBQI/zfjJAAoJEAuerLG7SymnPF0H/RU5rv/kuCVmqv2s
lTODZYzLunWyPBXjsiB4UJlHDyJm43SvTNPv4Ta9YzqGthKszbLgCTvo47oWXnRZPlCtahtS
IPEd0o86b1LJLV481utkTDNozSOqc+1/vcsSGNXh3tE+butBZ1bS7VREsGcC5MVuJh8wpC8p
l9L/4L5bkhRM+hgjfUhCZBhngOPBQGEzKoKBeu91Y/dAfbmianYmBHOH8DEbCCNP2Sll680Y
K6j2s/YrE63inczqdp3VDMhjUiUR4CLoGn3/fb6XRwT0reUNbBlziD346+gIMA1dr2e7PHol
BrbNAvTAI50+S6hR4CkZ9rx+n0rQNP20FO7VvneJAhwEEwECAAYFAkF3mZEACgkQX8tdKqjw
LvW7kg//ZtVHiG99LPPoQWniUfH3sN0njOICebzEpsAjig6GZh7cr6pj7AeaXlOSOVPQFGZS
C+xwbiVjWGIZjNuCjcen94EMRswbYKSGf+qQwS7eNMeXTrQIV3CQGk7sYoTV+6CJ5MNMYUCT
uBJLSvjuMkUMcDuLadKioRkFjb979v4F3bQGWEPZsdKLOCZyX2cNjVtCcDBlkhzYNy85Pwzd
iA5YdnoACxcfe8qz6BpOC7kZiLN3yV5xXkU+uexQGBJY564+B57y+exBRvEYwKEIQwiq50qJ
N3NNdhN31HFdURzAV+KIzFXu43+SvtxR9F2OdfvPPHrN/Qpu4Ni1CBvypkG5XIkwd7xM3iw/
6fh4/BFzYYIFqUADPFzkYKy6U4lls9BNL/Yk0JgEkLbrEayNW6QbM1j/j2wctUrbaEe6Imnc
p8VN8DHSjE2tOe1iHIj6G+9rywDXx4kb9hwqcOfpKL/0AoRzle6aTr7KnCpxBMXCIfQyLKEc
J9wiO3LCwBafJ7fmLJFUnRb4L7ZPg5gMejl0fquMtVKR+CySLnhEqDwbrtIR5VOJuZlUFzr7
7HBL/T7rbxiU3mHONAI8T7dxs2fDv1+ktKeQtlLVv6DgOc2AaqbvgPO1LEtOdq9fN5aaoAi1
EGBDVkIMdWDXdVYY8PnP7GXow2X3G+oMDdl8+NpN3g+JAhwEEwECAAYFAkKfCxwACgkQ2MIK
CVokV8/xBQ/+MBAGiuwATgRalqxdV/PLCDHTaRKAqNf1kMhCMZ99ubECMPzXgI1QQa44AiTN
mUUd4RNrBS3gzMjXnx4oPe6JjXCkP1grnBLMple2NTkaWU0Q/VQkbDxYvZaiPZuz9JTrilU3
Z6L8+e6AzHVAs+EdIeYNxqeTfLUbFj+59AN9eJs7Ud7+uMWGeeDpiZUTcRXm2wdBRzfZi82q
bSLREsIAAvOHr7uB5YarjQOh6lFTT2Jo0GAE3fzVlcSAzS0yV1hD3qtIQH6x7uXrKTAcTDYQ
oDJnPIOZSYiz0xbuoAuWISicGXVvlaJ03C5+qgQ9oHRbzALC9SvxPXZeOC63bjMC7YLXQRzZ
+l4wkSjl+d2FfE6koAAC1vTzVx8febJ6eXbNB7mA3sO8gBRGj7oVzpqY2IAI+UqzyBuKVp7X
ElOKePK14mw3Dr0Ps/0MC63grWq6kLlAreGZzrS/dD/4L1ZgxibFbQXmaElQ+2n7AgNCV7Ye
ESafEPCVV82yScPxC1WlpVBUjqcmn4gcGBAQ62TBTg/2JL5Z7axiygv7KwDRiAb7lXtBRFid
F3dCYOyA696K6CKXioXZwYA3XIZXat2A5SfvH6NKVPzcultvqMWtvYceIx9OfiDiTCrInXni
xOSn9cJXRk7SeAOoQ/PHczcYWeAz8kAkUzCYMLQwtusUkkKIRgQTEQIABgUCP52dtgAKCRAh
kYDN20KmDkeUAKCKdRvqJlZLav7J8aZs+VHh45UmIwCgka/3mvy+0u2U8QdfHH9U2H2ndceI
RgQTEQIABgUCQA2AagAKCRAqHoQY2VDGRzkxAJ4kR3qK5sz/RW34GRwgtpvqA3tmAQCfVz6Z
bFeDgGtSzE+Hii7P2EGIz7CIRgQTEQIABgUCQC9h1gAKCRAYtrIyAv9xslhhAKCoaqimGJyU
ZZy3CmA5w9VeEQ/F8QCaAk5+ZnpWWitw9Px1srYz7Ps/knyIRgQTEQIABgUCQDe6OwAKCRAt
u3a/rdTJM4p0AJ9ZetvNX6woPsu8P/vxOXW4h97gKgCffLe5NAJrQJEX/XqVyBz61UaKCRCI
RgQTEQIABgUCQGhQ0QAKCRB81sDYi0FbqWAeAJ9Box2B5/C/YTc8CqNbB03JYPMxDACgvth6
MSFftyxQFSoFGe9A7exsyNKIRgQTEQIABgUCQGhS7gAKCRD2zzZt3CnlVIvzAJ0XTvHD9bKg
re6hdyDFIuxuSef/+gCfYOUsVkbwUqb3qA6hpbsl+jQHuvCIRgQTEQIABgUCQLD91gAKCRCz
ECrSTehe+AiSAJwJDLftzrq7Y7cOS8uNabiJkbFFUgCfTSM2QN4PN98bvII397o9TaWonxuI
RgQTEQIABgUCQieafAAKCRAOLabAN5HGCsDbAKCrV2bphe81jwW3UIqWK30aPI2EQwCdEDxo
HAQbFwQlriUUKEXbngBd8UOIRgQTEQIABgUCRiZ+5QAKCRBYiMxKKtdp1k3XAJ95ZF9U+TW2
jE9C6eg0cMXwc857FQCfZsUXM0YBMDemoV6MsUHLv7EllquISQQTEQIACQUCQDqQOQIHAAAK
CRDoDiJ7pAPsoBavAJwLUNAOOGHWauZJn06IhAW3A8uGkwCfbU2LiJwyQ/y3nBhpAehsp8yi
ZBmIWwQTEQIAGwUCP52dOwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRC0QmnQTypv0tjwAJ0U
5YaKyE6YWm/qMQB7W8WRfQVcgwCfVjlWmVBudyFliAFzhr94/3Jq95aIYwQTEQIAGwUCP52d
OwYLCQgHAwIDFQIDAxYCAQIeAQIXgAASCRC0QmnQTypv0gdlR1BHAAEB2PAAnRTlhorITpha
b+oxAHtbxZF9BVyDAJ9WOVaZUG53IWWIAXOGv3j/cmr3lrkBDQQ/nZ08EAQAugOfLWJbKwMA
9vg2mJU594TZU0HRJkx/fqYhx0YxWWRpzplrEyvcDXuYcWi1Hwh0tD86T4fR5GV6joWiWClz
D+Hwhhb6gcSdeSGlGLlZAvWYtFSHWiv+3LaI9w8Vtczl99Bh2WiMDNDDGw0RQg6ZaftldLSe
4j1pffpFGQ8SuisAAwUEAKVxqLT7fC5xQ6oclcZ+PhoDlePQ1BiTS7tuGM07bFF4nNvY91LL
7S31pooz3XbGSWP8jxzSv1Fw35YhSmWGOBOEXluqMbVQGJJ5m8fqJOjC0imbfeWgr/T7zLrJ
eiljDxvX+6TyawyWQngF6v1Hq6FRV0O0bOp9Npt5zqCbDGs/iEYEGBECAAYFAj+dnTwACgkQ
tEJp0E8qb9L//gCcDVYnDegNCOxDn1sedDwxw+0h8OcAn1CZHof15QqxnTwEnvwF2QeOI5dn
=EheR
-----END PGP PUBLIC KEY BLOCK-----

[herrold@centos-5 rpmlint]$

RPM is being careful there, dumping the entire key value.

Let's see that process again without the key dump:

[herrold@centos-5 rpmlint]$ rpm -Kv rpmlint-0.82-3.fc9.src.rpm
rpmlint-0.82-3.fc9.src.rpm:
    Header V3 DSA signature: OK, key ID 4f2a6fd2
    Header SHA1 digest: OK (8d753729ecfc59620fca2ccc1018e767787da9a6)
    MD5 digest: OK (7d8b212cc68ff675fd64b124d832c423)
    V3 DSA signature: OK, key ID 4f2a6fd2
[herrold@centos-5 rpmlint]$ rpm -K rpmlint-0.82-3.fc9.src.rpm
rpmlint-0.82-3.fc9.src.rpm: (sha1) dsa sha1 md5 gpg OK
[herrold@centos-5 rpmlint]$ sudo rpm -e gpg-pubkey-4f2a6fd2-3fcdf8c9
Password:
[herrold@centos-5 rpmlint]$ rpm -K rpmlint-0.82-3.fc9.src.rpm
rpmlint-0.82-3.fc9.src.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#4f2a6fd2)
[herrold@centos-5 rpmlint]$ sudo rpm --import  Fedora-key
[herrold@centos-5 rpmlint]$ rpm -K rpmlint-0.82-3.fc9.src.rpm
rpmlint-0.82-3.fc9.src.rpm: (sha1) dsa sha1 md5 gpg OK
[herrold@centos-5 rpmlint]$

Notice that difference in how RPM reports matters, with the key present [gpg OK], and removed [(GPG) NOT OK (MISSING KEYS: GPG#4f2a6fd2)] from the RPM database.

A careful automated build system can complain and stop, when offered a SRPM bearing an unknown signature. I outlined (and implemented) such a process some years ago for the cAos community distribution effort.

Recent efforts to reach a buildsystem to pull 'on the fly' from CVS head [I am thinking here of Mark Shuttlesworth's keynote address at OLS this summer, and of some comments within Fedora's -devel mailing list] or other version control system are all well and good, but when the time comes for the official external build for record, I prefer a system where the entire chain of binaries produced are only from signed packages and signed by persons I trust.