On Mon, 1 Feb 2021 at 22:21, Salvatore Bonaccorso <car...@debian.org> wrote: > > Hi Ard, > > On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote: > > L.S., > > > > This is a request to consider disabling obsolete crypto in 5.10 and > > later Debian builds of the Linux kernel on any architecture. > > > > We are all familiar with the rigid rules when it comes to not breaking > > userspace by making changes to the kernel, but this rule only takes > > effect when anybody notices, and so I am proposing disabling some code > > downstream before removing it entirely. > > > > 5.10 introduces a new Kconfig symbol > > > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE > > > > which is enabled by default, but depends on support for the AF_ALG > > socket API being enabled. In turn, block ciphers that are obsolete and > > unlikely to be used anywhere have been made to depend on this new > > symbol. > > > > This means that these obsolete block ciphers will disappear entirely > > when the AF_ALG socket API is omitted, but we can get rid of these > > block ciphers explicitly too, by not setting the new symbol. I.e., > > adding > > > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set > > > > to the kernel configs. Note that Fedora have already done so in release 33 > > [0] > > > > The block ciphers in question are RC4, Khazad, SEED, and > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known > > to be used via the socket API (although a change was applied to > > iwd/libell recently to get rid of an occurrence of RC4 - this change > > has already been pulled into bullseye afaik) > > > > Note that this is not a statement on whether these algorithms are > > secure or not -there is simply no point in carrying and shipping code > > that nobody uses or audits, but which can be autoloaded and exercised > > via an unprivileged interface. > > FTR (posteriori), we tried that in > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737 > (and is in the 5.10.12-1 upload to unstable). >
Confirmed, thanks.