Red Hat Bugzilla – Bug 1008430
different "Signing Key:" on 5.5.0 and 5.6.0
Last modified: 2018-04-09 05:14:09 EDT
Created attachment 798228 [details]
custom rpm I have used
Description of problem:
I have pushed one package to two satellites and it have different "Signing Key:" on 5.5.0 and 5.6.0.
Version-Release number of selected component (if applicable):
1 of 1
Steps to Reproduce:
1. Take attached package and push it to satellites 5.5.0 and 5.6.0
2. Look at webUI to this package details
5.5.0: Signing Key: 0252331999000a09
5.6.0: Signing Key: 1054b7a24bd6ec30
"Signing Key:" should match.
I have been testing bug 838705 when I have seen this - maybe could be connected?
I have tried with different package and "Signing Key:" matches
How I have signed the package:
$ gpg2 --gen-key
gpg (GnuPG) 2.0.19; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: Example Key for RPM Book
Email address: email@example.com
Comment: Example Key for RPM Book
You selected this USER-ID:
"Example Key for RPM Book (Example Key for RPM Book) <firstname.lastname@example.org>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 8FAE20CA marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0 valid: 4 signed: 3 trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1 valid: 3 signed: 1 trust: 0-, 0q, 0n, 2m, 1f, 0u
gpg: next trustdb check due at 2013-10-08
pub 2048R/8FAE20CA 2013-09-13
Key fingerprint = 0B84 0FD8 8D50 E1B6 165E ABB7 C3DB 0329 8FAE 20CA
uid Example Key for RPM Book (Example Key for RPM Book) <email@example.com>
Note that this key cannot be used for encryption. You may want to use
the command "--edit-key" to generate a subkey for this purpose.
$ cat .rpmmacros
%_gpg_name Example Key for RPM Book
$ rpm --resign rpmbuild/RPMS/x86_64/pragha-1.1.1-3.fc19.jhutar.x86_64.rpm
Enter pass phrase:
Pass phrase is good.
$ rpm --checksig rpmbuild/RPMS/x86_64/pragha-1.1.1-3.fc19.jhutar.x86_64.rpm
rpmbuild/RPMS/x86_64/pragha-1.1.1-3.fc19.jhutar.x86_64.rpm: RSA sha1 ((MD5) PGP) md5 NOT OK (MISSING KEYS: (MD5) PGP#8fae20ca)
RPM have this:
$ rpm -Kv rpmbuild/RPMS/x86_64/pragha-1.1.1-3.fc19.jhutar.x86_64.rpm
Header V4 RSA/SHA1 Signature, key ID 8fae20ca: NOKEY
Header SHA1 digest: OK (17220397b416ddff8d549aeb2f2dc601c0b2caad)
V4 RSA/SHA1 Signature, key ID 8fae20ca: NOKEY
MD5 digest: OK (b9961e922505c04dbe6bda0d196cc3bb)
After importing attached package to my machine, I see:
Signing Key: c3db03298fae20ca
and it was detected as *gpg* package key type.
We agreed with Milan that it seems that backend/rhnpush does not correctly parse this type of signature. We need to start support pgp signatures to resolve this BZ/RFE.
Not a regression.
We have re-reviewed this bug, as part of an ongoing effort to improve Satellite/Proxy feature and bug updates, review and backlog.
This is a low priority bug and has no currently open customer cases. While this bug may still valid, we do not see it being implemented prior to the EOL of the Satellite 5.x product. As such, this is being CLOSED DEFERRED.
Closing now to help set customer expectations as early as possible. You are welcome to re-open this bug if needed.