On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote: > On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé <berra...@redhat.com> > wrote: > > > > On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote: > > > We've been disabling it in TLS, but its usage is much wider than TLS. > > > The next agonizing step is to restrict its usage for signatures > > > on the cryptographic libraries level, with openssl being the scariest one. > > > > > > Good news is, RHEL-9 is gonna lead the way > > > and thus will take a lot of the hits first. > > > Fedora doesn't have to pioneer it. > > > Bad news is, Fedora has to follow suit someday anyway, > > > and this brings me to how does one land such a change. > > > > > > --- > > > > > > Fedora is a large distribution with short release cycles, and > > > 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. > > > But it's unreasonable to just wait for, say, Fedora 37 branch-off > > > and break it in Rawhide for Fedora 38. > > > The fallout will just be too big. > > > > If RHEL-9 has lead the way, what are the stats for real world > > RHEL impact ? > > We'll know when the real world starts using RHEL-9 en masse? > > > What is/was the absolute number of packages and % number of > > packages from the RHEL distro that saw breakage ? > > Does preventing the distro from installing altogether count as 100%? > If yes, 100%. =) > Jokes aside, I can't give you an accurate estimate yet.
Perhaps a useful first step is to just modify the three main crypto libs (gnutls, openssl, and nss) to send a scary warnihg message to stderr/syslog any time they get use of SHA1 in a signature. Leave that active for a release cycle and see how many bug reports we get. > > Such figures can give us a better idea of impact on Fedora > > beyond "too big". > > > > Assuming RHEL-9 has dealt with the problems, Fedora should > > inherit those fixes, which gives us a good base for the most > > commonly used / important packages in Fedora. > > Yeah, that's what I meant by the good news. > But that won't solve all Fedora problems. > > > If the breakage % from RHEL was single digits, and those > > were the most important packages to fix from Fedora's POV > > too, then maybe the fall is not in fact "too big". It might > > be sufficient to identify a few important remaining packages > > to validate, and just accept the fallout for the remaining > > less important packages in Fedora can be fixed after the > > fact ? > > At a quick glance, > I eyeball RHEL at ~2k packages and Fedora at ~22k packages. > I think that limited analysis 's enough to safely claim > that leaving the 90% of the packages you've labelled "less important" > to be "fixed after the fact" is gonna be a disaster. > One cycle doesn't sound enough. That 90% of packages are not all going to be using cryptographic signatures though. Only a relatively small subset will do anything crypto related, and most of that just be HTTPS and completely outsourced to a crypto library. IOW of that 90% of packages not in RHEL, it could conceivably be single digits that will be using cryptographic signatures with SHA-1. An even smaller percentage of those will be considered important enough to be blockers for this change. 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 on the list, report it: https://pagure.io/fedora-infrastructure
