that PHP fix is 13k lines
5k apparently of non-tests
that's all human written, right? I wouldn't want to speak out of turn about sprawling quick fix diffs
2 Boosts
0 Likes
@davidgerard it’s not a quick fix, they spent months on it. The patch is massive because of massive tech debt in php’s byzantine design, there was no other way to do it.
The patch was co-signed by five humans and zero bots
@0xabad1dea @davidgerard Sorry if this horse is already dead, but one of the co-signers has since admitted that "a substantial amount of AI" was involved: https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065#commitcomment-206067056
@ne_ @0xabad1dea @davidgerard That isn’t really what they write though, is it? Taken slightly out of context.
@discoursology @ne_ @0xabad1dea we should definitely take the guys who just got busted at their word about their excuses, ok
why are you people like this
@ne_ @0xabad1dea @davidgerard quoting like a creationist isn’t a good look, irrespective of your position on AI. The full quote is: “I'd also like to let you know that, while a substantial amount of AI has been used for analysis, identification of vulnerable code, patch verification, and even test generation, only a small fraction of the functional changes were AI-generated and all of it was thoroughly reviewed and tested.”
The real message: PHP continues to be be high risk due to tech debt.
@acdha@code4lib.social @ne_ @0xabad1dea
> "we used the slop machine extensively but there's very little slop in the output honest"
> look inside
> slop tells all through
nobody is obliged to assume good faith in bad faith actions, and we don't have to take them at their word when the diff already said otherwise
@ne_ @0xabad1dea EVERY FUCKIN TIME
@0xabad1dea oh well if they didn't say they used a bot, well
others wonder a bit, e.g.
https://chitter.xyz/@JennyFluff/117481147340068318
https://chitter.xyz/@JennyFluff/117479752875775371
https://chitter.xyz/@JennyFluff/117481175927488079
someone else listed particular comments that looked extremely bot to them, tho i can't find the post just now
@davidgerard Were working on the fix way before the CVE released
@davidgerard
That 13k lines of code wouldn’t happen to include a back door for intelligence agencies would it? I’m sure everyone will go over it before applying it, right?
@davidgerard @catsalad the correct fix is so much simpler
if (going_to_run_out_of_memory) {
dont();
}
@davidgerard and it's a band-aid on top of trying to handle out-of-memory conditions, which they have no business trying to handle - php is not an OS kernel, they should just kill the process early.
and they knew that code was bad for two years. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
@davidgerard
Given the problem had been discovered in 2024, they even seems a very few of them to me.
Good chance it's all done manually with search & replace. Monster pain, but doable.
@davidgerard On an extremely cursory look at the patch diff, the code is of course awful because it's in C, but it looks like human-writen awful C. No obvious AI "tells" have jumped out at me. The tests even appear to test the fixes rather than just print "yeah, everything's just fine, ship it".
It looks like several people have in fact put in quite a heroic effort to fix this, for which they should get a commendation, but it's a shame that they have to waste their talents on this unmaintainable mudball.
@pndc @davidgerard What I was told is that the fix process for this vuln (actually pair of vulns) was a process that lasted about a month and crossed multiple organizations
@pndc @davidgerard oh I have plenty of obvious AI ones when I looked through earlier:
- changed test cases to something different for no reason. I talked about this earlier https://chitter.xyz/@JennyFluff/117479752875775371
- out of memory checks on each iteration of a loop instead of growing the thing first, checking it and then coping over the data
random function return type changes for no reason
- several function return types were changed from void to bool for no apparent reason.
- gates on the newly added return type changed function return true or SUCCESS depending on the file (when if you'd even do that return false at a failed gate!)
- sometimes they handle OOM errors with a goto, sometimes with returns. Sometimes goto statements jump to different labels instead of just oom, like oom_function_name
- sometimes they gate OOM error handling with some other condition that makes no sense
This is a dumpster fire of a patch.
@JennyFluff @davidgerard Oh yeah, it's a dumpster fire alright, and one that's clearly the result of a mechanical process that didn't consider solving the wider problem. But that doesn't necessarily indicate AI. I've worked on projects with confirmed-human commits not unlike that. Sometimes people really do grep around and paste in boilerplate fixes, tweaking randomly as they go to make it compile.
There's no smoking gun, it could go either way, and I'm prepared to give them the benefit of the doubt. I'm sure we'll find out soon enough when the next batch of CVEs drop.
@pndc @davidgerard I don't know, if I grep and replace around I end up with a lot of the same execution and some artifacts that look the same, maybe same broken.
You could argue this is done by 4 people doing different things but I don't know this because it was listed as one commit. I mean this *could* explain why it sometimes returns false/true, sometimes Success/Failure and sometimes goto oom in the code.
This *smells* like AI code was involved down the line.
If you leave all the technical details out, you still ended up with a solution that now is a lot harder to service than before because everything has function call specific OOM handling added, but it doesn't follow a consistent framework and there are some exceptions to the implementation that have zero comments added.
I specifically did not look at the tests they *added* to verify the code, only the ones they changed. And things are very weird.
@davidgerard It doesn't look LLM generated at first blush, but I'm no longer confident in my ability to tell to be honest. Either way, you could not possibly pay me enough to sign off on +11k -1k over 423 files with most of it being random branches and gotos...
The fix for EOL versions are ~300 lines.
- 7.4: https://github.com/php/php-src/commit/712e60f9edfd03f0960fc4fc3c2c375f42b90aa2
- 8.0: https://github.com/php/php-src/commit/82f8f31b16a035c1b67cc253e79f7cc288f4cc20
- 8.1: https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a
@davidgerard According to this page:
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
they were informed of one of the vulnerabilities in 2024, and wasted much of the intervening time arguing about how to fix it. So I'm not sure this one qualifies as "quick fix".
(Still glad to not be running any PHP on anything I manage...)
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
they were informed of one of the vulnerabilities in 2024, and wasted much of the intervening time arguing about how to fix it. So I'm not sure this one qualifies as "quick fix".
(Still glad to not be running any PHP on anything I manage...)
@corbet i just spent my entire day and missed doing today's post/episode because of it, so i'm not enamoured of PHP
i expect the PHP team is not having the greatest day either
@davidgerard according to the blog post that went with this security release, they've been working on this patch for about 2 MONTHS, so this gigapatch may very well likely be human
@davidgerard after seeing some more detailed analysis on the patch I may need to retract my previous toot...
@techokami wondering which human put a little juicing in their code
@davidgerard I feel like retreating tothe one language not rotted with slop... Motorola 68000 assembly
@davidgerard php team busy at work
@stoori i expect they're not having the greatest day either
@davidgerard Even if this isn't that, at *some* point we're going to see a quick "everyone panic! Keystone tool XYZ is compromised!" 13kloc fix that fixes … something … then deliberately adds three more well-obfuscated backdoors.
@cstross if we haven't seen it yet we haven't noticed it
vibe code is a playground for the bad guys
@davidgerard We've spent more than 75 years trying to keep code and data separate and vibe coding just drunk-drove a bulldozer through a lifetime of hard-learned lessons about best practices.
just an ever-increasing avalanche of evidence that John von Neumann fucked everything up forever
CC: @davidgerard@circumstances.run
@cstross @davidgerard Everyone knows the solution to in-band signaling is more in-band signaling with a lid of extra begging and pleading on top.
![[object Object]](https://media.mas.to/accounts/avatars/109/287/758/133/964/366/original/0f3099c0adfb36a0.png "[object Object]")
@davidgerard just a quick 13kloc fix for my personal homepage tools
@davidgerard I was worried enough about the Internet Archive vibe coding forks of EOL PHP versions but I guess this is just where we're at. Oh well, the Internet was fun while it lasted