Linux – Bad RPM Signatures

centosgpglinuxrpm

I'm trying to set up a repo that contains both CentOS 6.4 and 5.9 packages. The machine itself is 6.4.

I've created a GPG key and have been able to sign my 6.4 packages no problem. When I create them for 5.9 though I get header errors. I realize that the versions of RPM are different, so I installed 4.2 (the version that ships with 5.9) and tried signing with that… it still doesn't work.

[root@usch1ksv01 RPMS]# /usr/local/bin/rpm --version
RPM version 4.4.2.3

[root@usch1ksv01 RPMS]# rpm --version
RPM version 4.8.0

[root@usch1ksv01 RPMS]# /usr/local/bin/rpm --checksig ypserv-2.19-10.el5_9.1.x86_64.rpm 
ypserv-2.19-10.el5_9.1.x86_64.rpm: RSA sha1 (MD5) (PGP) md5 NOT OK (MISSING KEYS: PGP#a8228ab5) 

[root@usch1ksv01 RPMS]# rpm --checksig ypserv-2.19-10.el5_9.1.x86_64.rpm 
ypserv-2.19-10.el5_9.1.x86_64.rpm: rsa sha1 (md5) pgp md5 OK

I don't understand why the signatures aren't working for the older version of RPM… I'm just doing an rpmsign –addsign , which clearly works for the new version but not the old. I've used both versions of RPM to try signing too.

I'm totally out of ideas, so any help would be greatly appreciated! Thanks!

Best Answer

The MISSING KEY indicates that you have not done an rpm --import for the 0xa8228ab5 public key.

You can see the pub keys imported into an rpmdb

 rpm -q gpg-pubkey

After import (you may need to export an ASCII-armored pubkey using gnupg), you should see a gpg-pubkey with keyed in the version field.

Related Solutions

RPM Build Issue

It helps to understand a little about how RPM works here.

RPM will be automatically adding requirements for particular classifications of file that it knows about (eg ELF shared libraries, #! scripts, etc):

http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-auto-depend.html

What is happening here is that some of the contents of the payload have been picked up with having requirements that are not packaged:

/home/rpmbuild/python/Python-2.6.4-root/usr/bin/python2.6
/usr/local/bin/python2.6

We can verify this by running rpmbuild -bi Python.spec to run the build up to the install stage. Based on the information supplied above you could search for files:

find /home/rpmbuild/python/Python-2.6.4-root/ -type f -exec grep \ /home/rpmbuild/python/Python-2.6.4-root/usr/bin/python2.6

I'd say you're looking at:

/home/rpmbuild/Python-2.6.4-root/usr/bin/python2.6-config for the the file that has a shebang that refers to the full buildroot and a bunch of scripts that refer to /usr/local/bin/python2.6

RPM isn't doing anything wrong here, and the details of the right way to fix this up will often be specific to the build of the package you're building.

One approach to fixing this would be to set AutoProvReq: no in the preamble of the SPEC file, eg directly after Group: Python. This should give you an installable RPM but you could argue that it's not taking full advantage of RPM's dependency model and you'd have incorrect paths in some of your Python package files.

Lets specifically look at the Python build and try and understand what we could do to fix this in a more comprehensive way.

Your %install section uses the macro %makeinstall which expands by default as:

[pnasrat@centos5 ~]$ rpm -E '%makeinstall'

  /usr/bin/make \
    prefix=/usr \
    exec_prefix=/usr \
    bindir=/usr/bin \
    sbindir=/usr/sbin \
    sysconfdir=/etc \
    datadir=/usr/share \
    includedir=/usr/include \
    libdir=/usr/lib64 \
    libexecdir=/usr/libexec \
    localstatedir=/var \
    sharedstatedir=/usr/com \
    mandir=/usr/share/man \
    infodir=/usr/share/info \
  install

For reference I tend to consult the upstream Fedora SPEC, which is much more complicated but can be made to build (with some modification and a patch for autotools versions IIRC) a parallel python26 package. I'm not going to go into the detail of that right now but if we look at how they install the key line is:

make install DESTDIR=%{buildroot}

I'd strongly recommend doing that rather than disabling AutoProvReq. As Python is a libtool based build that is probably better than the %makeinstall macro as you've already configured prefix. That seems to do the right thing by inspecting here. Note, if you are rebuilding with this change you'll also want to add:

%clean
rm -rf $RPM_BUILD_ROOT

And want a similar rm line at the beginning of the %install section. This all seems to work for me:

[pnasrat@centos5 RPMS]$ rpm --test -ivh x86_64/Python-2.6.4-1.x86_64.rpm 
Preparing...                ########################################### [100%]

It might well be worth using a python2.6 package provided elsewhere, I believe IUSCommunity provides packages, as documented here - http://agilesysadmin.net/recent-python-on-rhel-or-centos. These are probably much closer to the fedora packages.

Redhat – Bad signatures or NOKEY errors on RPMs I just signed

It's a cluster of RPM bugs. Not just one bug, or two bugs. A nest of the critters. RPM fails (failed?) to validate signed packages, didn't understand v4 GPG signatures but didn't notice it didn't understand them, didn't understand some key sizes and types but didn't notice it didn't understand that, and also choked on subkeys!

This lifesaving blog entry by Jacob Helwig, as pointed out by a colleague, covers the issues:

You must force GnuPG to use v3 signatures when signing on/for RHEL / CentOS 5 or 6 in your `

%__gpg_sign_cmd %{__gpg} \
    gpg --force-v3-sigs --digest-algo=sha1 --batch --no-verbose --no-armor \
    --passphrase-fd 3 --no-secmem-warning -u "%{_gpg_name}" \
    -sbo %{__signature_filename} %{__plaintext_filename}

because RPM doesn't check the sigversion or validate the signed package after signing it, and these distros contain GPG versions that default to v4 signatures.

You must also generate a 2048 bit signing-only RSA key with no subkeys.

A couple of relevant bugs:

Best Answer

Related Solutions

RPM Build Issue

Redhat – Bad signatures or NOKEY errors on RPMs I just signed

Related Topic