bug#80669: concern regarding linux-crypto dependency from the current release cycle

Hello coreutils,

I was hoping to open a discussion about implementing the BLAKE3 algorithm, the project's understanding of length extension attacks, and how an archive format might be able to take advantage of features of tree hashes of this variety in concert with an implementation such as coreutils.

I would love nothing more than to engage in this, but I happened to be made aware of a new section in the kernel config through what seems to have been "luck" on Friday and a lot of facially broken changes are being added at an incredible clip.


So that you can quickly determine if I am wasting your time: if you have a local checkout, the following abbreviated refs modify what I believe to be precisely an area coreutils builds using the `--with-linux-crypto` configure script would subsequently become affected by. These are from two engineers, one David Howells from Red Hat / IBM, and Eric Biggers of Google.

965e9a2cf23b066d8bdeb690dff9cd7089c5f667   pkcs7: Change a pr_warn() to pr_warn_once()
91db696adea4d76017b1e1f45915a5cbf04e8da3   pkcs7: Allow authenticatedAttributes for ML-DSA
0ad9a71933e73c8a2af101d28e9a1dc35bae02d5   modsign: Enable ML-DSA module signing
8bbdeb7a25b4cd3d829136a2e12982b8ee7d7991   pkcs7, x509: Add ML-DSA support
f3eccecd782dbaf33d5ad0d1fd22ea277300acdb   pkcs7: Allow the signing algo to do whatever digestion it wants itself
f728074f1f577565c97e465652c3d4afb0964013   pkcs7, x509: Rename ->digest to ->m
2c62068ac86bdd917a12eef49ba82ec8b091208b   x509: Separately calculate sha256 for blacklist

fbfeca74043777b48add294089cd4c4f68ed3377   lib/crypto: aes: Drop 'volatile' from aes_sbox and aes_inv_sbox
9ddfabcc1ed884ef47bcca317e77596c797bef83   lib/crypto: sha1: Remove low-level functions from API
5023479627e3e85a97807f612bea2eddbf202e1d   ipv6: Switch to higher-level SHA-1 functions
20d6f07004d639967dcb00994d56ce6d16118e9e   lib/crypto: tests: Add a .kunitconfig file
4478e8eeb87120c11e90041864c2233238b2155a   lib/crypto: tests: Depend on library options rather than selecting them
beeebffc807531f69445356180238500f56951cc   lib/crypto: powerpc/aes: Fix rndkey_from_vsx() on big endian CPUs
ffd42b6d0420c4be97cc28fd1bb5f4c29e286e98   lib/crypto: mldsa: Clarify the documentation for mldsa_verify() slightly


This is my checkout of Linus's checkout:
https://codeberg.org/cosmicexplorer/linux/src/branch/master

This is Linus's checkout:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

c369299895a591d96745d6492d4888259b004a9e

In particular, there was:
- ML-DSA module signing added with this openly broken config section:
config PKCS7_WAIVE_AUTHATTRS_REJECTION_FOR_MLDSA
+	bool "Waive rejection of authenticatedAttributes for ML-DSA"
+	depends on PKCS7_MESSAGE_PARSER
+	depends on CRYPTO_MLDSA
+	help
+	  Due to use of CMS_NOATTR with ML-DSA not being supported in
+	  OpenSSL < 4.0 (and thus any released version), enabling this
+	  allows authenticatedAttributes to be used with ML-DSA for
+	  module signing.  Use of authenticatedAttributes in this
+	  context is normally rejected.

- wide-ranging changes to cryptographic APIs (I was under the impression `include/crypto/public_key.h` is shared with dependents such as coreutils)


- finally, there is this new directory `scripts/livepatch`, with two files of significance:
1. fix-patch-lines, which pretty openly states that its goal is to create patch files that work after nontrivial modifications
2. klp-build, which will modify and update the kernel configuration so that it the above is not exposed.

I had been looking to type a more general document at some length and continued to find further and further issues and thought this might at least be sufficient for your purposes. I will note that david howells in particular had performed a hard reset of some variety on his fork last night, and lwn had multiple articles online over the weekend which mentioned his name:

https://lwn.net/Articles/1012946/
https://lwn.net/Articles/525592/

I do apologize for introducing this and would like to contribute and to learn from your team further under better circumstances. I happened to be working on packaging coreutils in the spack package manager (where it is already packaged, but not quite as nicely as it could be), and I was relieved to no end to hear that coreutils checksumming remains distinct from the torrent of real harm that linux users will likely face.

binutils was also mentioned in an faddr2line script but not in the way a library dependency might be concerned about.

Thanks, and sorry,
d@nny