miabbott reported a new issue against the project: `atomic-wg` that you are following: `` 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](https://github.com/ostreedev/ostree/issues/773#issuecomment-380773355) is to use the `ostree remote gpg-import` functionality to make the recent keys available to the remote.
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 ``` ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/461
jlebon added a new comment to an issue you are following: `` 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`. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/461
dustymabe added a new comment to an issue you are following: `` I think I still prefer:
- delivering the ostree remote config via rpm (like we do for yum repos), which allows us to change the content over time - 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
``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/461
miabbott added a new comment to an issue you are following: ``
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.
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/461
jlebon added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/461
dustymabe added a new comment to an issue you are following: `` but if gpgkeypath were a list of 2 keys (one for f27 and one for f28) then it would work fine. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/461
atomic@lists.fedoraproject.org
-
Dusty Mabe -
Jonathan Lebon
-
Micah Abbott