On Wed, Mar 09, 2022 at 02:32:48PM +0200, Alexander Bokovoy wrote: > On ke, 09 maalis 2022, Daniel P. Berrangé wrote: > > 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é <berrange@xxxxxxxxxx> 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. > > Specifically, Kerberos is one of those protocols and MIT Kerberos is one > of those implementations which currently forced to use SHA-1 due to > interoperability issues and also due to compliance with RFCs. > > In the context of Fedora development, for example, use of Anonymous > PKINIT requires usage of SHA-1 in PKINIT pre-authentication module in > MIT Kerberos. We have to support that or Fedora developers would not be > able to obtain their Kerberos tickets. > > For more details see https://bugzilla.redhat.com/show_bug.cgi?id=2060798 I assume RHEL is going to have to solve that problem with Krb because it wouldn't be viable to break Krb in RHEL, any more than it would in Fedora. 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@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
