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): spacewalk-java-2.0.2-39.el6sat.noarch How reproducible: 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 Actual results: 5.5.0: Signing Key: 0252331999000a09 5.6.0: Signing Key: 1054b7a24bd6ec30 Expected results: "Signing Key:" should match. Additional info: 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: jhutar Comment: Example Key for RPM Book You selected this USER-ID: "Example Key for RPM Book (Example Key for RPM Book) <jhutar>" 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) <jhutar> 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 %_signature pgp %_gpg_name Example Key for RPM Book %_gpg_path /home/pok/.gnupg/ $ rpm --resign rpmbuild/RPMS/x86_64/pragha-1.1.1-3.fc19.jhutar.x86_64.rpm Enter pass phrase: Pass phrase is good. rpmbuild/RPMS/x86_64/pragha-1.1.1-3.fc19.jhutar.x86_64.rpm: $ 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 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.