Bug 142574 - rpm --import in rpm %post script screws up the rpm database
Summary: rpm --import in rpm %post script screws up the rpm database
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-12-10 18:14 UTC by Orion Poplawski
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-18 02:48:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Example package (140.99 KB, application/octet-stream)
2004-12-10 18:15 UTC, Orion Poplawski
no flags Details

Description Orion Poplawski 2004-12-10 18:14:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040913

Description of problem:
I generate and sign a number of custom packages.  Some of these are
distro version agnostic and so are installed on all version of FC. 
The packages signed with earlier (FC2) versions of rpm cause problems
with the current version of rpm.

So, on a FC2 box:
# rpm -K /data/sw1/CoRPMS/noarch/logwatch-5.2.2-2.cora7.noarch.rpm
/data/sw1/CoRPMS/noarch/logwatch-5.2.2-2.cora7.noarch.rpm: (sha1) dsa
sha1 md5 gpg OK

On a x86_64 FC3 box:
# rpm -K /data/sw1/CoRPMS/noarch/logwatch-5.2.2-2.cora7.noarch.rpm
error: rpmdbNextIterator: skipping h#     238 Header V3 DSA signature:
BAD, key ID d142dbfb
Segmentation fault

Once it has been intalled:
# rpm -q logwatch
error: rpmdbNextIterator: skipping h#     238 Header V3 DSA signature:
BAD, key ID d142dbfb
logwatch-5.2.2-2.cora7






Version-Release number of selected component (if applicable):
rpm-4.3.2-21

How reproducible:
Sometimes

Steps to Reproduce:
1. Sign a package on i386 FC2 system
2.  Install on x86_64 FC3 system
3.
    

Additional info:

Comment 1 Orion Poplawski 2004-12-10 18:15:30 UTC
Created attachment 108337 [details]
Example package

Comment 2 Orion Poplawski 2004-12-10 19:13:17 UTC
I think this may just be a x86_64 issue.  Created a new package and
signed on FC3 i386 and it stills gives the segfault when checking on
x86_64.

In fact, I created the package on i386, signed on x86_64 and it still
segfaults:

[root@coop01 ~]# rpm --addsign
/data/sw1/CoRPMS/noarch/logwatch-5.2.2-2.cora7.noarch.rpm
Enter pass phrase:
Pass phrase is good.
/data/sw1/CoRPMS/noarch/logwatch-5.2.2-2.cora7.noarch.rpm:
[root@coop01 ~]# rpm -K
/data/sw1/CoRPMS/noarch/logwatch-5.2.2-2.cora7.noarch.rpm
error: rpmdbNextIterator: skipping h#     239 Header V3 DSA signature:
BAD, key ID cc2de824
Segmentation fault


Having trouble with imported keys too:

# rpm -qa gpg-pubkey*
error: rpmdbNextIterator: skipping h#     238 Header V3 DSA signature:
BAD, key ID d142dbfb
error: rpmdbNextIterator: skipping h#     172 Header V3 DSA signature:
BAD, key ID d142dbfb
error: rpmdbNextIterator: skipping h#     238 Header V3 DSA signature:
BAD, key ID d142dbfb
error: rpmdbNextIterator: skipping h#     234 Header V3 DSA signature:
BAD, key ID d142dbfb
gpg-pubkey-897da07a-3c979a7f
gpg-pubkey-1cddbca9-3f9da14c
gpg-pubkey-e418e3aa-3f439953
gpg-pubkey-cc2de824-419b83cd
gpg-pubkey-db42a60e-37ea5438
gpg-pubkey-4f2a6fd2-3f9d9d3b
gpg-pubkey-30c9ecf8-3f9da3f7
gpg-pubkey-d142dbfb-4193ecf8


Comment 3 Jeff Johnson 2004-12-10 23:18:35 UTC
So the problem is not arch related it appears.

Nuke /var/lib/rpm/Pubkeys, reimport each of the keys
one by one, and tell me which pubkey is at fault please.
Then I'll be able to tell you what to do.

Hang on, lemme check 0xd142dbfb which appears to be the cause ...


