#461 use 'ostree remote gpg-import' when producing cloud-images/ISO
Opened 5 years ago by miabbott. Modified 5 years ago

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.

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.

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

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.

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.

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.

Metadata