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. 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
