On Wed, Mar 9, 2022 at 10:57 AM Daniel P. Berrangé <berrange(a)redhat.com> 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(a)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.
I left my crystal ball at home today,
but I don't need it to say it'd be ~0 bugs filed if we log to syslog
and ~3 if we log to stderr/stdout, all named
"$CRYPTOLIB has no business messing up my stderr/stdout",
which we'll promptly close by reverting the changes.
> > 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 :|