On Sun, Feb 18, 2024 at 12:32:45PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Feb 16, 2024 at 09:37:25AM -0800, Kevin Fenzi wrote:
> > On Fri, Feb 16, 2024 at 11:12:07AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > > In my earlier message I quoted this case:
> > > 
> > > > [1] From 
> > > > https://github.com/systemd/systemd/actions/runs/7919159325/job/21619276641?pr=31338:
> > > >
> > > > Running transaction
> > > > Importing PGP key 0xA15B79CC:
> > > >  Userid     : "Fedora (40) <fedora-40-prim...@fedoraproject.org>"
> > > >  Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC
> > > >  From       : 
> > > > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary
> > > > The key was successfully imported.
> > > >
> > > > Transaction failed: Signature verification failed.
> > > > PGP check for package "filesystem-3.18-8.fc40.x86_64"
> > > > (/var/cache/libdnf5/fedora-306b6523e9c8dc02/packages/filesystem-3.18-8.fc40.x86_64.rpm)
> > > >  from
> > > > repo "fedora" has failed: Import of the key didn't help, wrong key?
> > > 
> > > /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary
> > > points to RPM-GPG-KEY-fedora-40-primary.
> > > So everythould be fine, no? filesystem-3.18-8.fc40.x86_64 is clearly an 
> > > F40
> > > package, so it should be signed with the RPM-GPG-KEY-fedora-40-primary 
> > > key.
> > 
> > Not really no. 
> > 
> > When we branch, the branched release gets all the already signed by
> > fedora-40 key packages. Rawhide is completely re-signed with the new
> > fedora-41 key. The dist tag of packages has nothing to do with it. 
> > 
> > So, day X, rawhide is all signed by fedora-40 key. 
> > Day X+1 we branch and get a new rawhide compose and all rawhide is
> > signed by the fedora-41 key.
> 
> Oh, OK. So it was a misunderstanding on my side. I thought that since e.g. F41
> has a bunch of packages taken from F40 and F39 and earlier, they will be 
> signed
> by those respective keys. But we resign them, so they are not. (To make this
> more confusing, on upgraded systems if the package version didn't change,
> and it doesn't if the package isn't rebuilt, we have the old package signed
> by the old key, while an "identical" package on a newer install will be signed
> by a newer key. But that's all OK, once you know about the resigning.)
> 
> > > 2. How does this even work later on? Wouldn't F40 installations refuse
> > >    packages signed with the F41 key?
> > 
> > refuse where? dnf/dnf5 use the line in fedora-rawhide.repo that lists
> > Both keys.
> 
> I meant that F_40_ installations don't allow the F41 key. (F41/rawhide 
> installations
> allow both, that is fine.)  But now I understand that F40 will get packages
> signed by the F40 key, and F41/rawhide will get resigned packages. So all is 
> OK.
> 
> > > 3. If F42 key has already been generated, why isn't it distributed in
> > >    distribution-gpg-keys already, to make it well known and make the
> > >    transition easier in the future?
> > 
> > It should have been. I am not sure where the process failed. 
> > 
> > I did generate the fedora-42 key.
> 
> Right. The key is there, and even distribution-gpg-keys package has in on F39.

One correction:
distribution-gpg-keys has 
/usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-41-primary
and fedora-gpg-keys has /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-41-x86_64
(a symlink to RPM-GPG-KEY-fedora-41-primary), which are identical.

tl;dr: the F41 key is available in F39.

> So I think the whole issue can be solved by letting tools use
> two keys for rawhide. The patch for mkosi was merged [1].
> Should we do something similar for mock?
> 
> [1] 
> https://github.com/systemd/mkosi/commit/f221562c945a48db9384f8521f67b9b02cd71ac1
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to