kparal added a new comment to an issue you are following:
``
The last few times we have branched off the new release, then
switched rawhide compose to use the new rawhide key and made sure everything was signed
with that key.
That means that Rawhide users were not able to update the system without using
`--nogpgcheck`, because the new packages were suddenly signed with a new key that they
didn't have on their system. Is that correct?
So we could:
Just sign one package with the new key at branch point: fedora-release. This would allow
them to update fedora-repos and import the new key.
Wait some time (a day? a week?)
switch everything over to the new key.
Alternatively, there could be instructions on the wiki how to download&import the new
key, which would work even outside of that ~1week timeslot. But none of these are easily
automatable, and that's ugly.
I might have found a solution :wink: DNF specifies that the `gpgkey=` variable in a
`.repo` file is a **list** (values are separated by commas or spaces). So you can
introduce the key for Rawhide+1 well in advance and give users plenty of time to receive
new `fedora-gpg-keys` and `fedora-repos`. Ideally, when you branch e.g. F31 and Rawhide
becomes F32, at the very same time you can update it to include the key for F33. That
means that if users update their Rawhide systems at least once per 6 months, they will
never be cut off from updates because of a new GPG key. Also, they can update the whole
system in one transaction, without thinking about "I need to update
fedora-release/repos/keys first".
The repo files would change from this:
```
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
```
to something like this:
```
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-$basearch
```
This can be applied just for Rawhide, or even for stable systems (because the two keys can
translate to the same file, there's no problem in it). The line loses some elegance,
but I think the advantages seem quite convincing.
During Branch event (e.g. F31), the existing F32 key would get copied/symlinked to the
Rawhide key:
```
ln -sf RPM-GPG-KEY-fedora-32-primary RPM-GPG-KEY-fedora-rawhide-primary
```
and a new `RPM-GPG-KEY-fedora-33-primary` key would get generated. The repo files would
get updated as shown above.
I'm pretty happy about this solution and haven't found any logical flaw. WDYT?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7445