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.