lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wj7TAP8fD42m_eaHE23ywfp7Y2ciqeGC=ULsKbuVTdMrg@mail.gmail.com>
Date: Mon, 6 Oct 2025 12:29:47 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Vegard Nossum <vegard.nossum@...cle.com>
Cc: Eric Biggers <ebiggers@...nel.org>, Jiri Slaby <jirislaby@...nel.org>, 
	Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, netdev@...r.kernel.org, 
	Jakub Kicinski <kuba@...nel.org>, "Theodore Ts'o" <tytso@....edu>, "nstange@...e.de" <nstange@...e.de>, 
	"Wang, Jay" <wanjay@...zon.com>
Subject: Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL]
 Crypto Update for 6.17]

On Mon, 6 Oct 2025 at 12:12, Vegard Nossum <vegard.nossum@...cle.com> wrote:
>
> Yes, thank you, I've already acknowledged that my patch caused boot
> failures and I apologize for that unintentional breakage. Why does this
> mean we should throw fips=1 in the bin, though?

That's not what I actually ever said.

I said "as long as it's that black-and-white". You entirely ignored that part.

THAT was my point. I don't think it makes much sense to treat this as
some kind of absolute on/off switch.

So I would suggest that "fips=1" mean that we'd *WARN* about use of
things like this that FIPS says should be off the table in 2031.

The whole "disable it entirely" was a mistake. That's obvious in
hindsight. So let's *learn* from that mistake and stop doing that.

If somebody is in a situation where they really need to disable SHA1,
I think they should hard-disable it and just make sure it doesn't get
compiled in at all.

But for the foreseeable immediate future, the reasonable thing to do
is AT MOST to warn about fips rules, not break things.

Because the black-and-white thing is obviously broken. One boot
failure was enough - we're *NOT* doubling down on that mistake.

                Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