The problem with older packaging managers in two lines ...

There was a post from the NetBSD oriented 'pkgsrc' project into the Scientific-Linux mailing list earlier this week. Lots of skilled geeks following their muse ... but From the #pkgsrc IRC channel ('nick' changed to protect the poster)

09:11 wxzy> Ugh. I think I should have chosen the X from pkgsrc.
09:11 wxyz> The one I have now lacks fonts that applications need.

Yeah. Package 'Managers' that unroll tarballs, but lack a strong Requirements / Dependency system are like that

RPM and YUM trick: synchronize packages installed on two hosts

The question was asked in IRC today:

hello folks, is there any way to install packages from a list written by yum list installed? I've two CentOS 6.3 hosts and I like to get them with the same packages installed (also versions)

Here is a quick (and accurate) answer:

1. Take and test backups to taste
2. Run:
   

   rpm -qa --qf '%{name} \n' | sort > MANIFEST

   Note: that is a backslash n -- the html markup makes it hard to see the distinction
3. Then copy that MANIFEST to the second unit and run:
   

   yum -y install `cat MANIFEST`

   Note: and here, backtick around the cat to get a sub-shell
4. Finish by running:
   

   yum -y update

   on each unit

For extra credit, re-run the MANIFEST creator on each unit, and use diff to find any variances

Coping with xz under the RPM tools in CentOS 5

So there I am, minding my own business, building a SRPM from Red Hat's 'rawhide' archive, and it fails. They are cutting over to 'xz' compression for the tarballs they ship. Their archive, and so their call, and not the end of the world

The symptom shows up when rpmbuild goes to uncompress such:

...
+ rm -rf clamav-0.96.4
+ tar -xf /home/herrold/rpmbuild/SOURCES/clamav/clamav-0.96.4-norar.tar.xz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Read 6508 bytes from /home/herrold/rpmbuild/SOURCES/clamav/clamav-0.96.4-norar.tar.xz
tar: Error exit delayed from previous errors
error: Bad exit status from /var/tmp/rpm-tmp.36477 (%prep)

RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.36477 (%prep)
[herrold@centos-5


The error messages could be better, but the older compression methods that are known to the 'file' program available to rpmbuild that ships with CetnOS 5 do not contain the relevant 'magic numbers' yet. Progress is like that, and so until and unless Red Hat backports support into its RHEL sources, CentOS will not pick up the fix in its version 5 mainline

One perfectly suitable response is to use the RPM5 branch of the package manager, which DOES know. But some people cannot relax that constraint for various non-technical reasons

This issue is rather like the old cutover from md5sums to shasums which RPM did a while ago, and that I wrote aboutI wrote about

The fix is straightforward:

1. Install the compressed tarball, spec file and any patches with rpm in the usual fashion
2. Uncompress from the unknown compression format and re-compress with a known one
3. Amend the spec file; here, I use grep to look, and as there is just one edit, sed to edit
4. Rebuild using the '-ba' option from the revised .spec file with the tools of the target environment (here, CentOS 5)
5. The resulting SRPM will be portable and as a result of the second step, uses a known compression

Lets look:

[herrold@centos-5 clamav]$ unxz /home/herrold/rpmbuild/SOURCES/clamav/clamav-0.96.4-norar.tar.xz
[herrold@centos-5 clamav]$ gzip /home/herrold/rpmbuild/SOURCES/clamav/clamav-0.96.4-norar.tar
gzip: /home/herrold/rpmbuild/SOURCES/clamav/clamav-0.96.4-norar.tar.gz already exists; do you wish to overwrite (y or n)? y

[herrold@centos-5 clamav]$


That question about over-writes happened because it appears the sources from a prior build of clamav-0.96.4 were not re-rolled into a 0.96.5 tarball by the upstream packager at RawHide, but may have been patched instead. I've not expressly looked

[herrold@centos-5 clamav]$ cp ~/rpmbuild/SPECS/clamav.spec .
[herrold@centos-5 clamav]$ rpmbuild -ba clamav.spec
error: File /home/herrold/rpmbuild/SOURCES/clamav/clamav-0.96.4-norar.tar.xz: No such file or directory
...


As we have not yet fixed the .spec file, this was expected, but is shown here so the diagnosis path is clear

[herrold@centos-5 clamav]$ grep xz clamav.spec
Source0: %name-%version%{?prerelease}-norar.tar.xz
[herrold@centos-5 clamav]$ sed -i -e 's@xz@gz@g' clamav.spec


And now the .spec file is ready as well

[herrold@centos-5 clamav]$ rpmbuild -ba clamav.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.47404
+ umask 022
+ cd /home/herrold/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /home/herrold/rpmbuild/BUILD
+ rm -rf clamav-0.96.4
+ /bin/gzip -dc /home/herrold/rpmbuild/SOURCES/clamav/clamav-0.96.4-norar.tar.gz
+ tar -xf -
...
checking host system type... x86_64-redhat-linux-gnu
checking target system type... Invalid configuration `noarch-redhat-linux-gnu': machine `noarch-redhat' not recognized
configure: error: /bin/sh config/config.sub noarch-redhat-linux-gnu failed
error: Bad exit status from /var/tmp/rpm-tmp.86669 (%build)
...


The build fails for other reasons out of scope for this post, in that a new configure 'target' is emitted. This is similar to a later compression format addition, but a different problem, solved elsewhere. Such a change is another part of distribution and brand management matters at Red Hat's part. I'll note the solution for this (putting to side seriously amending the rpm build environment macros, which is the 'one way' path into later versions) in a later post

Once all the changes are done, and the 'scratch' test builds and will install cleanly, I go in with an editor, manually bump the release value by one, and add a note in the changelog stanza. Then I repeat the build 'for record', signing, and distribution. The Release 'bump' is needed so the NEVR (name, Epoch, Version, and Release comparison which librpm does, and that yum calls through librpm to do can detect the fact that a later updated version is in an updates repository in due course

All done

checklist RO rsync server

Setting up a new RO RSYNC server setup

The primary usage case is we describe is how to deploy a read-only RSYNC server with no end user accounts, to be used for distribution of content (here, to move a builder result archive that is intentionally NOT 'visible' from the internet to a more capable transfer server) From there, the content is integrated into a internal archiving server, and after that, to a publicly accessible binary archive, accessible through ftp, rpm, or yum

As before, we start with a freshly deployed, and hardened PMman instance. At all times, we will strive to follow proper sysadmin 'best practices' discipline under SElinux, wrappers and iptables

Install and enable rsync, which is the package holding the stock rsync daemon. As rsync supports wrappers, we also need the xinetd which is the package holding the stock inetd in recent Red Hat derived distributions -- Let's get started:

1. yum can do the install trivially

   yum install rsync xinetd

2. Then enable the needed services:

   /sbin/chkconfig rsync on
/sbin/chkconfig xinetd on

3. We need to do some configuration for the rsync daemon as to permissions and directories to serve:

   [root@trap64 etc]# cd /etc
[root@trap64 etc]# cat rsyncd.conf
# motd file = /etc/rsyncd.motd
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock

[trap64]
path = /var/ftp/pub/local
comment = x86_64 fruit
uid = nobody
gid = nobody
read only = yes
list = yes
# auth users = username
# secrets file = /etc/rsyncd.scrt
hosts allow = 10.0.0.0/24 127.0.0.0/24
hosts deny = 0.0.0.0/0

[root@trap64 etc]#

4. Set up the iptables -- I do not recall the rsync daemon port off the top of my head, so I look it up:

   [root@trap64 etc]# grep rsync /etc/services | head -2
rsync 873/tcp # rsync
rsync 873/udp # rsync
[root@trap64 etc]#

   ... so the port is 873

   # localhost can do all ...
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
# ...
# rsync daemon
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 10.0.0.0/8 --dport 873 -j ACCEPT
# ...

5. Open the wrappers

   #
ALL: ALL@127.0.0.1
#
# ...
#
rsync: ALL@10.0.0.0/255.0.0.0
#

6. Restart the wrappers enforcing daemon

   [root@trap64 sysconfig]# /sbin/service xinetd restart

7. Test it:

   [root@trap64 sysconfig]# rsync localhost::
trap64 x86_64 fruit
[root@trap64 sysconfig]#

8. To put it into production on a client, we can use something like this:

   #!/bin/sh
#
# this file: /root/bin/update-archive.sh
# Copyright (c) 2010 R P Herrold
# License: GPLv3+
#
# ln -s /root/bin/update-archive.sh /etc/cron.hourly/
#
export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
umask 022
# -- non local content goes into the mirror constellation
[ ! -e /var/ftp/pub/mirror/pmman/RPMS/x86_64/ ] && \
mkdir -p /var/ftp/pub/mirror/pmman/RPMS/x86_64/
#
# export VERBOSE="-v "
export QUIET="-q "
#
/usr/bin/rsync -a ${VERBOSE} ${QUIET} --exclude=working \
trap64.darkside.lan::trap64/pmman/RPMS/x86_64/. /var/ftp/pub/mirror/pmman/RPMS/x86_64/.
chown -R root.root /var/ftp/pub/mirror/pmman/RPMS/x86_64
#

9. All done

---

Earlier in this series:

Function	Link
hardening	http://www.pmman.com/usage/hardening/
lftp	http://orcorc.blogspot.com/2010/08/mirroring-upstream-master-with-lftp-to.html
RO vsftpd	http://orcorc.blogspot.com/2010/07/checklist-ro-ftp-server-setup.html
RO NFS	http://orcorc.blogspot.com/2010/08/nfs-aide-to-memory.html

living at HEAD

Mark Shuttlesworth gave a keynote a few OLS ago, proposing that some folks need to 'live at head' and file the bleeding edge bugs early so nasty stuff gets fixed early, and good stuff flows down

The assumption is that the need for patches, except for branding, etc will fade away, and the character of Open Source's code improves with 'a rising tide that floats all boats'. Apple is pretty far down this road already with Clang/LLVM

I already build much from nightlies from VCS anyway (including clang), and it is simple enough to first solve a selfhosting iso builder. Then continue to populate leaf nodes to taste. Auto-reinstall daily preserving configs or detecting breakages and writing idempotent configs migrators as needed

File bugs ruthlessly, or at least relentlessly

Wire in valgrind, llvm, drill in unit tests and end to end functional tests, buildbots, LSB conformance testers, more, and file more bugs off the daily exceptions reports after new commits appear upstream. Whitelist acknowledged bugs for a while (with timeouts to keep the upstream honest)

Keep the machines busy at night rather than letting them play cards with one another

---

This email drafted in 5 minutes but I've ranted the rant enough times it is familiar. How is that for a real world and useful goal? Certainly better than playing 'bikeshed' politics

Stupid RPM tricks: SOURCE files No. 2 in a series

The #rpm channel has this question this morning:

how can I simple include a file placed in SOURCES dir in a pkg?

Locally on a development box, I maintain a huge archive of unpacked .spec files, either written from scratch, or with automated tools locally produced in house, or extracted from SRPMs (from a mirror collection of somewhat over a quarter-million such SRPMs)

This gives me a huge reservoir to look through for a clean example. Folks in a Unix ™ like environment are fortunate to live in a culture what favors portability by rebuilding from sources, and avoiding binary data stores in favor of plain text ones. This has been a part of the environment since the earliest days of that culture. The tool grep can act as one's eyes, to scout out examples

I know from experience reading and then writing .spec files, that a file living in the ./SOURCES/ directory might be listed, and then referred to by using the identifier: SOURCE. So, I look with grep and find the following

[herrold@centos-5 ~]$ cd rpmbuild/SPECS/
[herrold@centos-5 SPECS]$ grep SOURCE *spec | wc
623 2876 44222
[herrold@centos-5 SPECS]$ grep SOURCE *spec | less

As there were LOTS of matches, I used less to scan the results a screen at a time, looking for a well known, and readily available package to pull an example from. The ISC bind nameserver is a well known and prevasively available one

[herrold@centos-5 SPECS]$ grep -i SOURCE bind*spec | grep 29
Source29: named.conf.sample
cp -fp %{SOURCE29} sample/etc/named.conf
[herrold@centos-5 SPECS]$ grep -i sample bind*spec
Source29: named.conf.sample
Source30: named.rfc1912.zones.sample
# sample bind configuration files for %doc:
mkdir -p sample/etc sample/var/named/{data,slaves}
cp -fp %{SOURCE29} sample/etc/named.conf
cp -fp %{SOURCE30} sample/etc/named.rfc1912.zones
cp -fp %{SOURCE31} sample/etc/
cp -fp %{SOURCE17} %{SOURCE18} %{SOURCE19} %{SOURCE20} %{SOURCE21} %{SOURCE22} %{SOURCE23} sample/var/named
ns localhost.' > sample/var/named/$f;
/usr/bin/tail -n '+'`/bin/egrep -n '\\$Id: rndc.conf,v' bin/rndc/rndc.conf | sed 's/:.*$/+1/' | bc` bin/rndc/rndc.conf | sed '/Sample rndc configuration file./{p;i\
;d}' > sample/etc/rndc.conf;
%doc sample/
...

So we see that the process is:

1. List that file, living in ./SOURCES/ in the .spec file
2. Simply use the cp command (with some options preserving timestamps, etc.) to the install staging point, and
3. include the destination directory or the specific file in the list down in the %files stanza of the .spec file

By reading prior examples, a person can find both good and bad examples, of course, and so cross checking is sensible. This particular example was chosen as it is a nice clean one

---

This post is part of a continuing series. The content of this series might be indexed out with the tag: rpm It addresses usage questions and issues raised in the #rpm IRC channel on freenode. That channel is populated by folks who are part of the RPM branch represented at: http://rpm5.org/. Your author of this content formerly served as the editor of the RPM website, for many years, until the domain owner 'pulled' it back one day. The older content formerly at the old rpm.org site is now archived at: http://www.oldrpm.org/

Stupid RPM tricks, No. 1 in a new series

In the #rpm channel on freenode, a new person has wandered in with what seems like a basic question when writing up a new .spec file. I looked into the back archive for this blog, and it seems there is a way to get a list of just the items I have tagged with "rpm"

When I add:
%config %{_builddir}/ossec-hids-%version/etc/ossec.conf
.. where the rpm will put this file when i install that package?

Kind of a strange question as a line begenning: %config ... is usually placed in the %files stanza to mark the character of a file as a configuration file. Those files usually live at down /etc/ or perhaps /etc/packagename/ The author will find that this construct is not likely to place content where a general system application striving to meet and to be conformant with the File Hierarchy Standard would place such

Putting that to one side, let's 'solve' here it ends up when RPMBUILD processes that .spec file stanza
$ rpm --showrc | grep _builddir

[herrold@centos-5 ~]$ rpm --showrc | grep _builddir
RPM_BUILD_DIR="%{u2p:%{_builddir}}"
cd %{u2p:%{_builddir}}
/usr/lib/rpm/find-debuginfo.sh %{?_missing_build_ids_terminate_build:--strict-build-id} %{?_find_debuginfo_opts} "%{_builddir}/%{?buildsubdir}"
-14: __mono_provides /usr/lib/rpm/mono-find-provides %{_builddir}/%{?buildsubdir} %{buildroot} %{_libdir}
-14: __mono_requires /usr/lib/rpm/mono-find-requires %{_builddir}/%{?buildsubdir} %{buildroot} %{_libdir}
-14: _builddir %{_topdir}/BUILD
RPM_BUILD_DIR="%{_builddir}"
[herrold@centos-5 ~]$

Obviously here is a need to run another query to examine '_topdir' to fully answer that question:

[herrold@centos-5 ~]$ rpm --showrc | grep _topdir
-14: _builddir %{_topdir}/BUILD
-14: _rpmdir %{_topdir}/RPMS
-14: _sourcedir %{_topdir}/SOURCES/%{name}
-14: _specdir %{_topdir}/SPECS
-14: _srcrpmdir %{_topdir}/SRPMS
-14: _topdir /home/herrold/rpmbuild
[herrold@centos-5 ~]$

So that file will end up at: %{_topdir}/BUILD/ossec-hids-%version/etc/ossec.conf , or more precisely: /home/herrold/rpmbuild/BUILD/ossec-hids-%version/etc/ossec.conf

The 'takeaway' here is that the "_builddir" variable is not customarily used down in the %files stanza of a .spec file

stirring the pot with the same old spoon -- rpm options

The same old question came up in an IRC channel yet again today, by a person who will not read, nor Google. Once again, with feeling, here is a quick script to study, as to stripping out excessive content on a Red Hat, CentOS, or Fedora derived 'multi-arch' box

[root@centos-5 bin]# cat ./strip-non-x86_64.sh
#/bin/sh
#
# strip-non-x86_64.sh
#
# strip all non x64_64 content (and also leave behind
# noarch stuff) for more build dependency friendly
# environment
#
# Copyright (c) 2010 R P Herrold
# GPLv3+
# tossed together for education purposes for a blog post
#
# optionally run over or over, after enabling the removal
# or one pass, if you uncomment two places
#
# not designed to be the more efficient one pass solution
# which is possible
#
# NODEPS="--nodeps "
#
# see: man rpm, see '--qf' or: queryformat
# or --querytags
#
for i in `rpm -qa --qf '%{name}.%{arch}\n' | sort | grep -v ^kernel | \
grep -v noarch$ | grep -v "86_64" | grep -v ^gpg-pubkey `; do
echo "${i}"
# rpm -e ${i} ${NODEPS}
done
#
[root@centos-5 bin]# ./strip-non-x86_64.sh
[root@centos-5 bin]#

I am so bone tired of people who want to be fed from the same old dirty spoon

For extra credit see: man yum.conf and add the needed multilib_policy = best line to etc/yum.conf

Reading the logs, part 3 -- Run your updates

It looks like I'll be writing these for a while as I clean up logfile noise. The earlier pieces are here and here. I say 'noise' here because they are not false positives, but neither are they material, just more a nuisance

One the things every admin who reads log files sees are automated scanners looking for exploits in 'canned' packages that were installed but have not been updated, either because the admin for a given machine has neglected to run updates, because it is not a publicly known exploit, or because the upstream has not yet addressed the matter.

A pattern that has emerged with our PMman with a data center with large contiguous swaths of IP space (and hosts scattered in assignment in that relatively compact range, said hosts reporting to me centrally) is as follows. The hostile exploit scanners are not even trying to be subtle any more -- they simply march sequentially through IP ranges, and inventory if a given weakness is present on every host to which they connect

Today, I focus on one sample report stanza:

--------------------- httpd Begin ------------------------

Requests with error response codes
400 Bad Request
HTTP/1.1: 1 Time(s)
403 Forbidden
/index.html: 1 Time(s)
404 Not Found
/cms/e107_files/e107.css: 1 Time(s)
/db/e107_files/e107.css: 1 Time(s)
/e107/e107_files/e107.css: 1 Time(s)
/e107_files/e107.css: 1 Time(s)
/forum/e107_files/e107.css: 1 Time(s)
/index.php: 1 Time(s)
/manager/html: 1 Time(s)
/portal/e107_files/e107.css: 1 Time(s)
/site/e107_files/e107.css: 1 Time(s)
/web/e107_files/e107.css: 1 Time(s)

---------------------- httpd End -------------------------

and apache can handle this trivially:

#
# file: noexploit.conf
#
# send scanners off to see the wizard
#
Redirect permanent /cms http://127.0.0.1/
Redirect permanent /db http://127.0.0.1/
Redirect permanent /e107 http://127.0.0.1/
Redirect permanent /forum http://127.0.0.1/
Redirect permanent /manager http://127.0.0.1/
Redirect permanent /mysql http://127.0.0.1/
Redirect permanent /phpmyadmin http://127.0.0.1/
Redirect permanent /phpMyAdmin http://127.0.0.1/
Redirect permanent /portal http://127.0.0.1/
Redirect permanent /site http://127.0.0.1/
Redirect permanent /user http://127.0.0.1/
Redirect permanent /users http://127.0.0.1/
Redirect permanent /web http://127.0.0.1/
#

The obvious next step is to package deployment hardenings, and add them to a local RPM repository so that simply running updates, as with yum will get the current best approaches on hardening, en masse, on all the servers

... I am the eggman

One recent addition to Python modules packaging at Red Hat in its Fedora project, is carrying along an additional, and optional structured metadata about the contents of that module (package), held outside of the RPM database

This additional information: egg-info came into Python at Python version 2.3 and following. More may be learned about these eggs at: egg-info (optional extra Python metadata about a Python module).
See: Fedora specifics

This new detail is a two edged sword. On one hand, it provides sufficient information that an ad hoc root level process, for when one using native Python tools that it makes for an easy_install [the skeptic in me suggests it might be 'easier', perhaps, along some skewed axis of metric of goodness]. See also the egg superset, Python setuptools which now work well in RPM-mediated space

Sadly, down this path, modules which are outside of the protections and managae-ability of the RPM packaging system may "easily" and inadvertently be introduced by an incautious admin, and thus introduce of Python code into a otherwise controlled system. This is the horror of a mixed RPM and CPAN system, all over again. As I say, one needs to choose a 'metric of goodness' with care

Incautious use of mixed packaging approaches in turn can lead to possible security and updates headaches. Using such non-packaging system tools can break the SPOT -- single point of truth -- to determine to what versions of binaries a given host is using. From sad experience, this way lies additional work, and madness

But on the other edge of that blade, the egg-info adds descriptive narrative, and cautiously used, increases the usability of a system that does not (ab)use those native installation tools

As noted, the FOSS world has faced this problem before with perl and CPAN. Weak and strong 'includes' versioning and security model questionable @INC 'include' path search practices in Python and perl are well known failings in their community archive models. I faced it recently in a packing push of CRAN modules for R -- hmmm, I still need to file a few bugs upstream to solve some problems I saw in some R module packaging choices that I consider poor ones

There is not a single, objectively 'technically right' way to proceed, but rather just one consistent, or not consistent with packaging system design and usage choices

Fedora helpfully offers a sample stanza to use in .spec files. I cruised my archive of .spec files to see what else turned up


# See if there's any egg-info
if [ -f %{buildroot}%{python_sitearch}/Conch*.egg-info ]; then
echo %{buildroot}%{python_sitearch}/Conch*.egg-info |
sed -e "s|^%{buildroot}||"
fi > egg-info


and later then using the %files stanza's -f file list option


%files -f egg-info
%defattr(-,root,root,-)
%doc LICENSE NEWS README doc/*
%{_bindir}/cftp
...


It appears I need to do some work in my local archive of SRPMs. Never enough hours in the day

May Day celebration

I see a tweet from KB about the monthly mailman mailing list reminder emails; I took steps long ago to use procmail to watch for these, and re-mark their subject line. I then sort my mailspool by subject in alpine, and delete this noise all in one pass.

# mailing list memberships reminder
#
:0 fw
* ^Subject: \/.*mailing list memberships reminder
*!^X-Reminder
  | formail -i "Subject: mlmr] $MATCH"     \
    -A "X-Reminder:$MATCH"    \
    -A "X-Munge: moved mailing list memberships reminder"


All power to the people

OMG, Round Two

I wrote a bit back about a gratuitous change in Red Hat's RPM variant breaking backward SRPM readability, in a fashion which stranded users of the earlier Red Hat Enteprise release products (and rebuilds such as CentOS) away from the Raw Hide pool of developmental edge packages.

The fix I outlined: to build and freeze (in time, and against updates) a RawHide domU instance, and to use that domU and an NFS mount back into the earlier dom0 to unpack SRPMs. This works fine for the present.

The full size screen shot is a bit large, but down that link. It takes just a couple of seconds to set up a new unpacking destination, and to do the rebuild, once it is set up.

No sparrow falls, but that ....

Letters, we get letters ...

> I saw a blog posting recently where you
> commented that RHEL 2.1 was based on RHL
> 8.0. My memory /understanding is that
> RHEL 2.1 is based on RHL 7.1... or maybe
> 7.2... but not 8.0.

memory fades ... let me dig a bit

Let's see ... I was on Red Hat's 'tester-list' external beta tester (under NDA) program

The watershed email (which put my memories in the RHL 8 timeframe) was:

Date: Thu, 17 Jul 2003 14:06:07
From: Michael K. Johnson
To: testers-list@redhat.com
Subject: Heads-up -- change coming [Red Hat Confidential]

This mail contains only Red Hat Confidential material. ...

But there had been rumblings ever since RHAS 2.1 issued, which made me want the 'insurance policy' community RPM based distribution

Which led previously led to me setting off with Greg Kurtzer to get cAos going. Greg and I discussed an enterprise product from the earliest cAos meetings (earliest I have a record of is: 29 Apr 2003). Greg, Rocky Mcgaugh and I pitched this product concept and extension of the 'two Linux' policy to an IBM VP at SuperComputing 03 in November 2003 at Phoenix, AZ. I remember flying down from Las Vegas for the meeting

And it matured quickly. Parallel efforts were underway by others -- Tao Linux, Xos, and more. There was a mailing list: rhel-rebuild list <rhel-rebuild-l@uibk.ac.at> but I've not seen a post on that list for eons

Date: Tue, 9 Dec 2003 09:30:23 -0600 (CST)
From: Rocky McGaugh
Reply-To: caos@caosity.org
To: caos@caosity.org
Subject: cAos] Announce: centos

The cAos-EL projects have been officially renamed to:
centos (Community ENTerprise Operating System)

Sadly, Rocky has died, too young. Greg (sensibly for his needs) stayed with the cAos part. And I am an old, tired dog, am left on the CentOS part... Does anyone not not die too young while they are still young of heart?

so thus my recollection of late 2003 ...

http://www.owlriver.com/redhat_versions.html
RHL 8 general release Sept 30 2002
RHL 9 general release Mar 31 2003
RHL 7.3 GA May 6, 2002

http://www.redhat.com/security/updates/errata/
RH AS 2.1 General Availability: May 17, 2002

negative rebuild report under 7.2
http://www.redhat.com/archives/rpm-list/2003-April/msg00001.html
April 2003

So .. it seems true that RHAS 2.1 was on a pre RHL 8 base. But RHL 7.3 was so good, and RHAS 2.1 ... wasn't. Perhaps that led me to conflate the fork point

A 'tip of the hat' to the sharp eyed blog reader Scott Dowdle who noticed the matter and called it to my attention

Oh ... my ... goodness ...

I've been mirroring, rebuilding, patching, filing bugs, and so on, against bleeding edge source package RPMs (SRPMs) out of 'RawHide' for at least a decade. It is one means I have used to push features from later Red Hat releases and hotfixes back into previous releases, to customers in our consulting (and on my own account).

We pushed post-RHL support, and commercial RPM-based support for side architectures including Netwinders [MIPS], PA-RISC, PPC, Sparc hardware, and Alphas from RawHide. We have built FOSS-based 'latest and greatest' LTSP forks of reduced package sets for commercial applications from RawHide

A largely unheralded change to a new RPM package file format for Raw Hide SRPMs coming out to the builder, at Red Hat's rpm-4.6 breaks all that, for the first time in at least a decade ... Jeff Johnson, a former lead developer and maintainer for Red Hat preceding the current incumbent lead, bent over backward and jumped through hoops, to make rpm a lingua Franca. Jeff was followed by a short-time incumbent, Paul Nasrat, who similarly did no harm to rpm

[herrold@centos-5 ctrlproxy]$ cp /mnt/nfs/var/ftp/pub/mirror/redhat/rawhide/SRPMS/ctrlproxy-3.0.8-2.fc11.src.rpm .
[herrold@centos-5 ctrlproxy]$ ls
ctrlproxy-3.0.8-2.fc11.src.rpm
[herrold@centos-5 ctrlproxy]$ rpmbuild --rebuild \
   ctrlproxy-3.0.8-2.fc11.src.rpm
Installing ctrlproxy-3.0.8-2.fc11.src.rpm
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
error: unpacking of archive failed on file /home/herrold/rpmbuild/SOURCES/ctrlproxy-3.0.8.tar.gz;49aeb249: cpio: MD5 sum mismatch
error: ctrlproxy-3.0.8-2.fc11.src.rpm cannot be installed
[herrold@centos-5 ctrlproxy]$ rpm -Vp ctrlproxy-3.0.8-2.fc11.src.rpm
Unsatisfied dependencies for ctrlproxy-3.0.8-2.fc11.src: rpmlib(FileDigests) <= 4.6.0-1
missing ctrlproxy-3.0.8.tar.gz
missing ctrlproxy.config
missing ctrlproxy.init
missing ctrlproxy.spec
[herrold@centos-5 ctrlproxy]$

Amid all that, the part which is important is that: a new rpmlib of at level 4.6.0-1 is needed (marked in red), and that without it, it produces a rather unhelpful cpio md5sum error message (marked in blue)

For the short term, until I get the matter sorted better, I'll set up a domU Raw Hide xen instance (which has the later rpmlib, and so can manipulate the package), such domU will be upgraded just enough to handle rpmlib(FileDigests) <= 4.6.0-1, then frozen against other breakage from later other updates

Further I'll grant that domU RW access to the NFS export that contains my build tree (/home/herrold/rpmbuild/), so that I can position a SRPM into that tree, and unpack it rpm -U packagename.src.rpm

With that unpacked set in the SOURCES subdirectory -- the tarball, patches, and such; and the SPECS subdirectory .spec file, I can then (hopefully) switch into an earlier rpm variant on an older unit, and rebuild the package to write a new SRPM with the older rpmlib form

---

We'll see. Change requires that the caterpillar moult and break out of the crysalis. It does not require that an angry Mothra result, and destroy the surrounding city in concert with Godzilla.

It might be asserted that this is some sort of performance or speed optimiszation.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. -- Donald Knuth

rpm has had the instrumentation capabilities in place to see about where performance penalties lie, and has them for some time, so that one can easily test where load is. This is not rocket science; similarly, we drilled in micro-second instrumentation and time-stamping in the shim, as we are accustomed to looking for code bottlenecks, and people using our software, and trading in the financial markets really care about where lags are. I wrote a bit about this last month in the New Future Always Coming piece.

As proof of the pudding, take a moment and run rpm 4.6.0 with --stats on a large package built under the old format, and rebuild and repeat the test with the new 4.6.0 variant. Please feel free to get back to me at: timetrials at owlriver dot com as to where YOU find the true performance issues are, comparing a package build with SHA2, v. MD5. I have my preliminary stats for a later post, but welcome more data

---

This sure seems like a gratuitous and thoughtless format breakage to me, with no backward compatibility path announced. RHAS 2.1 is about to go out of support, of course (which dates back to a foundation including a fix for the as shipped RHL 8 rpm database locking issues), but RHEL 3, 4 and 5 just lost the ability to use Raw Hide so far as I can currently see

I may be missing something obvious by way of a workaround, and would be glad to be corrected, but ...

I really feel that the current incumbent Panu Matilainen has NOT clearly articulated this on the mailing list and bugs at Red Hat which I read very closely

This WILL cause at a minimum confusion, and also compatibility problems down the road with bi-directional interoperability at the SRPM level between both the LSB, and Red Hat's major enterprise Linux distribution competitor, Novell and its SLES line [seemingly being branded: SUSE Linux Enterprise, presently]. Oracle's UBL and its consumers are sort of off in a 'market niche' world of its own here, and the impact will be less pronounced. It will probably cause such SRPMs to 'just NOT work' in the SuSE buildservice, but I have not tested this yet

Heaven help the users of side distributions -- cAos, Mandriva, PLD, and the non-English fluent RPM file format using -- who try to rebuild and use a random found SRPM. It really seems that Red Hat marginalizes (or forces one to choose a camp to join) other formats with this move. Perhaps that was their intent. Fedora has been used by Red Hat as a 'wedge' for this purpose in the past [consider studied dis-interest in inter-archive compatability], and it may be just more of the same

Grrr ...

---

Disclaimer: These days, I am aligned with the RPM5 insurgents, and served as the long time maintainer of the old RPM website which Red Hat has since re-claimed

rpm -import of GPG keys, revisited

Okay, I guess I covered too much too fast last time I discussed adding a signing key to RPM. Let's do it again with more annotation and color commentary.

The RPM package manager (see: the old RPM.ORG website, which I maintained as 'rpm.org' for several years; JBJ's 'way forward' for RPM development site; and the rather sparse, intentionally stale, and to me useless site controlled by and populated to suit the Red Hat corporate agenda -- details of the fork in RPM are out of scope here) has the capability to verify through strong cryptography that a package is intact, and is counter-signed by a person in possession both halves of an asymmetric public and private keypair. Assuming that reasonable care (where 'reasonable' is a very large and paranoid number) is used to protect the confidential nature of the private half, the chances of a successful substitution are vanishingly small.

Anyone can examine and inventory the keys in RPM's trusted keystore. The process of additions, changes, and deletions of keys is an operation requiring root level privileges, and so assuming a machine can be trusted (both network level and local physical level attacks need to be considered)

Enumerate the keys present:

$ rpm -qa gpg\*

Examine a specific key:

$ rpm -qi gpg-pubkey-e8562897-459f07a4

If we know or can determine the 'fingerprint' of the public half of a signing key, and if that key has been placed at a public keyserver, we can retrieve it, examine it, or even directly import it. For the sake of this example, we again consider the Raw Hide SRPM signing key (with the re-organizations over time, Red Hat presently signs Raw Hide content with key: 0x4F2A6FD2 which the MIT keyserver identifies thus)

The CGI query on the link above used the 'op=index' modifier; the next uses the 'op=get' -- one assumes 'op' is shorthand for the type of query operation made -- terse, or key-bearing. In any event, we retrieve the key into a local file thus:

$ wget -O fedora-key "http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4F2A6FD2"

and then may examine it with the conventional 'nix tools:

$ less fedora-key
<title>Public Key Server -- Get ``0x4F2A6FD2
''</title><p>
<h1>Public Key Server -- Get ``0x4F2A6FD2
''</h1><p>
<pre>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP Key Server 0.9.6

mQGiBD+dnTsRBACwnlz4AhctOLlVBAsq+RaU82nb5P3bD1YJJpsAce1Ckd2sBUOJ
D11NUCqH8c7EctOquOZ5zTcWxHiWWbLyKQwUw2SUvnWa5SSbi8kI8q9MTPsPvhwt
... snip ...
r/T7zLrJeiljDxvX+6TyawyWQngF6v1Hq6FRV0O0bOp9Npt5zqCbDGs/iE4EGBEC
AAYFAj+dnTwAEgkQtEJp0E8qb9IHZUdQRwABAf/+AJwNVicN6A0I7EOfWx50PDHD
7SHw5wCfUJkeh/XlCrGdPASe/AXZB44jl2c=
=aXEw
-----END PGP PUBLIC KEY BLOCK-----
</pre>

The important thing to notice, amid the HTML markup, is that the key is 'armoured text' well set off with start and end markers, so that GnuPG (and also RPM) may pick the key out of the chaff.

We discussed previously the chain of steps we used to decide that the key was authentic, and worthy of trust; as such we do not repeat them here.

Then, using the 'sudo' command to temporarily attain 'root' rights for the importation step, we can insert (import into the RPM database) the locally checked key:

$ sudo rpm -import fedora-key

Or, assuming that we will do a post-insertion check, we can do the import directly from the keyserver:

$ sudo rpm -import "http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4F2A6FD2"

Then we can re-inventory keys, and see the new one present, and the full name under which it may be found; part of the name is, conveniently, the 'fingerprint' of that key.

$ rpm -qa gpg\*
$ rpm -qi gpg-pubkey-4f2a6fd2-3fcdf8c9

Hopefully this clears things up a bit.

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.

... letters, we get letters

To : (elided)
Cc : CentOS security role account
Attchmnt:
Subject : vulnerability cache poisoning in bind-9.3.4-6.0.2.P1.el5_2
----- Message Text -----

On Thu, 28 Aug 2008, (elided) wrote:

> I haven't found any update to the bind software in the
> repositories. Is it necessary to download the source of bind
> version 9.5.x and compile it?
> S.O CentOS 5.2

No; CentOS uses the RPM packaging management system, and 'yum' (which itself uses the 'rpm' programs). This issue has been addressed already for people running updates regularly.

You do not mention the CVE you are concerned about. This is
the process to see the most recent updates as to CVE's.

The RPM package manager permits you to view what has been
addressed in recent time thus:

~]$ rpm -q --changelog bind | \
  grep -i cve | tac | tail
- added upstream patch for correct SIG handling - CVE-2006-4095
- added fix for #225229 - CVE-2007-0494 BIND dnssec denial of service
- added fix for #224445 - CVE-2007-0493 BIND might crash after
- fixed cryptographically weak query id generator (CVE-2007-2926)
- CVE-2007-6283 (#419421)
- CVE-2008-0122 (small buffer overflow in inet_network)
- CVE-2008-1447
~]$

and then viewing:

http://cve.mitre.org/cve/cve.html

Obviously, I used some command line tools to winnow down the
mass of Changelog; one could feed it to '| less' as well.

Placing: 2008-0122 into the: Search Master Copy of CVE, we
see:

CVE-ID
CVE-2008-1447
(under review)

Learn more at National Vulnerability Database (NVD)
• Severity Rating • Fix Information • Vulnerable Software
Versions • SCAP Mappings

Description
The DNS protocol, as implemented in (1) BIND 8 and 9 before
9.5.0-P1, 9.4.2-P1, and 9.3.5-P1; (2) Microsoft DNS in Windows
2000 SP4, XP SP2 and SP3, and Server 2003 SP1 and SP2; and
other implementations allow remote attackers to spoof DNS
traffic via a birthday attack that uses in-bailiwick referrals
to conduct cache poisoning against recursive resolvers,
related to insufficient randomness of DNS transaction IDs and
source ports, aka "DNS Insufficient Socket Entropy
Vulnerability" or "the Kaminsky bug."

------------------------------------

which is the recent Kaminsky bug. As it is mentioned, we see
it was addressed by CentOS in:

~]$ rpm -q bind
bind-9.3.4-6.0.2.P1.el5_2
~]$ rpm -q bind

Thanks for asking.