Re: Ruby FTBFS due to "SHA-1 jump scare"
On Thu, Aug 25, 2022 at 02:47:53PM +0100, Richard W.M. Jones wrote: > On Wed, Aug 24, 2022 at 12:31:29PM -0700, Adam Williamson wrote: > > so, from this we learn that the change would prevent PackageKit (and > > presumably other tools) from being able to read old Fedora signing > > keys; I'm not sure if that's a problem or not. > > YES - virt-v2v, libguestfs etc relies on being able to inspect old RPM > databases. This inspection takes place inside the libguestfs appliance VM though, right ? IOW can libguestfs ensure that its appliance filesystem sets up crypto-policies in LEGACY mode, regardless of what policy the host launching libguestfs is using. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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: Ruby FTBFS due to "SHA-1 jump scare"
On Wed, Aug 24, 2022 at 12:31:29PM -0700, Adam Williamson wrote: > so, from this we learn that the change would prevent PackageKit (and > presumably other tools) from being able to read old Fedora signing > keys; I'm not sure if that's a problem or not. YES - virt-v2v, libguestfs etc relies on being able to inspect old RPM databases. Please do not remove or cripple SHA-1 support. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit ___ 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: Ruby FTBFS due to "SHA-1 jump scare"
On 24. 08. 22 16:58, Alexander Sosedkin wrote: On Wed, Aug 24, 2022 at 4:33 PM Alexander Sosedkin wrote: On Wed, Aug 24, 2022 at 4:32 PM Fabio Valentini wrote: On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin wrote: On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch wrote: Alexander, Would you mind to comment on your intentions with: https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide which just landed in Fedora and broke Ruby test suite (even more then it was broken before): https://koschei.fedoraproject.org/package/ruby Although I know something like this was discussed and is already enabled in c9s, Yes, it was: [2], [3] I am not aware that the associated change [1] would be approved nor that you would send a warning that this is going to happen. Wait, right. It was just the Forewarning1 [4] that was approved, not the Forewarning2 one. Am I missing something? My intention was to break it right at the branch-off. What do I do now? Just keep it as it is? Revert, somehow initiate the approval early and unrevert once I have one? I don't think keeping rawhide/f38 intentionally broken, even if you're going to revert the brokenness in f38 after it branches off, is ever a good idea. Please revert the change and wait for the devel list and FESCo discussion of the topic before implementing it again. Ack, will do promptly. My bad. Reverted in crypto-policies-20220824-2.git2187e9c.fc38, sorry for the premature jump scare. Hey Alexander, In the meantime, have you considered doing this in Copr and rebuilding everything there, to have some statistics about impacted packages, before the change is discussed? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Ruby FTBFS due to "SHA-1 jump scare"
On Wed, 2022-08-24 at 16:58 +0200, Alexander Sosedkin wrote: > > Reverted in crypto-policies-20220824-2.git2187e9c.fc38, > sorry for the premature jump scare. openQA caught an interesting consequence of the change while it was live: it makes PackageKit start crashing. The journal shows these errors: Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: failed to parse public key for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-13-secondary Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: failed to parse public key for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-14-secondary Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null) Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: failed to parse public key for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-15-secondary Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null) Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: failed to parse public key for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-16-secondary Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null) Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: failed to parse public key for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-17-secondary Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null) Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: failed to parse public key for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-18-secondary Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null) Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: failed to parse public key for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-19-secondary Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null) Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: failed to parse public key for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-secondary Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null) Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: failed to parse public key for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-21-secondary Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null) Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: failed to parse public key for
Re: Ruby FTBFS due to "SHA-1 jump scare"
Dne 24. 08. 22 v 16:58 Alexander Sosedkin napsal(a): On Wed, Aug 24, 2022 at 4:33 PM Alexander Sosedkin wrote: On Wed, Aug 24, 2022 at 4:32 PM Fabio Valentini wrote: On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin wrote: On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch wrote: Alexander, Would you mind to comment on your intentions with: https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide which just landed in Fedora and broke Ruby test suite (even more then it was broken before): https://koschei.fedoraproject.org/package/ruby Although I know something like this was discussed and is already enabled in c9s, Yes, it was: [2], [3] I am not aware that the associated change [1] would be approved nor that you would send a warning that this is going to happen. Wait, right. It was just the Forewarning1 [4] that was approved, not the Forewarning2 one. Am I missing something? My intention was to break it right at the branch-off. What do I do now? Just keep it as it is? Revert, somehow initiate the approval early and unrevert once I have one? I don't think keeping rawhide/f38 intentionally broken, even if you're going to revert the brokenness in f38 after it branches off, is ever a good idea. Please revert the change and wait for the devel list and FESCo discussion of the topic before implementing it again. Ack, will do promptly. My bad. Reverted in crypto-policies-20220824-2.git2187e9c.fc38, Thx sorry for the premature jump scare. Also thx for reminding us that we should work with upstream to have it properly resolved, because it would already help with c9s ;) Vít OpenPGP_signature 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: Ruby FTBFS due to "SHA-1 jump scare"
On Wed, Aug 24, 2022 at 4:33 PM Alexander Sosedkin wrote: > > On Wed, Aug 24, 2022 at 4:32 PM Fabio Valentini wrote: > > > > On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin > > wrote: > > > > > > On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch wrote: > > > > > > > > Alexander, > > > > > > > > Would you mind to comment on your intentions with: > > > > > > > > https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide > > > > > > > > which just landed in Fedora and broke Ruby test suite (even more then it > > > > was broken before): > > > > > > > > https://koschei.fedoraproject.org/package/ruby > > > > > > > > Although I know something like this was discussed and is already enabled > > > > in c9s, > > > > > > Yes, it was: [2], [3] > > > > > > > I am not aware that the associated change [1] would be approved > > > > nor that you would send a warning that this is going to happen. > > > > > > Wait, right. It was just the Forewarning1 [4] that was approved, > > > not the Forewarning2 one. > > > > > > > Am I missing something? > > > > > > My intention was to break it right at the branch-off. > > > What do I do now? Just keep it as it is? > > > Revert, somehow initiate the approval early and unrevert once I have one? > > > > I don't think keeping rawhide/f38 intentionally broken, even if you're > > going to revert the brokenness in f38 after it branches off, is ever a > > good idea. > > Please revert the change and wait for the devel list and FESCo > > discussion of the topic before implementing it again. > > Ack, will do promptly. My bad. Reverted in crypto-policies-20220824-2.git2187e9c.fc38, sorry for the premature jump scare. ___ 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: Ruby FTBFS due to "SHA-1 jump scare"
On Wed, Aug 24, 2022 at 4:32 PM Fabio Valentini wrote: > > On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin > wrote: > > > > On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch wrote: > > > > > > Alexander, > > > > > > Would you mind to comment on your intentions with: > > > > > > https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide > > > > > > which just landed in Fedora and broke Ruby test suite (even more then it > > > was broken before): > > > > > > https://koschei.fedoraproject.org/package/ruby > > > > > > Although I know something like this was discussed and is already enabled > > > in c9s, > > > > Yes, it was: [2], [3] > > > > > I am not aware that the associated change [1] would be approved > > > nor that you would send a warning that this is going to happen. > > > > Wait, right. It was just the Forewarning1 [4] that was approved, > > not the Forewarning2 one. > > > > > Am I missing something? > > > > My intention was to break it right at the branch-off. > > What do I do now? Just keep it as it is? > > Revert, somehow initiate the approval early and unrevert once I have one? > > I don't think keeping rawhide/f38 intentionally broken, even if you're > going to revert the brokenness in f38 after it branches off, is ever a > good idea. > Please revert the change and wait for the devel list and FESCo > discussion of the topic before implementing it again. Ack, will do promptly. My bad. ___ 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: Ruby FTBFS due to "SHA-1 jump scare"
On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin wrote: > > On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch wrote: > > > > Alexander, > > > > Would you mind to comment on your intentions with: > > > > https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide > > > > which just landed in Fedora and broke Ruby test suite (even more then it > > was broken before): > > > > https://koschei.fedoraproject.org/package/ruby > > > > Although I know something like this was discussed and is already enabled > > in c9s, > > Yes, it was: [2], [3] > > > I am not aware that the associated change [1] would be approved > > nor that you would send a warning that this is going to happen. > > Wait, right. It was just the Forewarning1 [4] that was approved, > not the Forewarning2 one. > > > Am I missing something? > > My intention was to break it right at the branch-off. > What do I do now? Just keep it as it is? > Revert, somehow initiate the approval early and unrevert once I have one? I don't think keeping rawhide/f38 intentionally broken, even if you're going to revert the brokenness in f38 after it branches off, is ever a good idea. Please revert the change and wait for the devel list and FESCo discussion of the topic before implementing it again. Fabio ___ 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: Ruby FTBFS due to "SHA-1 jump scare"
On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch wrote: > > Alexander, > > Would you mind to comment on your intentions with: > > https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide > > which just landed in Fedora and broke Ruby test suite (even more then it > was broken before): > > https://koschei.fedoraproject.org/package/ruby > > Although I know something like this was discussed and is already enabled > in c9s, Yes, it was: [2], [3] > I am not aware that the associated change [1] would be approved > nor that you would send a warning that this is going to happen. Wait, right. It was just the Forewarning1 [4] that was approved, not the Forewarning2 one. > Am I missing something? My intention was to break it right at the branch-off. What do I do now? Just keep it as it is? Revert, somehow initiate the approval early and unrevert once I have one? > [1] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/ [3] https://lwn.net/Articles/887832/ [4] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1 ___ 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
Ruby FTBFS due to "SHA-1 jump scare"
Alexander, Would you mind to comment on your intentions with: https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide which just landed in Fedora and broke Ruby test suite (even more then it was broken before): https://koschei.fedoraproject.org/package/ruby Although I know something like this was discussed and is already enabled in c9s, I am not aware that the associated change [1] would be approved nor that you would send a warning that this is going to happen. Am I missing something? Vít [1] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 OpenPGP_signature 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