Comment 4 Jeff Johnson 2004-12-10 23:33:18 UTC
Here's your pubkey:
=======================
hkp://sks.keyserver.penguin.de/pks/lookup?op=get&search=0x3919f3aed142dbfb
V4 Public Key(6) DSA(17) Thu Nov 11 17:51:36 2004(0x4193ecf8)
     p = [1024]:
8eb8affef604cbe34bbcd9847eeda20845c1c3f4d1683d424e3aba3c97c5633828bb862b6fed25ef3ce0767ea5a5419dda3e8addb5614a2acb6e2ab207f18c59ed75c3bdefadd27c56a07d816c72afadd1217b9e32eaff89747de32aa0739b8209d9861ebcc780741f20d60932dadb7f4da82eaf3fa20300cce597ef79cf5e67
     q = [ 160]: f0b8032af0aeda6ae1bd0a551369bbf12aabb5b5
     g = [1022]:
3c8403dc45de983507b9ced11cba460f484c7e29c0cb7a20f6483e0d3d61ee9faef1b7a3384edcbc29565f6054a603f333c8579f2f7f69f08f2c38a01665317f017a1c6263719fcca5e876bc28b9bcae932c650e1d58b47a5547eb48b17ce6dc29326ea386c19c20afe0f069e434949df85a3c848d85c21ddc1d782cfae21f88
     y = [1023]:
57683efc520c3ebd49a86f206e6a9b477ddedb6d5d1faaf7d69123076a1dcca67150679117256eeb702d0b6b558c24099896d70abddec214bb3f08eba9b796a527307574bdf9e425442e1d920a879a232ca95d747c224c3bb33c2f392e636d358419d4fde8db97cd78a27e3a7d034caccf77f40a7daa2384926aca34427f8c82
User ID(13) "Orion Poplawski <orion.com>"
V4 Signature(2) DSA(17) SHA1(2) Positive certification of a User ID
and Public Key(19)
    signature creation time(2) Thu Nov 11 17:51:36 2004(0x4193ecf8)
    key flags(27) 03
    preferred symmetric algorithms(11) AES(256-bit key)(9) AES(192-bit
key)(8) AES(128-bit key)(7) CAST5(3) 3DES(2)
    preferred hash algorithms(21) SHA1(2) RIPEMD160(3)
    preferred compression algorithms(22) ZLIB(2) ZIP(1)
    features(30) 01
    key server preferences(23) No-modify(128)
    issuer key ID(16) 3919f3aed142dbfb
 signhash16 dc90
     r = [ 159]: 513c92446d96fa2f0489ef6e59b84b2ded490901
     s = [ 159]: 71e6801cd8c44bc65bf6bcae6c52f03f3cb09539
V4 Public Subkey(14) Elgamal(Encrypt-Only)(16) Thu Nov 11 17:51:39
2004(0x4193ecfb)
     p = [1024]:
f98c4d79ab6b5e028c780ca3d6bce1300b845adf22267e10a9a5bb3fb89e4556fd0c292765b3995f7b369da1e3e8830e09cfa2ce9c4e4e699651378b27317bdb81dedd111ac104294c273134b9b4ad51fb8413b9d5a83a29421e22b0314fc962cb69a372c52833229d988b9948d31f9a50e8cd4eb3555d8d74ef72e8e07eb52b
     g = [   3]: 05
     y = [1024]:
86b9f49605ba16f7a93dbf268aa7226f753e9041d69fd952e524d4a8bebbc5e5c5d57cbca024b95bbc770c19ffee72afc6185f7fc436c56fa39a248e7f6327b29befffa80a49f277f89529e0ec7331c805787e958b3ae8228471cb5d5eaeb529354a855d502bc5ca68f133b8d894b24406caeeee4e75bbeffd8e6a3575f687d2
V4 Signature(2) DSA(17) SHA1(2) Subkey Binding Signature(24)
    signature creation time(2) Thu Nov 11 17:51:39 2004(0x4193ecfb)
    key flags(27) 0c
    issuer key ID(16) 3919f3aed142dbfb
 signhash16 fba9
     r = [ 160]: adab3b4cbc9db21c4cd2660c3f6ced5f9f1c35a2
     s = [ 160]: bb298530e7de27b0f064e7f125984c49ea0fd5c3

