On Tue, Mar 8, 2022 at 3:34 PM Demi Marie Obenour <demiobenour@xxxxxxxxx> wrote: > > On 3/8/22 15:23, Neal Gompa wrote: > > On Tue, Mar 8, 2022 at 3:11 PM Simo Sorce <simo@xxxxxxxxxx> wrote: > >> > >> On Tue, 2022-03-08 at 20:51 +0100, Zbigniew Jędrzejewski-Szmek wrote: > >>> On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote: > >>>> the only realistic way to weed out its reliance on SHA-1 signatures > >>>> from all of its numerous dark corners is to break them. > >>>> Make creation and verification fail in default configuration. > >>> > >>> That sounds like a terrible plan. We should make newer hashes > >>> the default, and we can make tools print a warning if sha1 is used > >>> where it shouldn't, but please don't break things on purpose. > >>> > >>> For many many things sha1 is just fine. Just like md5 or even > >>> crc32. Not everything is about cryptographic security. > >> > >> I would like to make it clear that this is just for *Cryptographic > >> Signatures*, this is not a plan to block SHA-1 for all uses. > >> > >> And for Cryptographic Signatures everything is about cryptography and > >> SHA-1 is not safe anymore. > >> > >> And to be extra clear this means: Certificates, TLS session setup, > >> DNSSEC (although a lot of signatures are still SHA-1 based there ...), > >> VPNs session establishment, PGP, etc... > >> > >>> Also, users will want to verify old signatures essentially forever. > >> > >> This is only reasonable for stuff like emails, where you may have a > >> reasonable expectation that the archived messages have not been > >> tampered with after the fact. Allowing verification of signatures with > >> SHA-1 for any "online" communication would be pointless. > >> > >>> This should be always possible. And finally, the world is huge, > >>> and other users will provide sha1 signatures no matter what we do, > >>> and it is better to check those than to completely ignore them. > >> > >> We need to move the needle at some point. We will be able to set LEGACY > >> crypto policies to allow SHA-1 verification, but we need to be First > >> and Secure here as well. > >> > > > > Did we check to make sure such a change won't break Fedora's *own* GPG > > keys and the GPG keys of preferred third party repositories? It was a > > very unpleasant surprise to have all of CentOS' *second-party* keys > > break with that change. > > Fedora’s RPM package signatures are safe, and have been since > at least Fedora 25 if not earlier. I can confirm that every single > package in the Fedora 25 and Fedora 32 archives are signed with SHA-256 > or later, and presumably the same holds for all releases since Fedora > 25. > > Qubes OS’s rpmcanon tool can be used to check if a package is signed > with SHA-1: it will return an `InsecureAlgorithm` error for such > packages unless the `--allow-weak-hashes` flag is passed. It does so > by parsing the signatures itself before passing them to RPM. Did you check our preferred third-parties? From memory, we have shipped, are shipping, or will be shipping repository definitions for repositories from the following providers: * RPM Fusion * Google * COPR * Microsoft -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
