Description of problem:
I recently tried signing an RPM with a subkey of my main GPG key. It worked,
but not in the way that I would have expected. Now when I gave my uid in the
%_gpg_name macro, it did pick the subkey to sign with automatically. (This may
have been due to the fact that this was the only signing subkey.) When I looked
at the RPM file using "rpm -qip", it showed the RPM as having been signed by the
subkey, which is what I would expect. Namely, the last 8 hex-characters of the
Key ID field were the last 8 hex-characters of the GPG fingerprint of the
subkey. However, the version of the GPG key in the RPM database was the same as
the fingerprint of the parent key. That also makes sense, as that is how one
has to handle the key in general. Even though they displayed different key
fingerprints, the RPM would verify correctly. But there was no indication that
the two were part of the same key. Perhaps the RPM should indicate that it was
signed using key x which is a subkey of key y.
See http://fortytwo.ch/gpg/subkeys for a description of why multiple subkeys are
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Make a brand new GPG key that can sign.
2.Add a signing subkey to this GPG key.
3.Add the uid of this key to the %_gpg_name macro in your .rpmmacros file.
4.Import the parent key (including the subkey) using rpm --import.
5.Sign an RPM file using this subkey.
When you look at the RPM using "rpm -qip _rpm_filename_", you see the
fingerprint for the subkey, but nothing indicating the parent key. When you run
"rpm -q gpg-pubkey", you see the fingerprint for the parent key, but nothing
indicating the subkey.
I would hope to see some kind of linkage between the parent key and the subkey.
There are 2 elements needed to support signining subkeys:
1) adding the signining subkey fingerprint to the Pubkeys index so that the key is found.
2) Verifying the signature that binds the subkey to the primary key.
If you can export the signing subkey as an armored pubkey certificate, then
its likely that rpm --import and signature verification will just work. Whether
that is a wise or proper certificate is a whole different matter.
User email@example.com's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening as this is a feature that is needed for supporting offline master keys. The master keys should not be used for anything else than subkey and peer key signatures and revocations.
Fixed upstream as a173d781a631a92524ce5be364c679ba19b3e321
Rpm always imported whole gpg keys including subkeys because rpm stores whole unparsed key data (key, subkeys, signatures of keys...) in gpg-pubkey... packages. These data are parsed during loading keys from db into rpm keyring in the beginning of rpm transaction but previously only main keys was extracted from these data and they were inserted into rpm keyring. Now also all subkeys are parsed and inserted into keyring. That means now you can have rpm package signed with arbitrary subkey and rpm is able to verify the sign of this package.
This change is in rpm-4.12.90 (a.k.a. rpm-4.13.0-alpha) which is in fedora rawhide.