Re: The semiannual "Transaction failed: Signature verification failed." exercise
On Tue, Feb 20, 2024 at 10:21:50AM -0800, Kevin Fenzi wrote: > On Sun, Feb 18, 2024 at 12:32:45PM +, Zbigniew Jędrzejewski-Szmek wrote: > > 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 > > I think that would help a good bit if we can. > > I do see logic there to use rawhide and rawhide-1, but I think it needs > rawhide+1 also (at least around branching time)? > > Can someone file a mock bug/pr? https://github.com/rpm-software-management/mock/issues/1338 Zbyszek -- ___ 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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
On Sun, Feb 18, 2024 at 12:32:45PM +, Zbigniew Jędrzejewski-Szmek wrote: > > 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.) Yeah... > 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 I think that would help a good bit if we can. I do see logic there to use rawhide and rawhide-1, but I think it needs rawhide+1 also (at least around branching time)? Can someone file a mock bug/pr? kevin signature.asc Description: PGP signature -- ___ 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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
On Sun, Feb 18, 2024 at 12:32:45PM +, 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 +, 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) " > > > > 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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
Dne 16. 02. 24 v 18:27 Kevin Fenzi napsal(a): On Fri, Feb 16, 2024 at 09:46:05AM +0100, Vít Ondruch wrote: Other solution could be if Rawhide lived in rawhide repos instead of f41. I'm not sure I follow... rawhide is in a rawhide repo? pub/fedora/linux/development/rawhide/ I stand corrected. Sorry. Not sure what I was checking. Vít Or did you mean to sign rawhide with a 'rawhide' key always that never changes? Thats an option, but then there's no regular key rotation... kevin -- ___ 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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ 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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
On Fri, Feb 16, 2024 at 09:37:25AM -0800, Kevin Fenzi wrote: > On Fri, Feb 16, 2024 at 11:12:07AM +, 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) " > > > 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@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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
On Fri, Feb 16, 2024 at 09:37:25AM -0800, Kevin Fenzi wrote: ...snip... > > It should have been. I am not sure where the process failed. > > I did generate the fedora-42 key. FYI, I was lacking coffee or something. it's there in the rawhide fedora-repos: https://src.fedoraproject.org/rpms/fedora-repos/c/d10a092adbcf0e0b2d7e4f05311255c805c878b5?branch=rawhide Needs updating in other places though. kevin signature.asc Description: PGP signature -- ___ 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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
On Fri, Feb 16, 2024 at 11:12:07AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Feb 15, 2024 at 06:03:59PM -0800, Kevin Fenzi wrote: > > That won't do it. We need mock to update it's config at exactly the same > > moment a successfull rawhide compose completes and mirrors to whatever > > mirror you are hitting. ;( > > > > We make keys a year ahead now. The f42 key is in fedora-release already. > > Oh, I didn't know that. I see that I have > /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary > /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-41-primary > on both my F39 and ~rawhide systems. yes. The 42 one should have been added too... not sure why it didn't land. ;( > This means that both keys are on the system, it's just a matter of > pointing dnf/other tools at them. Yes. Looking more I think we just need mock to list both the current one and the next one. fedora-repos already does this and I think dnf/dfn5 honor it. > But let's not talk about mock, let's talk about mkosi. ok > 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) " > > 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. > But it has > "Signature : RSA/SHA256, Fri 09 Feb 2024 01:30:23 PM CET, Key ID > d0622462e99d6ad1" > which is RPM-GPG-KEY-fedora-41-primary. > > This actually raises a bunch of questions: > 1. Why is the .f40 package signed with the F41 key? Because it's composed in rawhide. That same package composed in branched composes _is_ signed by the fedora-40 key. > 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. > 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. > and also: > > 4. https://fedoraproject.org/fedora.gpg contains keys for F35, F36, F37, F38, > F38, F40. >Why not F41 and F42? Yes, it should be added. > For mkosi specifically, I guess could try to import also the "next" key > when configuring rawhide installs, but I'd like to first understand why > the packages are signed with the F41 key. See above, happy to expand or try better to explain. kevin signature.asc Description: PGP signature -- ___ 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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
On Fri, Feb 16, 2024 at 09:46:05AM +0100, Vít Ondruch wrote: > > > Other solution could be if Rawhide lived in rawhide repos instead of f41. I'm not sure I follow... rawhide is in a rawhide repo? pub/fedora/linux/development/rawhide/ Or did you mean to sign rawhide with a 'rawhide' key always that never changes? Thats an option, but then there's no regular key rotation... kevin signature.asc Description: PGP signature -- ___ 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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
On Fri, Feb 16, 2024 at 11:12:07AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Feb 15, 2024 at 06:03:59PM -0800, Kevin Fenzi wrote: > > That won't do it. We need mock to update it's config at exactly the same > > moment a successfull rawhide compose completes and mirrors to whatever > > mirror you are hitting. ;( > > > > We make keys a year ahead now. The f42 key is in fedora-release already. > > Oh, I didn't know that. I see that I have > /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary > /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-41-primary > on both my F39 and ~rawhide systems. > > This means that both keys are on the system, it's just a matter of > pointing dnf/other tools at them. > > But let's not talk about mock, let's talk about mkosi. > > 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) " > > 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. > > But it has > "Signature : RSA/SHA256, Fri 09 Feb 2024 01:30:23 PM CET, Key ID > d0622462e99d6ad1" > which is RPM-GPG-KEY-fedora-41-primary. > > This actually raises a bunch of questions: > 1. Why is the .f40 package signed with the F41 key? > 2. How does this even work later on? Wouldn't F40 installations refuse >packages signed with the F41 key? > 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? > > and also: > > 4. https://fedoraproject.org/fedora.gpg contains keys for F35, F36, F37, F38, > F38, F40. >Why not F41 and F42? > > For mkosi specifically, I guess could try to import also the "next" key > when configuring rawhide installs, but I'd like to first understand why > the packages are signed with the F41 key. For now, I prepared the following PR: https://github.com/systemd/mkosi/pull/2398. It makes the build work by importing both RPM-GPG-KEY-fedora-40-primary and RPM-GPG-KEY-fedora-41-primary when the version string is "rawhide". As I wrote above, I don't understand some things here, so comments are very much welcome. Zbyszek -- ___ 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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
On Thu, Feb 15, 2024 at 06:03:59PM -0800, Kevin Fenzi wrote: > That won't do it. We need mock to update it's config at exactly the same > moment a successfull rawhide compose completes and mirrors to whatever > mirror you are hitting. ;( > > We make keys a year ahead now. The f42 key is in fedora-release already. Oh, I didn't know that. I see that I have /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-41-primary on both my F39 and ~rawhide systems. This means that both keys are on the system, it's just a matter of pointing dnf/other tools at them. But let's not talk about mock, let's talk about mkosi. 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) " > 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. But it has "Signature : RSA/SHA256, Fri 09 Feb 2024 01:30:23 PM CET, Key ID d0622462e99d6ad1" which is RPM-GPG-KEY-fedora-41-primary. This actually raises a bunch of questions: 1. Why is the .f40 package signed with the F41 key? 2. How does this even work later on? Wouldn't F40 installations refuse packages signed with the F41 key? 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? and also: 4. https://fedoraproject.org/fedora.gpg contains keys for F35, F36, F37, F38, F38, F40. Why not F41 and F42? For mkosi specifically, I guess could try to import also the "next" key when configuring rawhide installs, but I'd like to first understand why the packages are signed with the F41 key. Zbyszek -- ___ 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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
Dne 16. 02. 24 v 3:03 Kevin Fenzi napsal(a): On Thu, Feb 15, 2024 at 07:57:37PM +, Zbigniew Jędrzejewski-Szmek wrote: It's this time of the year again: ... Could we please do something so that this doesn't happen? Dunno, generate and distribute the keys earlier so that mock and https://fedoraproject.org/fedora.gpg get updated _before_ we need it? That won't do it. We need mock to update it's config at exactly the same moment a successfull rawhide compose completes and mirrors to whatever mirror you are hitting. ;( We make keys a year ahead now. The f42 key is in fedora-release already. I know this subject comes up approx. twice a year (or once once for F21 ;) ), e.g. [2]. I know this can be "fixed" with some manual steps, but I posit that this should never occur in the first place. I guess one possible solution would be for rpm to support multiple signatures and koji to support writing out those rpms and then we could sign new rawhide with both keys at least for a while. Other solution could be if Rawhide lived in rawhide repos instead of f41. Vít I guess I had that idea 7 years ago: https://github.com/rpm-software-management/rpm/issues/189 Or I suppose we could move to just one key for everything, but then it would have a larger effect if we ever had to revoke/reissue. At the very least, perhaps mock could try and identify this problem and note to upgrade mock-core-configs? Dunno. I agree it's not good, but it's not easy to solve either. kevin -- ___ 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 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ 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
Re: The semiannual "Transaction failed: Signature verification failed." exercise
On Thu, Feb 15, 2024 at 07:57:37PM +, Zbigniew Jędrzejewski-Szmek wrote: > It's this time of the year again: ... > > Could we please do something so that this doesn't happen? > Dunno, generate and distribute the keys earlier so that mock > and https://fedoraproject.org/fedora.gpg get updated _before_ > we need it? That won't do it. We need mock to update it's config at exactly the same moment a successfull rawhide compose completes and mirrors to whatever mirror you are hitting. ;( We make keys a year ahead now. The f42 key is in fedora-release already. > I know this subject comes up approx. twice a year (or once once for F21 ;) ), > e.g. [2]. I know this can be "fixed" with some manual steps, but I posit > that this should never occur in the first place. I guess one possible solution would be for rpm to support multiple signatures and koji to support writing out those rpms and then we could sign new rawhide with both keys at least for a while. I guess I had that idea 7 years ago: https://github.com/rpm-software-management/rpm/issues/189 Or I suppose we could move to just one key for everything, but then it would have a larger effect if we ever had to revoke/reissue. At the very least, perhaps mock could try and identify this problem and note to upgrade mock-core-configs? Dunno. I agree it's not good, but it's not easy to solve either. kevin signature.asc Description: PGP signature -- ___ 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
The semiannual "Transaction failed: Signature verification failed." exercise
It's this time of the year again: Running transaction Importing PGP key 0xA15B79CC: Userid : "Fedora (40) " Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC From : file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary The key was successfully imported. Importing PGP key 0xA15B79CC: Userid : "Fedora (40) " Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC From : file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary The key was successfully imported. Importing PGP key 0x18B8E74C: Userid : "Fedora (39) " Fingerprint: E8F23996F23218640CB44CBE75CF5AC418B8E74C From : file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary The key was successfully imported. Transaction failed: Signature verification failed. PGP check for package "curl-8.6.0-6.fc40.x86_64" (/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/curl-8.6.0-6.fc40.x86_64.rpm) from repo "fedora" has failed: Import of the key didn't help, wrong key? This message is from mock. It's one issue if mock fails, when you call it from the command line, but this failure also causes CI fails. And as everybody knows, flaky CI gets ignroed. I very much want people to use Fedora for their CI, and in particular rawhide, because it's great for testing with upstream software. But it looks silly if we get such a major "security failure" twice a year [1]. Could we please do something so that this doesn't happen? Dunno, generate and distribute the keys earlier so that mock and https://fedoraproject.org/fedora.gpg get updated _before_ we need it? I know this subject comes up approx. twice a year (or once once for F21 ;) ), e.g. [2]. I know this can be "fixed" with some manual steps, but I posit that this should never occur in the first place. Zbyszek [1] From https://github.com/systemd/systemd/actions/runs/7919159325/job/21619276641?pr=31338: Running transaction Importing PGP key 0xA15B79CC: Userid : "Fedora (40) " 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? Note that this is a test VM that was created specifically for this test run, so there's no question of stale data or anything like that. [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MFX2JDVANNEW7LWWIBBLYCN6DEPWHSXF/. -- ___ 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
