Bug 1225666

Summary:	first time experience with zypper gpg import is suboptimal
Product:	[openSUSE] openSUSE Leap Micro	Reporter:	Lubos Kocman <lubos.kocman>
Component:	Transactional Update	Assignee:	E-mail List <zypp-maintainers>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	ma
Version:	6.0
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	screenshot fixed gpg import

Description Lubos Kocman 2024-05-30 14:05:53 UTC

On a fresh installed Leap Micro with openSUSE-repos

login do something like a zypper search and you'll be instantly prompted to accept new gpg key followed by error as the tranasaction lock /usr/lib/sysimage/rpm/rpm.lock can't be created

For a zypper ref/search that's a bit too much. I'm  perfectly fine with anything installation related being done in transactional-update shell etc ... 


We should do something about the current behavior.

Comment 1 Lubos Kocman 2024-05-30 14:07:09 UTC

Created attachment 875222 [details]
screenshot

Comment 2 Lubos Kocman 2024-05-30 14:10:14 UTC

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

Comment 3 Lubos Kocman 2024-05-30 14:10:43 UTC

Alternatively zypper ref/search would not create a transactinal lock or similar. But perhaps that's needed for a key import.

Comment 5 Michael Andres 2024-05-31 09:57:35 UTC

(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.

Comment 6 Lubos Kocman 2024-05-31 13:43:51 UTC

My bad the self-install has the gpg import step. It's just that suse-build key was propagated there which caused the missing openSUSE gpg keys import.

Comment 7 Lubos Kocman 2024-05-31 13:44:40 UTC

Created attachment 875250 [details]
fixed gpg import

Comment 8 Lubos Kocman 2024-05-31 13:45:23 UTC

Fixed by forking the base pattern https://build.opensuse.org/package/show/openSUSE:Leap:Micro:6.0/patterns-base?rev=1