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-primary@xxxxxxxxxxxxxxxxx>" > > > > 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
