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
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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
