[Bug 1207683] New: zypper: consider removing no longer need GPG keys from rpmdb
https://bugzilla.suse.com/show_bug.cgi?id=1207683 Bug ID: 1207683 Summary: zypper: consider removing no longer need GPG keys from rpmdb Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: ma@suse.com Reporter: matthias.gerstner@suse.com QA Contact: qa-bugs@suse.de CC: dheidler@suse.com, security-team@suse.de Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1206924 In bug 1206924 comment 7 we stumbled over the topic of public GPG signing keys not being removed by zypper when invoking `zypper rr` and a related signing key is no longer needed. The opi package manages third party repositories and hit the problem of properly cleaning up behind itself when repositories are deleted again. Having third party GPG keys lingering in the rpmdb can be security relevant. In opi this is now solved on foot for the time being. So the question is whether it is possible to handle this on Zypper level already to remove no longer needed keys from the rpmdb. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1207683 https://bugzilla.suse.com/show_bug.cgi?id=1207683#c1 --- Comment #1 from Marcus Meissner <meissner@suse.com> --- We can do these in the packages "owning" keys. e.g. i did in the suse-build-key package for SLE15: # obsoletes old SLE11 build key, as it is 1024 bit only Obsoletes: gpg-pubkey-b37b98a9 so we can handle this as a package topic, not a zypper topic . -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1207683 https://bugzilla.suse.com/show_bug.cgi?id=1207683#c2 --- Comment #2 from Marcus Meissner <meissner@suse.com> --- on second thought it might be a sensible idea to add this as option -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1207683 https://bugzilla.suse.com/show_bug.cgi?id=1207683#c3 --- Comment #3 from Dominik Heidler <dheidler@suse.com> --- My idea from the opi bugzilla ticket: On "zypper rr $repo" zypper could: 1. Get the gpgkey entry from the repo file 2. Query it (or better have it's content cached) 3. Compare the queried gpg key with the gpg keys in the rpm db to find the right one 4. Check if that key is still in use by other repos 5. Remove the key -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1207683 https://bugzilla.suse.com/show_bug.cgi?id=1207683#c4 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|ma@suse.com |zypp-maintainers@suse.de --- Comment #4 from Michael Andres <ma@suse.com> --- - The 1st source of a repos gpg key is the repomd.xml.key shipped with the repo (i.e. the key used to sign the metadata). - A signed repomd.xml file will be able to define additional keys to be downloaded and imported together with the repomd.xml.key. These should be additional keys used to sign packages shipped by the repos. But at the end it's under control of the repo maintainer what they add. - The gpgkey entry from the repo file is only evaluated in the case we need a key and it is not in the rpm db, not in /var/cache/zypp/pubkeys and not in /usr/lib/rpm/gnupg/keys. From zyppers POV 'rr' is not a good place, because the command does not do anything but removing the .repo file. Like 'ar' does not do anything but creating it. Both do no network access nor do they access any repo caches or the data therein. We also have several workflows where repos are removed and then new repos added. This would lead to losing keys which are later needed again. Similar during migration, where deleted old repos need to be restored after a failing migration. Not speaking of manually imported keys which would not be covered at all. Rather than pretending to care about gpg-pubkey security by trying to guess some key to remove upon 'rr', I'd vote for doing a dedicated 'zypper pubkey' command, which allows to list and manip all the keys in the rpmdb. Such a command would be able to do a thorough analysis of all keys in the db and their relation to known repositories - whithout risk of tampering existing workflows. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1207683 https://bugzilla.suse.com/show_bug.cgi?id=1207683#c5 --- Comment #5 from Dominik Heidler <dheidler@suse.com> --- In the meantime my hackweek project can fulfill at least parts of the task: https://hackweek.opensuse.org/projects/create-tool-for-managing-rpm-package-... -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com