redsakana
I think X.509 and Kerberos are pretty good actually—compared to many of the alternatives on offer.
@bagder@mastodon.social This suggests a fun exercise for someone interested in messing around with LLMs:
-
Put back all the curl security issues previously found by LLM tools by dropping the fix commits from history or otherwise obfuscating the revert.
-
Feed the re-vulnerabilized repo to a selection of models and see what are the cheapest ones (by memory, time and/or monetary cost) that can find, say, 50%/75%/100% of the issues found by the warehouse-scale "foundation models".
Feels like a large part of the current results should be doable with significantly smaller resources, because being trained on every tweet and reddit post and libgen book ever is not obviously related to the task.
Two screenshots from today's FT. Surely no problems here at all. (The most surprising part may be that Oracle supposedly has $250B of deferred cloud revenue in addition to what OpenAI has promised them.)
(https://www.ft.com/content/7599af3b-2184-4538-8ef9-370e01c1aaa8?syn-25a6b1a6=1 and https://www.ft.com/content/be97df0a-76b1-4cb0-9ba4-d1117d8d1450 , the latter diagram is originally from https://www.theinformation.com/articles/anthropic-commits-spending-200-billion-googles-cloud-chips)
the IPv8 dude is now trying to push his wares on the nanog mailing list and that's some serious AI psychosis going on there
@campuscodi@mastodon.social The code that led to the exploit is kind of mind-blowing: https://www.openwall.com/lists/oss-security/2026/04/18/5
Looking for code of this caliber in obscure projects/forks looks like an optimum case for LLMs since there's little need for hard work like predicting brances or deriving types.
wake up babe, new slopnerability class dropped: find application X that _could_ be linked with some library Y that has a known vulnerability AND X could somehow be operated to reach said vulnerability in Y.
File slop report against X to claim your CVE badge and bug bounties.
(AFAICT this is neither about vendoring a vulnerable version of Y in X nor about vulnerable version of Y being concretely otherwise shipped somewhere where X could also be installed.)
Implemented TPM2 auto-unlock and most of systemd-pcr{phase,fs} for initramfs-tools to get rid of dracut [1]. There's such an amazing amount of potential confused deputies in a typical initramfs (all flavors) that it's like having an entire sheriff's department in your computer.
If you're doing TPM auto-unlock without systemd-pcrphase (PCR 11) or equivalent, grabbing your encrypted root partition can likely be done in less than an hour of physical access without attacking the main OS or any kind of the TPM snooping or other hard work. pcrphase raises the bar, but you still have to get a _lot_ of fairly complex and non-obvious stuff right along the boot chain.
[1] dracut is kind of a second-class citizen on Debian, but it _could_ be fine on its own. However when combined with its systemd-in-the-initramfs module (enabled by default), the result is just an incredible fucking mess of pointless complexity. And I'm saying this after getting way too familiar with the giant pile of shell scripts that is initramfs-tools.