Re: Landing a larger-than-release change (distrusting SHA-1 signatures)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/9/22 1:56 AM, 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.

To be clear, the actual mechanism to turn off SHA1 for signatures doesn't involve any changes to any of our crypto libraries, it involves changing the crypto policies file. With crypto policies, you can actually turn off almost any algorithm involved in SSL or signatures in all of our libraries. There is really no good way to 'log' from the crypto libraries.

Actually I think that provides a way forward that might work.

1) in fedora 37, provide a policy that turns SHA-1 off. in our testing, we encourage people to run with that policy and write bugs against components.

2) in fedora 38, SHA-1 gets turned of in the default policy and ships that way. Things that still fail would only work once in the legacy policy.

3) some day in the future (fedora 39?) it gets turned off legacy as well.

bob

_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux