A common problem that users hit when a new major release lands is having to manually configure a new remote or modify an existing remote to use the new major release GPG key. This is exacerbated now that we have a unified repo for all of our refs.
A solution pointed out in the upstream ostree issue is to use the ostree remote gpg-import functionality to make the recent keys available to the remote.
ostree remote gpg-import
Would it be possible to change how we produce the cloud-images/AMIs/ISOs so that the pre-configured remote uses this method to make all the recent keys available?
# ostree remote add fedora-atomic https://dl.fedoraproject.org/atomic/repo/ # cat /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-{27,28,29}-primary |ostree remote gpg-import --stdin fedora-atomic
Hmm, but then we'd be allowing e.g. F28 content to be signed by the F27 key, right? That seems like the opposite effect of what we want from rotating keys.
OTOH, I appreciate the UX annoyance here. Maybe we should just teach gpgkeypath to support $releasever and $basearch, like dnf? Then rpm-ostree rebase should Just Work assuming the newer keys are already part of the installed fedora-gpg-keys.
gpgkeypath
$releasever
$basearch
rpm-ostree rebase
fedora-gpg-keys
I think I still prefer:
Seems unlike that would happen, but I understand the reasoning.
having gpgkeyfile being a list with two keys in it (this release and next release), which enables you to rebase from one release to the next
This seems like it would enable the same problem that @jlebon called out if we were to import all the keys into the remote config.
delivering the ostree remote config via rpm (like we do for yum repos), which allows us to change the content over time
But with a unified repo, that remote config wouldn't really change...unless you are just changing the valid keys.
Even if the remote config is part of an RPM and you e.g. update the baked gpgkeypath= value, rpm-ostree would still be using the current remote config during the rebase operation.
gpgkeypath=
but if gpgkeypath were a list of 2 keys (one for f27 and one for f28) then it would work fine.
Login to comment on this ticket.