Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Tommy Nguyen kirjoitti 17.9.2022 klo 10.44: On Sat, 2022-09-17 at 10:40 +0300, Otto Liljalaakso wrote: Leigh Scott kirjoitti 17.9.2022 klo 10.27: On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote: I found this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1 Again, not a very friendly response. The short is that they are currently in freeze so no action can be taken ATM. I did not write that, Tommy did. Please be careful with attribution, especially with clips that can be interpreted as negative. Other than that, great to see somebody from RPM Fusion involved in this It was almost certainly a typo when editing the replies. I doubt they intended to misquote. No malice assumed, and no harm done! I just wanted to point out the accident. ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Sat, 2022-09-17 at 10:40 +0300, Otto Liljalaakso wrote: > Leigh Scott kirjoitti 17.9.2022 klo 10.27: > > > On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote: > > > > > > I found this: > > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1 > > > > > > Again, not a very friendly response. The short is that they are > > > currently in freeze so no action can be taken ATM. > > I did not write that, Tommy did. Please be careful with attribution, > especially with clips that can be interpreted as negative. > > Other than that, great to see somebody from RPM Fusion involved in > this It was almost certainly a typo when editing the replies. I doubt they intended to misquote. Anyway, I did successfully update to the F37 beta with the crypto policies at default. I have not tested re-enabling it because one package I depend on still has sha1 code. ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Leigh Scott kirjoitti 17.9.2022 klo 10.27: On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote: I found this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1 Again, not a very friendly response. The short is that they are currently in freeze so no action can be taken ATM. I did not write that, Tommy did. Please be careful with attribution, especially with clips that can be interpreted as negative. Other than that, great to see somebody from RPM Fusion involved in this thread! ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
> On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote: > > I found this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1 > > Again, not a very friendly response. The short is that they are > currently in freeze so no action can be taken ATM. The rpmfusion f36 release repo isn't fixable as it is locked after f36 release. ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Tommy Nguyen kirjoitti 16.9.2022 klo 6.51: On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote: RPM Fusion Fedora 37 repository seems to be all SHA256 already. Thanks for doing the research. I plan on upgrading to the F37 beta soon. Have you done so already and what are your results? I have the same plan, but currently I cannot fully upgrade my Fedora 36 [1], so Fedora 37 Beta has to wait until that is resolved. However, this issue is easily reproducible in a Toolbox container. There, I see the reported problems for Fedora 36, but not for Rawhide. I have not tried Fedora 37, and do not plan to do so, because based on the information that has been gathered, I am convinced that the problem will be gone soon enough. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2124059 ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote: > Tommy Nguyen kirjoitti 15.9.2022 klo 17.40: > > > > > On Sep 15, 2022, at 10:26 AM, Otto Liljalaakso > > > wrote: > > > > > > So maybe it is just that, for Fedora 36 at least, RPM Fusion it > > > not compatible with the new crypto settings. > > > > > > I also see the following key ids in the errors I reported in the > > > original message. How can I check what those are, more RPM Fusion > > > keys? > > > > > > 6dc1be18 > > > d651ff2e > > > 94843c65 > > > > A while back I reported the issue and someone said that it has to > > do with their sub key. Not much that can be done except report it > > to rpmfusion (unless it’s already been done). > > I tried searching bugzilla.rpmfusion.org, but could not find anything > that looks relevant. I also wanted to search the mailing lists, but > apparently, at the moment, RPM Fusion is not publicly archiving its > mailing lists [1]. > > [1]: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4759#c5 > > Anyhow, I did some more research. It looks like RPM Fusion has > switched > signing packages with SHA256, but in their repository for Fedora 36, > there are older builds around that still use SHA1. At least the SHA1 > ones that I found are older than the SHA256 ones. > > RPM Fusion Fedora 37 repository seems to be all SHA256 already. > > So, it looks like there is nothing to fix here, except maybe adding > some > note to testing instructions. > > > In order to identify the rest of the keys, try: > > > > rpm -qa gpg-pubkey\* > > rpm -qi gpg-pubkey-keyid-goeshere > > Thanks, they are all from RPM Fusion. > ___ > 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 I found this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1 Again, not a very friendly response. The short is that they are currently in freeze so no action can be taken ATM. ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote: > RPM Fusion Fedora 37 repository seems to be all SHA256 already. Thanks for doing the research. I plan on upgrading to the F37 beta soon. Have you done so already and what are your results? ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Tommy Nguyen kirjoitti 15.9.2022 klo 17.40: On Sep 15, 2022, at 10:26 AM, Otto Liljalaakso wrote: So maybe it is just that, for Fedora 36 at least, RPM Fusion it not compatible with the new crypto settings. I also see the following key ids in the errors I reported in the original message. How can I check what those are, more RPM Fusion keys? 6dc1be18 d651ff2e 94843c65 A while back I reported the issue and someone said that it has to do with their sub key. Not much that can be done except report it to rpmfusion (unless it’s already been done). I tried searching bugzilla.rpmfusion.org, but could not find anything that looks relevant. I also wanted to search the mailing lists, but apparently, at the moment, RPM Fusion is not publicly archiving its mailing lists [1]. [1]: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4759#c5 Anyhow, I did some more research. It looks like RPM Fusion has switched signing packages with SHA256, but in their repository for Fedora 36, there are older builds around that still use SHA1. At least the SHA1 ones that I found are older than the SHA256 ones. RPM Fusion Fedora 37 repository seems to be all SHA256 already. So, it looks like there is nothing to fix here, except maybe adding some note to testing instructions. In order to identify the rest of the keys, try: rpm -qa gpg-pubkey\* rpm -qi gpg-pubkey-keyid-goeshere Thanks, they are all from RPM Fusion. ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
> On Sep 15, 2022, at 10:26 AM, Otto Liljalaakso > wrote: > > Tommy Nguyen kirjoitti 15.9.2022 klo 16.28: >>> On Thu, 2022-09-15 at 16:18 +0300, Otto Liljalaakso wrote: >>> To test this, I did enable TEST-FEDORA39 on my system, first >>> installed >>> as Fedora 24, now running 36. For some rpm and dnf operations, I get >>> the >>> following kind of errors: >>> >>> error: rpmdbNextIterator: skipping h# 740 >>> Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD >>> Header SHA256 digest: OK >>> Header SHA1 digest: OK >>> >>> I first noticed this with 'dnf upgrade', simplified to 'dnf reinstall >>> glibc', perhaps the best reproduces is 'rpm -qa > /dev/null'. >>> >>> Regardless of these errors, all the commands work as expected. Still >>> I >>> wonder, is it expected that old installations will see, and keep >>> seeing, >>> these errors after distrusting SHA-1? >> That is the RPM Fusion signing key. > > Yes, I have RPM Fusion enabled. I also see that there are more problems with > RPM Fusion: > > $ sudo dnf install vlc > ... > Problem opening package faad2-libs-2.10.0-3.fc36.x86_64.rpm > Problem opening package libdca-0.0.7-5.fc36.x86_64.rpm > Problem opening package live555-2022.02.07-1.fc36.x86_64.rpm > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: GPG check FAILED > > If I install vlc when the DEFAULT policy is in force, then put TEST-FEDORA39 > back, I cannot remove vlc any more: > > $ sudo dnf remove vlc > ... > Remove 96 Packages > Freed space: 377 M > Is this ok [y/N]: y > Running transaction check > error: rpmdbNextIterator: skipping h# 526 > Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD > Header SHA256 digest: OK > Header SHA1 digest: OK > Error: An rpm exception occurred: package not installed > > So maybe it is just that, for Fedora 36 at least, RPM Fusion it not > compatible with the new crypto settings. > > I also see the following key ids in the errors I reported in the original > message. How can I check what those are, more RPM Fusion keys? > > 6dc1be18 > d651ff2e > 94843c65 > ___ > 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 A while back I reported the issue and someone said that it has to do with their sub key. Not much that can be done except report it to rpmfusion (unless it’s already been done). In order to identify the rest of the keys, try: rpm -qa gpg-pubkey\* rpm -qi gpg-pubkey-keyid-goeshere For now either disable rpmfusion or set the crypto policy back to default. ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Tommy Nguyen kirjoitti 15.9.2022 klo 16.28: On Thu, 2022-09-15 at 16:18 +0300, Otto Liljalaakso wrote: To test this, I did enable TEST-FEDORA39 on my system, first installed as Fedora 24, now running 36. For some rpm and dnf operations, I get the following kind of errors: error: rpmdbNextIterator: skipping h# 740 Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD Header SHA256 digest: OK Header SHA1 digest: OK I first noticed this with 'dnf upgrade', simplified to 'dnf reinstall glibc', perhaps the best reproduces is 'rpm -qa > /dev/null'. Regardless of these errors, all the commands work as expected. Still I wonder, is it expected that old installations will see, and keep seeing, these errors after distrusting SHA-1? That is the RPM Fusion signing key. Yes, I have RPM Fusion enabled. I also see that there are more problems with RPM Fusion: $ sudo dnf install vlc ... Problem opening package faad2-libs-2.10.0-3.fc36.x86_64.rpm Problem opening package libdca-0.0.7-5.fc36.x86_64.rpm Problem opening package live555-2022.02.07-1.fc36.x86_64.rpm The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: GPG check FAILED If I install vlc when the DEFAULT policy is in force, then put TEST-FEDORA39 back, I cannot remove vlc any more: $ sudo dnf remove vlc ... Remove 96 Packages Freed space: 377 M Is this ok [y/N]: y Running transaction check error: rpmdbNextIterator: skipping h# 526 Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD Header SHA256 digest: OK Header SHA1 digest: OK Error: An rpm exception occurred: package not installed So maybe it is just that, for Fedora 36 at least, RPM Fusion it not compatible with the new crypto settings. I also see the following key ids in the errors I reported in the original message. How can I check what those are, more RPM Fusion keys? 6dc1be18 d651ff2e 94843c65 ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Thu, 2022-09-15 at 16:18 +0300, Otto Liljalaakso wrote: > To test this, I did enable TEST-FEDORA39 on my system, first > installed > as Fedora 24, now running 36. For some rpm and dnf operations, I get > the > following kind of errors: > > error: rpmdbNextIterator: skipping h# 740 > Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD > Header SHA256 digest: OK > Header SHA1 digest: OK > > I first noticed this with 'dnf upgrade', simplified to 'dnf reinstall > glibc', perhaps the best reproduces is 'rpm -qa > /dev/null'. > > Regardless of these errors, all the commands work as expected. Still > I > wonder, is it expected that old installations will see, and keep > seeing, > these errors after distrusting SHA-1? That is the RPM Fusion signing key. ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Ben Cotton kirjoitti 29.8.2022 klo 21.30: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 == Summary == Cryptographic policies will be tightened in Fedora ''38''-39, SHA-1 signatures will no longer be trusted by default. Fedora ''38'' will do a "jump scare", introducing the change but then reverting it in time for Beta. Test your setup with TEST-FEDORA39 today and file bugs in advance so you won't get bit by Fedora ''38''-39. To test this, I did enable TEST-FEDORA39 on my system, first installed as Fedora 24, now running 36. For some rpm and dnf operations, I get the following kind of errors: error: rpmdbNextIterator: skipping h# 740 Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD Header SHA256 digest: OK Header SHA1 digest: OK I first noticed this with 'dnf upgrade', simplified to 'dnf reinstall glibc', perhaps the best reproduces is 'rpm -qa > /dev/null'. Regardless of these errors, all the commands work as expected. Still I wonder, is it expected that old installations will see, and keep seeing, these errors after distrusting SHA-1? ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On 9/15/22 00:59, Kevin Kofler via devel wrote: Alexander Sosedkin wrote: That's a reason why my initial thread [1] has been named "Landing a larger-than-release change (distrusting SHA-1 signatures)": flipping the switch is the easy part, unfortunately. IMHO, a change that breaks so many things that you expect it to take more than 6 months to fix the breakage across the entire distribution is just unacceptable to begin with and should just not be done altogether, ever. At least not as long as it is expected to break so many things. Maybe in 10 or 20 years, you can even consider dropping SHA-1. The real world does not move as fast as the progress in cryptanalysis, you just have to accept that. Maybe it can work to distrust SHA-1 in some particularly security-critical contexts, e.g., make RPM distrust SHA-1 signatures for packages installed on the system (but not, e.g., in a mock chroot targeting some older RHEL!) by default, with an easy way to change that default (I am thinking of something like "echo 'trust_sha1_sigs 1' >/etc/rpm/macros.trustsha1"). But disallowing SHA-1 systemwide, with no regards to what the actual application is and what level of security it provides, is just insane, and will just lead to applications bundling their own SHA-1 implementation and possibly even their own PGP signature implementation to work around your deliberate breakage. Please read the actual proposal: this is about SHA-1 *signatures*. Not the hash itself. - Panu - ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Alexander Sosedkin wrote: > That's a reason why my initial thread [1] has been named > "Landing a larger-than-release change (distrusting SHA-1 signatures)": > flipping the switch is the easy part, unfortunately. IMHO, a change that breaks so many things that you expect it to take more than 6 months to fix the breakage across the entire distribution is just unacceptable to begin with and should just not be done altogether, ever. At least not as long as it is expected to break so many things. Maybe in 10 or 20 years, you can even consider dropping SHA-1. The real world does not move as fast as the progress in cryptanalysis, you just have to accept that. Maybe it can work to distrust SHA-1 in some particularly security-critical contexts, e.g., make RPM distrust SHA-1 signatures for packages installed on the system (but not, e.g., in a mock chroot targeting some older RHEL!) by default, with an easy way to change that default (I am thinking of something like "echo 'trust_sha1_sigs 1' >/etc/rpm/macros.trustsha1"). But disallowing SHA-1 systemwide, with no regards to what the actual application is and what level of security it provides, is just insane, and will just lead to applications bundling their own SHA-1 implementation and possibly even their own PGP signature implementation to work around your deliberate breakage. Kevin Kofler ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Wed, 2022-09-07 at 17:47 +, Maxwell G via devel wrote: > I think this is a bad idea. It's quite hostile to packagers. It will > break rawhide for months and make it very difficult to stabilize the > distro before the beta freeze or do any type of rebuild. It very well > may > affect other Changes. It will still cause untold problems even if you > revert it before the beta freeze. Please test this in COPR (as Miro > already said) or somewhere else instead of destabilizing the distro. > You > can analyze the COPR failures and report bugs just like the Python > SIG > does for new Python major versions. I have no stake in this but participated in the test day (I don't think anyone else did?) so I would like to give my 2 cents. First for the results. I only noticed two issues: RPM Fusion signing keys and libimobiledevice no longer pairing with phones. Both are "trivial" issues. The former is a quick fix, the latter the maintainer has been notified and has expressed interest in modifying the codebase to switching from SHA1 to something like SHA256. COPR also had issues but again, that was a quick fix. Secondly, I agree that it is hostile to packagers. I filed an issue and the packager was kind of blindsided by the proposal. I have no issue with the term jump scare because I think such a radical change does need to "scare" people otherwise complacency leads to people being slow to migrate (see Python 2 -> 3 and people forking 2, despite having over a decade to switch to 3 for example). So maybe such a big change should have more communication and emphasis. Now while I only found a few issues doing testing, I have no doubt other people will have more exotic setups like specific hardware, VPNs, third party repos, etc. where things will break. Although I should say that I did testing across a wide variety of software including Tor, git, SSH and so on so assuming a relatively vanilla setup, most people should be fine. Anyway I agree on paper about testing it on COPR to avoid affecting the main distro, but I think that something like this can only encourage people to fix (or drop) software if there is intentional breakage. ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Wed, Sep 14, 2022 at 6:40 PM Kevin Fenzi wrote: > > On Wed, Sep 14, 2022 at 11:45:16AM +0200, Alexander Sosedkin wrote: > > On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > > > > > How about this: > > > > > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. > > > > I'm open for proposals on the wording. =) > > Well, I guess it depends on if you still want to implement it and then > plan to roll it back or not... see below. > > > > > Rework the change so it's basically planning on making this change in > > > f38. > > > > That makes it closer than currently, > > defeating the purpose of letting people prepare. > > True, it possibly makes the timeline shorter. > If thats a concern, perhaps you would consider just targeting f39 and > for f38 just doing test days and reminders asking developers to test > instead of changing it and then changing it back? > > > > > Before f38 beta freeze, change owners/fesco looks at the state of things > > > and decides if it can remain on in f38 and if not, it gets reverted and > > > moved to f39. > > > > Not sure how it's better than reverting in branched f38 but not rawhide, > > unless the goal is to hasten the change. > > It's better because it seems more direct and honest to me. > It means you are landing a change and trying to get it done, not landing > it to break people and then at the last minute after people rush to fix > things, removing it again. I also suspect there will be some feet > dragging due to this: "Oh, it's broken now, but they are going to revert > it anyhow, so I won't do anything". If this helps, from the perspective of tracking rawhide, we flip the switch and don't revert it. So the "they'll revert it" argument doesn't work at least for rawhide. > > > In the run up to f38 beta we could: > > > > > > * run a series of test days. perhaps one before you enable it in > > > rawhide, one a month or two later and one right before f38 beta > > > freeze? > > > > I'm for more test days. > > There was one held already and I'm open for holding more in the future. > > Plus I should attempt some side-tag mass-rebuild or equivalent, > > but I, unfortunately, won't get to it until October at the earliest. > > Sure, understand time is low for everyone. ;( > > > > * see if openqa might have some way to set TEST-FEDORA39 and re-run > > > tests on a compose or updates? This might be a good thing to try and do > > > before landing it in rawhide. > > > > Sounds great if that's a possibility, but I don't know how to approach it. > > Perhaps Adam can chime in here... > > > > * setup a tracking bug to track the issues, so we can make a more > > > informed decision before f38 beta. > > > > > > Thoughts? > > > > If the core of your proposal is > > * make it happen in f38 and revert and push back to f39 only if necessary > > as opposed to > > * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, > > but not f38 branched (the current proposal) > > then I can't say I understand what you are trying to achieve with > > that. > > I don't care for "Here's a change, adjust to it please! Hurry!" Oh, just > kidding, it will not take effect until next cycle. That just seems to be > dishonest to our users. > > > IMO it makes the switch less certain, more frantic and more abrupt, > > while I was trying to smoothen it out in time as far as possible. > > I don't think it's possible to cleanly spread out a change like this > over more than 1 long fedora cycle. That's a reason why my initial thread [1] has been named "Landing a larger-than-release change (distrusting SHA-1 signatures)": flipping the switch is the easy part, unfortunately. > > So +1 on all the accompanying activities possible, > > -1 on expediting the switch. > > ok. I'm not sure where the rest of fesco is on this, but I guess we will > see. :) > > Thanks for listening. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/ ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Wed, Sep 14, 2022 at 11:45:16AM +0200, Alexander Sosedkin wrote: > On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > > > How about this: > > > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. > > I'm open for proposals on the wording. =) Well, I guess it depends on if you still want to implement it and then plan to roll it back or not... see below. > > > Rework the change so it's basically planning on making this change in > > f38. > > That makes it closer than currently, > defeating the purpose of letting people prepare. True, it possibly makes the timeline shorter. If thats a concern, perhaps you would consider just targeting f39 and for f38 just doing test days and reminders asking developers to test instead of changing it and then changing it back? > > > Before f38 beta freeze, change owners/fesco looks at the state of things > > and decides if it can remain on in f38 and if not, it gets reverted and > > moved to f39. > > Not sure how it's better than reverting in branched f38 but not rawhide, > unless the goal is to hasten the change. It's better because it seems more direct and honest to me. It means you are landing a change and trying to get it done, not landing it to break people and then at the last minute after people rush to fix things, removing it again. I also suspect there will be some feet dragging due to this: "Oh, it's broken now, but they are going to revert it anyhow, so I won't do anything". > > > In the run up to f38 beta we could: > > > > * run a series of test days. perhaps one before you enable it in > > rawhide, one a month or two later and one right before f38 beta > > freeze? > > I'm for more test days. > There was one held already and I'm open for holding more in the future. > Plus I should attempt some side-tag mass-rebuild or equivalent, > but I, unfortunately, won't get to it until October at the earliest. Sure, understand time is low for everyone. ;( > > * see if openqa might have some way to set TEST-FEDORA39 and re-run > > tests on a compose or updates? This might be a good thing to try and do > > before landing it in rawhide. > > Sounds great if that's a possibility, but I don't know how to approach it. Perhaps Adam can chime in here... > > * setup a tracking bug to track the issues, so we can make a more > > informed decision before f38 beta. > > > > Thoughts? > > If the core of your proposal is > * make it happen in f38 and revert and push back to f39 only if necessary > as opposed to > * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, > but not f38 branched (the current proposal) > then I can't say I understand what you are trying to achieve with > that. I don't care for "Here's a change, adjust to it please! Hurry!" Oh, just kidding, it will not take effect until next cycle. That just seems to be dishonest to our users. > IMO it makes the switch less certain, more frantic and more abrupt, > while I was trying to smoothen it out in time as far as possible. I don't think it's possible to cleanly spread out a change like this over more than 1 long fedora cycle. > > So +1 on all the accompanying activities possible, > -1 on expediting the switch. ok. I'm not sure where the rest of fesco is on this, but I guess we will see. :) Thanks for listening. 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > How about this: > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. I'm open for proposals on the wording. =) > Rework the change so it's basically planning on making this change in > f38. That makes it closer than currently, defeating the purpose of letting people prepare. > Before f38 beta freeze, change owners/fesco looks at the state of things > and decides if it can remain on in f38 and if not, it gets reverted and > moved to f39. Not sure how it's better than reverting in branched f38 but not rawhide, unless the goal is to hasten the change. > In the run up to f38 beta we could: > > * run a series of test days. perhaps one before you enable it in > rawhide, one a month or two later and one right before f38 beta > freeze? I'm for more test days. There was one held already and I'm open for holding more in the future. Plus I should attempt some side-tag mass-rebuild or equivalent, but I, unfortunately, won't get to it until October at the earliest. > * see if openqa might have some way to set TEST-FEDORA39 and re-run > tests on a compose or updates? This might be a good thing to try and do > before landing it in rawhide. Sounds great if that's a possibility, but I don't know how to approach it. > * setup a tracking bug to track the issues, so we can make a more > informed decision before f38 beta. > > Thoughts? If the core of your proposal is * make it happen in f38 and revert and push back to f39 only if necessary as opposed to * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, but not f38 branched (the current proposal) then I can't say I understand what you are trying to achieve with that. IMO it makes the switch less certain, more frantic and more abrupt, while I was trying to smoothen it out in time as far as possible. So +1 on all the accompanying activities possible, -1 on expediting the switch. ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Tue, Sep 13, 2022 at 1:35 PM Kevin Fenzi wrote: > > * setup a tracking bug to track the issues, so we can make a more > informed decision before f38 beta. This should be the tracker in the Changes Tracking component. Normally those are created after a proposal is approved by FESCo, but I can pre-create it if necessary. I've done that for some Python changes, e.g. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
How about this: Drop the term 'jump scare' entirely. IMHO it just sounds bad. Rework the change so it's basically planning on making this change in f38. Before f38 beta freeze, change owners/fesco looks at the state of things and decides if it can remain on in f38 and if not, it gets reverted and moved to f39. In the run up to f38 beta we could: * run a series of test days. perhaps one before you enable it in rawhide, one a month or two later and one right before f38 beta freeze? * see if openqa might have some way to set TEST-FEDORA39 and re-run tests on a compose or updates? This might be a good thing to try and do before landing it in rawhide. * setup a tracking bug to track the issues, so we can make a more informed decision before f38 beta. Thoughts? 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Aug 29, 2022 1:32:21 PM Ben Cotton : https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 == Summary == Cryptographic policies will be tightened in Fedora ''38''-39, SHA-1 signatures will no longer be trusted by default. Fedora ''38'' will do a "jump scare", introducing the change but then reverting it in time for Beta. Test your setup with TEST-FEDORA39 today and file bugs in advance so you won't get bit by Fedora ''38''-39. I think this is a bad idea. It's quite hostile to packagers. It will break rawhide for months and make it very difficult to stabilize the distro before the beta freeze or do any type of rebuild. It very well may affect other Changes. It will still cause untold problems even if you revert it before the beta freeze. Please test this in COPR (as Miro already said) or somewhere else instead of destabilizing the distro. You can analyze the COPR failures and report bugs just like the Python SIG does for new Python major versions. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Mon, Aug 29, 2022 at 02:30:44PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 > > == Summary == > > Cryptographic policies will be tightened in Fedora ''38''-39, > SHA-1 signatures will no longer be trusted by default. > Fedora ''38'' will do a "jump scare", introducing the change but then > reverting it in time for Beta. > Test your setup with TEST-FEDORA39 today and file bugs in advance so > you won't get bit by Fedora ''38''-39. This breaks a bunch of V2V use cases where we want to examine old guests which have RPM databases using SHA1. Also we want to ssh to remote machines running RHEL 5-era sshd. > The flagship change this time will be distrusting SHA-1 signatures > on the cryptographic library level, affecting more than just TLS. > > OpenSSL will start blocking signature creation and verification by default, > with the fallout anticipated to be wide enough > for us to roll out the change across multiple cycles > with multiple forewarnings > to give developers and maintainers ample time to react: The openssl change was a bad idea in RHEL 9, and it's going to be a bad idea in Fedora too. 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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Mon, Aug 29, 2022 at 10:48 PM Miro Hrončok wrote:
>
> On 29. 08. 22 20:30, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2
> >
> > == Summary ==
> >
> > Cryptographic policies will be tightened in Fedora ''38''-39,
> > SHA-1 signatures will no longer be trusted by default.
> > Fedora ''38'' will do a "jump scare", introducing the change but then
> > reverting it in time for Beta.
> > Test your setup with TEST-FEDORA39 today and file bugs in advance so
> > you won't get bit by Fedora ''38''-39.
>
> It is my opinion that breaking things on purpose ("jump scaring") is not a
> friendly way of making things happen. Sure, when other options are exhausted,
> let's consider it as an extreme option, but maybe we can figure something else
> out first.
>
> Have you for example considered:
>
> - changing the default in Copr and rebuilding the distro, seeing what
> breaks?
That's in my plans, but it won't catch user-important scenarios
not covered by tests of other packages.
> - changing the default in ELN only first?
That's already done.
___
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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On 29. 08. 22 20:30, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2
== Summary ==
Cryptographic policies will be tightened in Fedora ''38''-39,
SHA-1 signatures will no longer be trusted by default.
Fedora ''38'' will do a "jump scare", introducing the change but then
reverting it in time for Beta.
Test your setup with TEST-FEDORA39 today and file bugs in advance so
you won't get bit by Fedora ''38''-39.
It is my opinion that breaking things on purpose ("jump scaring") is not a
friendly way of making things happen. Sure, when other options are exhausted,
let's consider it as an extreme option, but maybe we can figure something else
out first.
Have you for example considered:
- changing the default in Copr and rebuilding the distro, seeing what breaks?
- changing the default in ELN only first?
--
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: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Mon, Aug 29, 2022 at 2:30 PM Ben Cotton wrote: > > * Release engineering: Not sure if mass-rebuild is required if we > land the change right after f38 branch-off. Maybe a "preview" > mass-rebuild can be done with a special build in the F37 timeframe to > cut down on F38 FTBFS. Please file an issue with releng: https://pagure.io/releng/new_issue This is required by FESCo for all System-Wide Change proposals anyway. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
