https://bugzilla.suse.com/show_bug.cgi?id=1225666 https://bugzilla.suse.com/show_bug.cgi?id=1225666#c1 --- Comment #1 from Lubos Kocman --- Created attachment 875222 --> https://bugzilla.suse.com/attachment.cgi?id=875222&action=edit screenshot -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1225666 https://bugzilla.suse.com/show_bug.cgi?id=1225666#c2 Lubos Kocman changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(ma@suse.com) CC| |ma@suse.com --- Comment #2 from Lubos Kocman --- Any thoughts on this one? Any sort of READONLY_HACK=1 zypper ref -S in post doesn't make sense as this will not fix it for the self-install media (which just dd's image built in OBS into drive) and skipping completely the package installation with network on. I was thinkining of running something like rpm --import on invididual keys in something like config.sh while the image is created -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1225666 https://bugzilla.suse.com/show_bug.cgi?id=1225666#c5 Michael Andres changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ma@suse.com) | --- Comment #5 from Michael Andres --- (In reply to Lubos Kocman from comment #2)

I was thinkining of running something like rpm --import on invididual keys in something like config.sh while the image is created

This would indeed be an easy clean and secure solution. The issue with a temporarily accepted key is that the downloaded metadata set is accepted and any later action will accept this set on disk as well. No matter if root is RO or RW. The next check will be done when the next set is downloaded. This requires a refresh after the data on the server side have changed, or a forced refresh. My initial idea of auto-temporarily-accepting a key is kind of dangerous, because packages from this metadata set may get installed, if at install time no refresh is needed or performed (--no-refresh). So the user must confirm that a new metadata set is temp. accepted. It's of course possible to keep accepted keys in a RO environment in a cache directory and to load those keys in addition to the rpmdb's into the zypp trusted keyring. They would get synced backed to the rpmd once libzypp finds it RW. But this would de facto introduce a 2nd authority for trusted keys besides the rpmdb. We can not prevent that keys explicitly removed from the rpmdb by the admin may get re-introduced by syncing pending keys from the cachedir later. My preferred solution would be one where the trusted keys are stored in the rpmdb and nowhere else. So either importing them in advance or by granting rw access to 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=1225666 https://bugzilla.suse.com/show_bug.cgi?id=1225666#c7 --- Comment #7 from Lubos Kocman --- Created attachment 875250 --> https://bugzilla.suse.com/attachment.cgi?id=875250&action=edit fixed gpg import -- You are receiving this mail because: You are on the CC list for the bug.