d@nny disc@ mc²do you think linus has done the full kconfig cannonball run recently
i have
insane shit
+#ifdef CONFIG_PKCS7_WAIVE_AUTHATTRS_REJECTION_FOR_MLDSA
+ bool authattrs_rej_waivable; /* T if authatts rejection can be waived */
+#endif
"authatts" what is the purpose of this typo besides signaling a typo
this one is low-effort. get a real job
git show 965e9a2cf23b066d8bdeb690dff9cd7089c5f667
commit 965e9a2cf23b066d8bdeb690dff9cd7089c5f667 (tag: keys-next-20260206, dhowells/keys-next)
Author: David Howells <[email protected]>
Date: Thu Feb 5 13:02:41 2026 +0000
pkcs7: Change a pr_warn() to pr_warn_once()
Only display the "PKCS7: Waived invalid module sig (has authattrs)" once.
Suggested-by: Lenny Szubowicz <[email protected]>
Signed-off-by: David Howells <[email protected]>
Tested-by: Lenny Szubowicz <[email protected]>
cc: Lukas Wunner <[email protected]>
cc: Ignat Korchagin <[email protected]>
cc: Jarkko Sakkinen <[email protected]>
cc: Stephan Mueller <[email protected]>
cc: Eric Biggers <[email protected]>
cc: Herbert Xu <[email protected]>
cc: [email protected]
cc: [email protected]
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c b/crypto/asymmetric_keys/pkcs7_verify.c
index 519eecfe6778..474e2c1ae21b 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -427,7 +427,7 @@ int pkcs7_verify(struct pkcs7_message *pkcs7,
if (pkcs7->have_authattrs) {
#ifdef CONFIG_PKCS7_WAIVE_AUTHATTRS_REJECTION_FOR_MLDSA
if (pkcs7->authattrs_rej_waivable) {
- pr_warn("Waived invalid module sig (has authattrs)\n");
+ pr_warn_once("Waived invalid module sig (has authattrs)\n");
break;
}
#endif
cloudflare is expected, but
linux-crypto is notthanks lenny for testing
that's definitely not all i saw but it's all that's from the one branch. then he throws in several weeks worth of other work on cifs. TWO FUCKING PERL SCRIPTS IN THE COMMIT MESSAGES yeah that's something normal to see
mr president a third perl script has hit the git log
ah! i had forgotten that git lets you time travel
........hence the linus email..........
anyway this is all still up of course
........hence the linus email..........
anyway this is all still up of course
i'm upset about linus
he was mean to an incredibly kind and devoted maintainer who cares........more than him
this is the one that had me reading that brain destroying nist spec
git show f3eccecd782dbaf33d5ad0d1fd22ea277300acdb
commit f3eccecd782dbaf33d5ad0d1fd22ea277300acdb
Author: David Howells <[email protected]>
Date: Wed Jan 21 12:41:42 2026 +0000
pkcs7: Allow the signing algo to do whatever digestion it wants itself
this one is SO close to sounding like a real commit message. except for all the specifics
Allow the data to be verified in a PKCS#7 or CMS message to be passed
directly to an asymmetric cipher algorithm (e.g. ML-DSA) if it wants to do
whatever passes for hashing/digestion itself.
so GODDAMN pissed he would create a capability that does not exist like this
this is, btw, one intended result of NIST's document that frames a "signature" as distinct from "hashing"
these people don't deserve to work for the government
The normal digestion of the
data is then skipped as that would be ignored unless another signed info in
the message has some other algorithm that needs it.
The normal digestion of the data is then skipped
nope! nope. not something that you would ever allow in the real world
Note that whilst ML-DSA does allow for an "external mu", CMS doesn't yet
have that standardised.
i didn't actually spend any time looking this up because i assumed it was completely made up
this shit is just funny. no, that's not how any of this works, why is this on master
no fucking way am i adding an early return 0 to my real crypto because someone thinks quantum computing is real and can hurt you. pascal's wager
+ if (!sinfo->authattrs && sig->algo_takes_data) {
+ /* There's no intermediate digest and the signature algo
+ * doesn't want the data prehashing.
+ */
+ sig->m = (void *)pkcs7->data;
+ sig->m_size = pkcs7->data_len;
+ sig->m_free = false;
+ return 0;
+ }
+
i guess there's another problem which is that ML-DSA most definitely does not do a checksum for you. symmetric and asymmetric crypto are not like easy <=> hard
it's called ML because it uses machine learning, so it was developed by an AI
oh yeah this is where i started screaming and saying this is all completely insane shit to be doing in the kernel
this would be headline on lwn if it was in a gnu project
+ if (!sinfo->sig->m_free) {
+ pr_notice_once("%s: No digest available\n", __func__);
+ return -EINVAL; /* TODO: MLDSA doesn't necessarily calculate an
+ * intermediate digest. */
+ }
none of this shit makes any sense btw. you can just type shit. IETF material
this is i think when i became convinced oh this is for real like this is gonna be released with signed modules upon 7.0
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index bd38ba4d217d..4c5199b20338 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -46,6 +46,8 @@ struct public_key_signature {
u8 *m; /* Message data to pass to verifier */
u32 s_size; /* Number of bytes in signature */
u32 m_size; /* Number of bytes in ->m */
+ bool m_free; /* T if ->m needs freeing */
+ bool algo_takes_data; /* T if public key algo operates on data, not a hash */
const char *pkey_algo;
const char *hash_algo;
const char *encoding;
the fuck are you doing in public_key.h asshole?????
i'm going backwards so this comes before the previous
git show f728074f1f577565c97e465652c3d4afb0964013
commit f728074f1f577565c97e465652c3d4afb0964013
Author: David Howells <[email protected]>
Date: Mon Jan 26 09:49:24 2026 +0000
pkcs7, x509: Rename ->digest to ->m
went into a brief fugue state
diff --git a/crypto/asymmetric_keys/asymmetric_type.c b/crypto/asymmetric_keys/asymmetric_type.c
index 348966ea2175..2326743310b1 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -593,10 +593,10 @@ static int asymmetric_key_verify_signature(struct kernel_pkey_params *params,
{
struct public_key_signature sig = {
.s_size = params->in2_len,
- .digest_size = params->in_len,
+ .m_size = params->in_len,
.encoding = params->encoding,
.hash_algo = params->hash_algo,
- .digest = (void *)in,
+ .m = (void *)in,
.s = (void *)in2,
};
this is very pythonic
this is a much bigger change than adding the fields
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index 81098e00c08f..bd38ba4d217d 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -43,9 +43,9 @@ extern void public_key_free(struct public_key *key);
struct public_key_signature {
struct asymmetric_key_id *auth_ids[3];
u8 *s; /* Signature */
- u8 *digest;
+ u8 *m; /* Message data to pass to verifier */
u32 s_size; /* Number of bytes in signature */
- u32 digest_size; /* Number of bytes in digest */
+ u32 m_size; /* Number of bytes in ->m */
const char *pkey_algo;
const char *hash_algo;
const char *encoding;
no. no. that's not real. that's not a thing
he keeps getting his boys to rizz him up
Signed-off-by: David Howells <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
cc: Lukas Wunner <[email protected]>
cc: Ignat Korchagin <[email protected]>
cc: Stephan Mueller <[email protected]>
cc: Eric Biggers <[email protected]>
cc: Herbert Xu <[email protected]>
cc: [email protected]
cc: [email protected]
this one's where he acts like people think that going back through time in git is more invisible?
git show 2c62068ac86bdd917a12eef49ba82ec8b091208b
commit 2c62068ac86bdd917a12eef49ba82ec8b091208b
Author: David Howells <[email protected]>
Date: Wed Jan 21 13:33:37 2026 +0000
x509: Separately calculate sha256 for blacklist
Calculate the SHA256 hash for blacklisting purposes independently of the
signature hash (which may be something other than SHA256).
This is necessary because when ML-DSA is used, no digest is calculated.
Note that this represents a change of behaviour in that the hash used for
the blacklist check would previously have been whatever digest was used
for, say, RSA-based signatures. It may be that this is inadvisable.
This is necessary because when ML-DSA is used, no digest is calculated.
yeah figured that out after wasting an hour of my life
Note that this represents a change of behaviour
yeah i mean the only thing i don't know is why you would say this out loud. i was literally reading the kbuild docs should i keep going
It may be that this is inadvisable.
i can't understand the theory of this process? like you can act like the IETF in the linux kernel? the place where people do close review?
specifically until linus said his maintainers can't change gitignore files during the california surveillance bill during the fascism
do we wanna keep going through cpython and rust
this is fucked up and appears ready to be merged/shipped/whatever. it will make module signing broken and will be just in time to comply with the california surveillance bill. i have stopped thinking it looks fake i can show you so much more shit in cpython
what power structure can stop people from being immediately harmed
i actually would love to chat with people working on build systems about checksum-based invalidation as like an interesting field of research with many avenues to reify the implicit graph structure and not because people are editing
public_key.h in ring 0 like it's a fucking joke (it has to be a joke for long enough until it's real)yeah man call 911 tell them about module signing and post-quantum-crypto being a ruse to crack ring 0
noticed another completely insane thing https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-pqc&id=d3b6dd90e23ef1b57143e60668175ecd890948d1
+config CRYPTO_MLDSA
+ tristate "ML-DSA (Module-Lattice-Based Digital Signature Algorithm)"
+ select CRYPTO_SIG
+ select CRYPTO_LIB_MLDSA
+ help
+ ML-DSA (Module-Lattice-Based Digital Signature Algorithm) (FIPS-204).
+
+ Only signature verification is implemented.
+
actually i guess that's the reason for the hackneyed openssl stuff if openssl can sign or something? but anyway only implementing verification is the weirdest way to implement asymmetric crypto
i was gonna say also the code looks wrong bc how does that implement the brain destroying nist standard but ohohoho https://www.phoronix.com/news/Linux-7.0-Crypto-ML-DSA (note: phoronix posted genuine reiser apologia like two years ago. this is not a link because phoronix is good to link to)
This ML-DSA introduction for signing within the kernel comes in the same release of Linux finally removing SHA-1 module signing support.
it is TEXTBOOK fucking IETF to pull this shit
In addition to that initial ML-DSA support is also AES library updates in the now-merged crypto library pull.
yeah that's a normal way to talk about things in a pull request
lol at other links on that phoronix page
Scoped User Access In Linux 6.19 To Reduce Speculation Barriers & Its Performance Hit
CVE-2026-0915: GNU C Library Fixes A Security Issue Present Since 1996
i will literally become a hurd contributor
i considered feeling helpless but i didn't see what that did for me
i did read IBM and the Holocaust
a single alternate email address for our friend david howells used to write a single commit dated 15 years ago (and from the nearby tags, not likely backdated) weird
git show dcd42ed3ea829aa99cf00d34c61e082ce575b193
Author: David Howells <[email protected]>
AuthorDate: Wed Oct 27 17:28:34 2010 +0100
still so mad i didn't know about
--filter=blob:none until today thanks to @Gaelan who is a powerful demigod. the git cli should do this and "commit" changes to file contents. so easythere's no way openssl is the only way to generate signatures
bet rust has 30 ml-dsa impls all of which inherently cracked by virtue of using cargo
Bredroll@hipsterelectron the python hazmat thing has one too