Path: csiph.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!news.uzoreto.com!aioe.org!bofh.it!news.nic.it!robomod
From: Salvatore Bonaccorso <carnil@debian.org>
Newsgroups: linux.debian.kernel
Subject: Re: please consider disabling obsolete crypto in 5.10 and later
Date: Thu, 25 Feb 2021 11:40:01 +0100
Message-ID: <BMmdP-1Py-3@gated-at.bofh.it>
References: <BD0YV-5Nt-1@gated-at.bofh.it> <BDOVI-3Hz-7@gated-at.bofh.it>
Old-Return-Path: <salvatore.bonaccorso@gmail.com>
Sender: robomod@news.nic.it
Mail-Followup-To: Ard Biesheuvel <ardb@kernel.org>, debian-kernel@lists.debian.org, waldi@debian.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Approved: robomod@news.nic.it
Lines: 65
Organization: linux.* mail to news gateway
Xref: csiph.com linux.debian.kernel:69614

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