kcxt2d ago

if you're using AI regularly to generate text/presentations that you intend to use persuasively i don't think i can trust a single thing you say. Where does the AI end and the human begin?

I think this is why im so against AI generated commit messages especially if the code was written by a human, you wrote the code so you should be able to demonstrate that you understand what the change does and why.

If you're deferring that to an AI and you made a subtle logic error that it decides to justify for you suddenly we have obfuscated our own fucking zero days. Good luck finding the bug if the commit message describes the error as if it was intentional.

For general text, if you start with the conclusion and let the AI write the justification then there is no justification!!! Details matter, having a paper trail for decision making matters.

I wonder how many executives will escape the consequences of their white collar crimes by blaming AI.

AI zombification is coming and it's going to create a distinct difference in communication styles between those who do and don't use it, honestly that point is already here.

And we're gonna find out yet again that marx was right when it becomes clear that AI usage correlates with class lines.

Show threadd@nny disc@ mc²2d ago
@cas people currently right now inject vulnerabilities into our shared source code by doing exactly as you describe and describing it as intentional. about 6 commits by red hat / IBM engineer david howells in linux-crypto were live on his linux-fs fork from friday to late sunday, before he reset and force pushed. linus agreed with include/crypto/public_key.h turning digest_size -> m_size. he was able to hide these commits not through "AI" (arguably it wasn't hidden at all) but at each point relying upon the right people to not say a thing. i throughout monday and tuesday i recorded ingo molnar adding a make syncconfig that weaponizes the howells config. i guess it makes sense that PREEMPT_RT was actually a fiction—it makes more sense than a monolithic kernel doing anything by half
Show threadd@nny disc@ mc²2d ago

@cas i 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:

  • fix-patch-lines, which pretty openly states that its goal is to create patch files that work after nontrivial modifications

  • klp-build, which will modify and update the kernel configuration so that it the above is not exposed.

linux

linux fork for silly nonsense

Codeberg.org
Show threadd@nny disc@ mc²2d ago
@cas in fact, to put these two points together, the post-"quantum" key shit is used as a pretext to fundamentally alter everything we used to believe was safe. signal instituted a new protocol and i don't plan to break it, but it's not scientific and weak against adversarial randomness. signal doesn't let you choose, so for postmarket i'd recommend immense caution with tbh any of the crypto changes but especially those two men. the new signal cryptographer, at the last lines of the 60 pages plus appendix, mentions that randomness is the os's job—someone has to protect them. you also may genuinely be able to just run an older version—but the way these things go, i assume they released some devastating vulns right after adoption
Show threadCassandrich

@hipsterelectron @cas Louder for the folks in the back:

"The post-'quantum' key shit is used as a pretext to fundamentally alter everything we used to believe was safe."

So. Much. This.

Mar 27 at 7:32pmWeb