This pubkey is not going to work
for signing packages in general. Signing with the public
subkey is not going to work either.

FWIW, the logwatch package verifies correctly with rpm-4.4,
available at
   ftp://jbj.org/pub/rpm-4.4

Note: carefully that rpm-4.4 is unlikely to be widely available
for quite some time, and so you should generate a different key,
structured like one of the current signing keys, and sign the
pubkey if you wish to sign rpm packages for distribution.

rpm supports only a subset of RFC-2440, and uses gpg for signing,
but beecrypt for verification.


Comment 5 Jeff Johnson 2004-12-10 23:34:33 UTC
Actually, all you need to do is sign the pubkey I believe.

Comment 6 Jeff Johnson 2004-12-10 23:42:37 UTC
Hmmm, and my brain fart, I missed

V4 Signature(2) DSA(17) SHA1(2) Positive certification of a User ID
and Public Key(19)

which is what rpm uses for a fingerprint.

So nuking /var/lib/rpm/Pubkeys and reimporting should fix your problem.

Is that the case?

Comment 7 Orion Poplawski 2004-12-10 23:51:35 UTC
I'm pretty confused at this point and I've gotten things kind of screwy:

# rpm -qa gpg-*
gpg-pubkey-cc2de824-419b83cd
gpg-pubkey-cc2de824-419b83cd
# rpm -e gpg-pubkey-cc2de824-419b83cd
error: "gpg-pubkey-cc2de824-419b83cd" specifies multiple packages
# rm /var/lib/rpm/Pubkeys
rm: remove regular file `/var/lib/rpm/Pubkeys'? y
[root@coop01 fedora-release-3]# rpm -qa gpg-*
gpg-pubkey-cc2de824-419b83cd
gpg-pubkey-cc2de824-419b83cd

But other things are working better:

root@coop01 noarch]# rpm --checksig logwatch-5.2.2-2.cora7.noarch.rpm
logwatch-5.2.2-2.cora7.noarch.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK
(MISSING KEYS: GPG#cc2de824)
[root@coop01 noarch]# rpm --import ../RPM-GPG-KEY.root
[root@coop01 noarch]# rpm --checksig logwatch-5.2.2-2.cora7.noarch.rpm
logwatch-5.2.2-2.cora7.noarch.rpm: (sha1) dsa sha1 md5 gpg OK

But I've got multiple references to the keyid in the package list. 
How do I get rid of them? --rebuilddb?

How did things get buggered in the first place?  If you have ideas to
test I can do that.  This system can be reinstalled via kickstart as
many times as necessary.  Takes about 3 minutes to do an istall...




Comment 8 Orion Poplawski 2004-12-10 23:59:51 UTC
Here's where keys are handled in the install:

my custom yum package contains my two keys, plus those for dag,
freshrpms, and atrpms.  The %post script does:

/bin/rpm --import %{_docdir}/%{name}-%{version}/RPM-GPG-KEY*

hmm, that probably doesn't work - macros probably don't work in %post?


My kickstart post script does:

#Import the distro keys
rpm --import /usr/share/doc/fedora-release-?/RPM-GPG-KEY*

So, fresh install, I get:
[root@coop01 ~]# rpm -qa >&-
error: rpmdbNextIterator: skipping h#     238 Header V3 DSA signature:
BAD, key ID d142dbfb
error: rpmdbNextIterator: skipping h#     238 Header V3 DSA signature:
BAD, key ID d142dbfb
[root@coop01 ~]# rpm -qa gpg-pubkey*
error: rpmdbNextIterator: skipping h#     238 Header V3 DSA signature:
BAD, key ID d142dbfb
error: rpmdbNextIterator: skipping h#     238 Header V3 DSA signature:
BAD, key ID d142dbfb
gpg-pubkey-897da07a-3c979a7f
gpg-pubkey-1cddbca9-3f9da14c
gpg-pubkey-e418e3aa-3f439953
gpg-pubkey-db42a60e-37ea5438
gpg-pubkey-4f2a6fd2-3f9d9d3b
gpg-pubkey-30c9ecf8-3f9da3f7

and importing the keys doesn't help:
[root@coop01 ~]# rpm --import /usr/share/doc/yum-2.1.11/RPM-GPG-KEY.*
[root@coop01 ~]# rpm -qa gpg-pubkey*
error: rpmdbNextIterator: skipping h#     238 Header V3 DSA signature:
BAD, key ID d142dbfb
error: rpmdbNextIterator: skipping h#     172 Header V3 DSA signature:
BAD, key ID d142dbfb
error: rpmdbNextIterator: skipping h#     238 Header V3 DSA signature:
BAD, key ID d142dbfb
error: rpmdbNextIterator: skipping h#     234 Header V3 DSA signature:
BAD, key ID d142dbfb
gpg-pubkey-897da07a-3c979a7f
gpg-pubkey-1cddbca9-3f9da14c
gpg-pubkey-e418e3aa-3f439953
gpg-pubkey-6b8d79e6-3f49313d
gpg-pubkey-d142dbfb-4193ecf8
gpg-pubkey-db42a60e-37ea5438
gpg-pubkey-4f2a6fd2-3f9d9d3b
gpg-pubkey-30c9ecf8-3f9da3f7
gpg-pubkey-66534c2b-3e60b428
gpg-pubkey-e42d547b-3960bdf1
gpg-pubkey-cc2de824-419b83cd
[root@coop01 ~]# rpm --checksig
/data/sw1/CoRPMS/noarch/logwatch-5.2.2-2.cora7.noarch.rpm
error: rpmdbNextIterator: skipping h#     239 Header V3 DSA signature:
BAD, key ID cc2de824
Segmentation fault


Let me fix my yum package and try again...





Comment 9 Orion Poplawski 2004-12-11 00:08:30 UTC
Here's the armored public key I'm importing:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.4 (GNU/Linux)

mQGiBEGT7PgRBACOuK/+9gTL40u82YR+7aIIRcHD9NFoPUJOOro8l8VjOCi7hitv
7SXvPOB2fqWlQZ3aPordtWFKKstuKrIH8YxZ7XXDve+t0nxWoH2BbHKvrdEhe54y
6v+JdH3jKqBzm4IJ2YYevMeAdB8g1gky2tt/Tagurz+iAwDM5Zfvec9eZwCg8LgD
KvCu2mrhvQpVE2m78SqrtbUD/jyEA9xF3pg1B7nO0Ry6Rg9ITH4pwMt6IPZIPg09
Ye6frvG3ozhO3LwpVl9gVKYD8zPIV58vf2nwjyw4oBZlMX8BehxiY3GfzKXodrwo
ubyukyxlDh1YtHpVR+tIsXzm3CkybqOGwZwgr+DwaeQ0lJ34WjyEjYXCHdwdeCz6
4h+IA/9XaD78Ugw+vUmobyBuaptHfd7bbV0fqvfWkSMHah3MpnFQZ5EXJW7rcC0L
a1WMJAmYltcKvd7CFLs/COupt5alJzB1dL355CVELh2SCoeaIyypXXR8Ikw7szwv
OS5jbTWEGdT96NuXzXiifjp9A0ysz3f0Cn2qI4SSaso0Qn+MgrQlT3Jpb24gUG9w
bGF3c2tpIDxvcmlvbkBjb3JhLm53cmEuY29tPoheBBMRAgAeBQJBk+z4AhsDBgsJ
CAcDAgMVAgMDFgIBAh4BAheAAAoJEDkZ867RQtv73JAAn1E8kkRtlvovBInvblm4
Sy3tSQkBAJ9x5oAc2MRLxlv2vK5sUvA/PLCVObkBDQRBk+z7EAQA+YxNeatrXgKM
eAyj1rzhMAuEWt8iJn4QqaW7P7ieRVb9DCknZbOZX3s2naHj6IMOCc+izpxOTmmW
UTeLJzF724He3REawQQpTCcxNLm0rVH7hBO51ag6KUIeIrAxT8liy2mjcsUoMyKd
mIuZSNMfmlDozU6zVV2NdO9y6OB+tSsAAwUEAIa59JYFuhb3qT2/JoqnIm91PpBB
1p/ZUuUk1Ki+u8XlxdV8vKAkuVu8dwwZ/+5yr8YYX3/ENsVvo5okjn9jJ7Kb7/+o
Cknyd/iVKeDsczHIBXh+lYs66CKEcctdXq61KTVKhV1QK8XKaPEzuNiUskQGyu7u
TnW77/2OajV19ofSiEkEGBECAAkFAkGT7PsCGwwACgkQORnzrtFC2/v7qQCgras7
TLydshxM0mYMP2ztX58cNaIAoLsphTDn3iew8GTn8SWYTEnqD9XD
=djfA
-----END PGP PUBLIC KEY BLOCK-----


Comment 10 Orion Poplawski 2004-12-11 00:23:21 UTC
Removing the --import from the yum %post script makes the install
work.  I guess importing keys inside of a %post script is a bad thing
to do.

[root@coop01 ~]# rpm -qa >&-
[root@coop01 ~]# rpm -qa gpg*
gpg-pubkey-897da07a-3c979a7f
gpg-pubkey-1cddbca9-3f9da14c
gpg-pubkey-e418e3aa-3f439953
gpg-pubkey-db42a60e-37ea5438
gpg-pubkey-4f2a6fd2-3f9d9d3b
gpg-pubkey-30c9ecf8-3f9da3f7
[root@coop01 ~]# rpm --checksig /data/sw1/CoRPMS/noarch/*
/data/sw1/CoRPMS/noarch/logwatch-5.2.2-2.cora7.noarch.rpm: (SHA1) DSA
sha1 md5 (GPG) NOTOK (MISSING KEYS: GPG#cc2de824)
/data/sw1/CoRPMS/noarch/yum-2.0.7-1.1.cora3.noarch.rpm: (SHA1) DSA
sha1 md5 (GPG) NOT OK(MISSING KEYS: GPG#d142dbfb)
[root@coop01 ~]# rpm --import /usr/share/doc/yum-2.1.11/RPM-GPG-KEY.*
[root@coop01 ~]# rpm --checksig /data/sw1/CoRPMS/noarch/*
/data/sw1/CoRPMS/noarch/logwatch-5.2.2-2.cora7.noarch.rpm: (sha1) dsa
sha1 md5 gpg OK
/data/sw1/CoRPMS/noarch/yum-2.0.7-1.1.cora3.noarch.rpm: (sha1) dsa
sha1 md5 gpg OK


Comment 11 Jeff Johnson 2004-12-11 01:52:18 UTC
Hmmm, I've done --import in %post before.

Finding a reproducer is moderately hard.

Meanwhile, the first is probably not diificult. One way, from the CLI,
is to nuke all the pubkeys
    rpm -e gpg-pubkey --allmatches
and reimport.

Another, slightly more brutal way, is to do
    rm -f /var/lib/rpm/Pubkeys
and then reimport.

Verify by doing
    rpm -qi gpg-pubkey
and test that pubkey is actually installed by doing
    rpm -qavv
(which will display signature verficiation for all headers),
or equivalently
    rpm -K foo*.rpm
for package signed with publey.

If signature verifies, then pubkey is imported correctly.

Does that get you sorted out? I believe all that you have is
a keyring (i.e. /var/lib/rpm/Pubkeys) problem, not anything else.

Comment 12 Orion Poplawski 2004-12-13 16:44:54 UTC
Well, the corrupt keyring  is easily reproducible for me.  If I
install with the yum package that does --import, I end up with a
corrupted keyring.  When I removed it, no problems.

Also, I've been having trouble doing upgrades were just after
upgrading the yum package, the rpm database would get corrupted and
the install would abort.  Lots of :

Upgrading yum-2.1.11-3.cora3.noarch.
Upgrading ncftp-3.1.8-2.i386.
error: db4 error(-30978) from dbcursor->c_put: DB_RUNRECOVERY: Fatal
error, run database
recovery
error: db4 error(-30978) from db->sync: DB_RUNRECOVERY: Fatal error,
run database recover
y
error: db4 error(-30978) from db->sync: DB_RUNRECOVERY: Fatal error,
run database recover
y
error: db4 error(-30978) from db->cursor: DB_RUNRECOVERY: Fatal error,
run database recov
ery
error: db4 error(-30978) from db->get: DB_RUNRECOVERY: Fatal error,
run database recovery
error: error(-30978) getting "ncftp" records from Name index
error: db4 error(-30978) from db->sync: DB_RUNRECOVERY: Fatal error,
run database recover
y
error: db4 error(-30978) from db->cursor: DB_RUNRECOVERY: Fatal error,
run database recov
ery

So it may cause other problems as well.  I haven't done an upgrade yet
with the non-importing yum yet.  But as far as I'm concerned, doing
the import is doing bad things.


Comment 13 Jeff Johnson 2005-02-07 22:57:50 UTC
Can you try to reproduce the problem with rpm-4.4.1-0.18
from FC4 please? If still a problem, then the fix will
be in rpm-4.4.1 initially. What would help to reproduce
is a ptr to exactly the package you are seeing the problem
with.

Comment 14 Orion Poplawski 2005-02-11 21:19:04 UTC
When FC4test1 is released I try to reproduce.  The package that causes
the problem is a package we have that we build into our custom
distribution.  I don't think any stock Fedora packages call rpm
--import from the install scripts.

I've since moved away from doing this and instead importing as part of
the anaconda post install script, but I may want to move back.

Comment 15 Orion Poplawski 2005-03-23 00:14:46 UTC
Tried with FC4test1.  Made a custom yum package that does an rpm --import of
some keys during the %post script.  Works better than before in that the
installation completes okay.  However, after install rpm does not report and gpg
keys installed and gives some errors:

error: rpmdbNextIterator: skipping h#     279 blob size(3088): BAD, 8 + 16 *
il(71) + dl(14112)
error: rpmdbNextIterator: skipping h#     279 blob size(3088): BAD, 8 + 16 *
il(71) + dl(14112)
error: rpmdbNextIterator: skipping h#     279 blob size(3088): BAD, 8 + 16 *
il(71) + dl(14112)
error: rpmdbNextIterator: skipping h#     276 blob size(2448): BAD, 8 + 16 *
il(73) + dl(7180)
error: rpmdbNextIterator: skipping h#     278 blob size(3160): BAD, 8 + 16 *
il(4337231) + dl(-1327856437)
error: rpmdbNextIterator: skipping h#     280 blob size(3060): BAD, 8 + 16 *
il(1647786297) + dl(909654324)
error: rpmdbNextIterator: skipping h#     279 blob size(3088): BAD, 8 + 16 *
il(71) + dl(14112)
error: rpmdbNextIterator: skipping h#     279 blob size(3088): BAD, 8 + 16 *
il(71) + dl(14112)
error: rpmdbNextIterator: skipping h#     279 blob size(3088): BAD, 8 + 16 *
il(71) + dl(14112)
error: rpmdbNextIterator: skipping h#     279 blob size(3088): BAD, 8 + 16 *
il(71) + dl(14112)
error: rpmdbNextIterator: skipping h#     277 blob size(3340): BAD, 8 + 16 *
il(-2124398626) + dl(786448275)
error: rpmdbNextIterator: skipping h#     279 blob size(3088): BAD, 8 + 16 *
il(71) + dl(14112)
error: rpmdbNextIterator: skipping h#     279 blob size(3088): BAD, 8 + 16 *
il(71) + dl(14112)
error: rpmdbNextIterator: skipping h#     279 blob size(3088): BAD, 8 + 16 *
il(71) + dl(14112)


Comment 16 Jeff Johnson 2006-03-18 02:48:57 UTC
I'm able to import the pubkey in comment #9 in a time-1.7-27.2.1.i386 package using rpm-4.4.6-0.5 w/
o rpmdb problems.


Note You need to log in before you can comment on or make changes to this bug.