|Summary:||RFE: better handling of signing subkeys|
|Product:||[Fedora] Fedora||Reporter:||John Guthrie <mathguthrie>|
|Component:||rpm||Assignee:||Packaging Maintenance Team <packaging-team-maint>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Version:||rawhide||CC:||herrold, lkardos, quanah, tmraz, tonster|
|Target Milestone:||---||Keywords:||FutureFeature, Reopened|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|:||1638955 (view as bug list)||Environment:|
|Last Closed:||2015-08-28 11:46:39 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description John Guthrie 2007-02-07 06:51:36 UTC
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 interesting. Version-Release number of selected component (if applicable): 4.4.2-32 How reproducible: Every time. 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. Actual results: 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. Expected results: I would hope to see some kind of linkage between the parent key and the subkey. Additional info:
Comment 1 Jeff Johnson 2007-02-07 12:40:16 UTC
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.
Comment 2 Red Hat Bugzilla 2007-08-21 05:31:38 UTC
User firstname.lastname@example.org's account has been closed
Comment 3 Panu Matilainen 2007-08-22 06:30:42 UTC
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 4 Bug Zapper 2008-04-04 06:07:38 UTC
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. http://fedoraproject.org/wiki/LifeCycle/EOL 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 the change. 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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
Comment 5 Bug Zapper 2008-05-06 19:10:48 UTC
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.
Comment 6 Tomas Mraz 2015-07-10 08:27:58 UTC
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.
Comment 7 Ľuboš Kardoš 2015-07-23 09:20:34 UTC
Fixed upstream as a173d781a631a92524ce5be364c679ba19b3e321
Comment 8 Ľuboš Kardoš 2015-08-28 11:46:39 UTC
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.