On Wed, 10 Mar 2021 at 14:38, Salvatore Bonaccorso <car...@debian.org> wrote: > > Hi Ard, > > On Tue, Mar 09, 2021 at 05:45:01PM +0100, Ard Biesheuvel wrote: > > On Thu, 25 Feb 2021 at 12:06, Ard Biesheuvel <a...@kernel.org> wrote: > > > > > > On Thu, 25 Feb 2021 at 11:35, Salvatore Bonaccorso <car...@debian.org> > > > wrote: > > > > > > > > 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? > > > > > > > > > > Hello Salvatore, > > > > > > I think the issue is the patch below. Having something that requires > > > RC4 and MD5 for security is an absolute joke in 2021, so I won't > > > recommend you reverting it. Instead, you should really fix nfs-utils > > > with priority. > > > > > > > Any updates on this? > > Apologies for not replying earlier. I agree with you. > > Debian's nfs-utils situation is quite bad. As you might know we still > ship 1.3.4, which at best is ancient with respect to upstream. Worse, > we cannot update it at this stage of the freeze (cf. > https://release.debian.org/#release-dates). > > So I guess the only two options we have now is either to revert the > above commit you think is the cause of the issues reported, or if this > is feasible apply the needed changes for nfs-utils (if they can be > determined and can be applied to the old version). >
Reverting the patch in question in the distro kernel seems reasonable, but please keep it as a downstream change only. Note that you will also need to revert the CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE change, or re-enable the ecb(arc4) driver in another way, because the NFS code relies on RC4. > After the Debian bullseye release it defintively needs to be a > priority for nfs-utils to be rebased to 2.5.3 and later (and then in > particular keep up with rebasing it, and not fall into the same issue > again). >
