Re: please consider disabling obsolete crypto in 5.10 and later
Hi Ard,
On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso 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).
There were two reports which might be in the end related to that
change:
https://bugs.debian.org/979764
https://bugs.debian.org/983508
We have long that nfs-utils need to be updated, but the version was so
outdated, that progress on updating to a newer version stalled, and
could not be done in time for bulleye. Once bullseye is released I
guess this really needs to be prioritzed in some way.
Ard, have you any insight in the above, so, should we revert the above
change for bullseye again?
Regards,
Salvatore
Reply to: