Day changed to 2026-10-09
[18:11] jfw: jfw reporting in OK for now from heavy earthquake in panama city.
[19:21] dorion: it was noticable, but mild here over in el barrio silvestre.
[19:37] jfw: magnitude 7.7 apparently
Day changed to 2026-10-10
[01:04] jfw: I hear it was felt from parts of colombia and costa rica. quite a pile of aftershocks too - http://jfxpt.com/wp-content/uploads/2026/10/azuero-quakes.png
[04:38] jfw: another big one in the same belt, mag 6. shaking wasn't as strong but took its time.
[06:45] caai: not cool
[12:41] dorion: fausto is on the azuero, very close to epicenter, surviving it.
[21:27] jfw: dorion: oh damn. I hope not in that town where "we're trying to figure out how to reach it by air, because the road collapsed and it's unreachable by land"
[21:29] jfw: perhaps now might be the proverbial second best time to hustle on promoting the mesh radios
[21:32] jfw: my own planned next step has been to research more into the wide array of extant hardware choices to find one that retains the upsides of the heltec v3/4 while resolving the poor battery life, and stock up on that
[21:33] jfw: there's probably no one choice that's best for all uses but at least narrow it down
Day changed to 2026-10-14
[14:38] SamyTF: @jfw can you call me plz ?
[14:39] SamyTF: need some info to come over
[14:50] jfw: done.
[20:11] dorion: ftr, fausto turned out ok.
[20:11] jfw: light but prolonged shaking, de nuevo...
[20:17] jfw: and yeah, not quite that town perhaps but close enough, structures leveled & roads turned into staircases, repaired enough to make it home in a few days.
[20:17] wotbot: 2026-10-10 21:27 (#jwrd) jfw: dorion: oh damn. I hope not in that town where "we're trying to figure out how to reach it by air, because the road collapsed and it's unreachable by land"
Day changed to 2026-10-22
[08:54] jfw: in insecurity news, https://www.php.net/archive/2026.php#2026-10-21-5 seems to be making a splash, investigating now.
[10:07] jfw: idk how they think they get away with writing these "advisories" without linking/citing the code and patches under discussion.
[10:19] jfw: plus just posting them on static web & github pages with no comments...
[10:36] jfw: it sounds like the most widely applicable is the first, "RCE via OOM corruption", with no real workaround. the second, "RCE via stale global state", is pickier; the so far documented vectors don't seem to exist at all in the CentOS 6 PHP 5.3.3. in the Gales version there is the session.upload_progress.enabled, default On, so that can be turned off to mitigate.
[10:40] jfw: the offered mitigation for the first, of disabling internal memory limit, is dubious as all hell but who knows, might do some good. or expose other trouble.
[10:46] jfw: I guess I'll shutdown the web server for fixpoint et al, try to get some more sleep (which was interrupted by a different slow-burning crisis), then look into patching for Gales and finishing the site migration earlier than expected.
[20:34] jfw: the situation is quite ugly. it's not just a couple of implementation mistakes, more like an entirely broken model of exception flow control vs. memory management, or multiple of such, sort of sleeping dogs left to lie in the wretched hairball of a codebase since it seemed to work and nobody found a way to prove it exploitable... until somebody or something did.
[20:37] jfw: they took 2 months under wraps developing the fixes and now drop a 20,000-line patch (on the master branch alone) all at once which we're expected to digest & apply yesterday. just trust us this time, after we bit you and left you bleeding for 10 years.
[20:38] jfw: 21 fucking words of explanation in the commit log.
[20:39] jfw: I haven't turned up the actual exploits as yet but might go in that direction, to have some kind of guidance as to what's actually known broken so far to better focus efforts. There's some indication that CentOS 6 might actually be old enough to dodge the bullet.
[20:46] jfw: the simplest thing might be along the lines of, kill the worker process straightaway & unconditionally when memory allocation fails (the server will respawn another), and disable the obscure session upload progress thing
[20:47] jfw: but aftershocks are to be expected as that's not the only possible trigger
Day changed to 2026-10-23
[02:03] jfw: the hype may be somewhat overhyped; now I'm hearing that what's known exploitable and demonstrably so is actually... not much, which is odd given the claims being made like how great the AI help was in powering through those pesky details enough to get the security team's attention. some good news is the backport for 7.4 is much smaller to review, and at least one distro maintainer seems to have
[02:03] jfw: done a 5.6 backport already.
Day changed to 2026-10-24
[05:34] jfw: Today was mostly more research. I've turned up 4+ different 5.6 backport patches by now, none of which are bold enough to name an author, and which overlap but don't fully agree. They probably all derive from upstream's unreleased minimal backport commit for the 7.4 branch.
[05:35] jfw: Fortunately all of these are much smaller than the "complete" fixes for latest branches, so it's looking quite doable to go through each change in that pile, in view of the full 5.6 context, to check that each is correct and nothing's missed.
[05:36] jfw: There still appear to be no working public exploits nor reports of successful exploitation in the wild.
[23:28] jfw: Patch review is proceeding, though I'm breaking out in the PHP hives... they print "possible integer overflow" when there's nothing uncertain about it, they have their own strndup which behaves different from the standard one and can't decide if it's for null-terminated or length-tracking strings, they have a function whose argument count for a format string varies with preprocessor conditions
Day changed to 2026-10-26
[05:03] jfw: I've sifted through the official 7.4 backport patch, cataloging ~32 distinct changes therein (and that was the "minimal" fix), and through one of the unsourced gossip backport patches for 5.6, which leaves some followup questions, now on to the second of those before visiting the one from the Debian PHP maintainer.
[05:04] jfw: much continued lulz in the surrounding PHP code.
[12:26] whaack: morning
[12:26] whaack: are jfxpt.com and dorion-mode.com down for php maintenance?
[12:26] whaack: !e view-height
[12:26] btcexplorer: block_height: 971489
[12:26] btcexplorer: mins_since_last_block: 16435
[16:38] jfw: I'd respond only he can't seem to stay connected even after noticing the web logs are down...
[18:34] jfw: whew, made it through the three unofficial backport patches (there's surely even more floating around by now). each one included some stuff not found in the others.
[18:39] jfw: the candidate change count is up to 36, before any further codebase searching of my own.
[19:28] caai: thank you for sharing details about how you are addressing the php security exploit. good thing it doesn't affect me ..... oh wait .... it does ..... :/
[19:47] jfw: heh. it probably affects a lot of people who have no idea.
[19:59] caai: indeed. but i suspect most of them won't realize what's happening until the entire left-wing is up in flames.
Day changed to 2026-10-27
[05:13] jfw: in the patch review I've determined that the new array_init_singleton function, which was included for 7.4 but only in one of the downstream 5.6 backports, is not necessary for 5.6. arguably it's not necessary for 7.4 either and is only trying to reduce the amplification factor for triggering the OOM condition in request parsing. but in 5.6, the hash table and bucket structures are so bloated to
[05:13] jfw: begin with that the marginal savings of dropping from 8 to 2 initial elements isn't worth the bother.
[05:15] jfw: 7.x completely rewrote the array/hash table implementation from what I gather. evidently not correctly, as we now see.
[05:18] jfw: that clears up one of the biggest glaring gaps between the backports; hopefully the rest can go a little faster now...
[05:21] jfw: deciphering that hash table code was quite a slog, really.
Day changed to 2026-10-28
[04:38] jfw: progress continues slowly, I'm through the closer looks on 10 of the 36. in a new setback for php5, I found quite a find: it is possible for zend_error_noreturn to return under certain conditions, while many callers assume it truly doesn't return, and there is at least one caller that's guaranteed to have it return!
[04:56] jfw: I'm thinking I might change course a little and start pushing out partial patches into testing, to close the biggest holes and get back online before finalizing all the just-one-more-things.
[05:00] jfw: this new return-from-noreturn thing jumped out at me as I was just sitting down to add the new fix code.
Day changed to 2026-10-29
[15:10] dorion: <jfw> 21 fucking words of explanation in the commit log.
[15:11] dorion: ^^ nuts, the entire demented sop.
[15:13] dorion: none of which are bold enough to name an author << but ofc !! lolz.
[15:18] dorion: <jfw> I'm thinking I might change course a little and start pushing out partial patches into testing... << makes sense.
Day changed to 2026-10-30
[20:41] jfw: aaaaand fixpoint is back among the living, in its new home at 62.72.189.10 - finally eating my own cooking, and it's tasting fine. update your hosts files or just follow DNS - it could take up until tomorrow for old caches to refresh.
[20:49] jfw: the wotbot relocation turned up a few buggy error paths due to change of database socket and server IP and whatnot, so I've fixed those too.
[20:49] wotbot: 2026-06-21 01:45 (#jwrd) jfw: despite the channel not getting much use these days, I finished it off now so that it can move to Gales Linux along with the rest of the Fixpoint orchestra.
[20:52] jfw: the behind-the-scenes link archiver make take some more time to bring up in the new environment, but meanwhile its intake queue will keep track of the pending links.
[20:52] jfw: *may take
[20:55] jfw: the core of the PHP vulnerabilities is patched and work will continue on the long train of details.
[18:11] jfw: jfw reporting in OK for now from heavy earthquake in panama city.
[19:21] dorion: it was noticable, but mild here over in el barrio silvestre.
[19:37] jfw: magnitude 7.7 apparently
Day changed to 2026-10-10
[01:04] jfw: I hear it was felt from parts of colombia and costa rica. quite a pile of aftershocks too - http://jfxpt.com/wp-content/uploads/2026/10/azuero-quakes.png
[04:38] jfw: another big one in the same belt, mag 6. shaking wasn't as strong but took its time.
[06:45] caai: not cool
[12:41] dorion: fausto is on the azuero, very close to epicenter, surviving it.
[21:27] jfw: dorion: oh damn. I hope not in that town where "we're trying to figure out how to reach it by air, because the road collapsed and it's unreachable by land"
[21:29] jfw: perhaps now might be the proverbial second best time to hustle on promoting the mesh radios
[21:32] jfw: my own planned next step has been to research more into the wide array of extant hardware choices to find one that retains the upsides of the heltec v3/4 while resolving the poor battery life, and stock up on that
[21:33] jfw: there's probably no one choice that's best for all uses but at least narrow it down
Day changed to 2026-10-14
[14:38] SamyTF: @jfw can you call me plz ?
[14:39] SamyTF: need some info to come over
[14:50] jfw: done.
[20:11] dorion: ftr, fausto turned out ok.
[20:11] jfw: light but prolonged shaking, de nuevo...
[20:17] jfw: and yeah, not quite that town perhaps but close enough, structures leveled & roads turned into staircases, repaired enough to make it home in a few days.
[20:17] wotbot: 2026-10-10 21:27 (#jwrd) jfw: dorion: oh damn. I hope not in that town where "we're trying to figure out how to reach it by air, because the road collapsed and it's unreachable by land"
Day changed to 2026-10-22
[08:54] jfw: in insecurity news, https://www.php.net/archive/2026.php#2026-10-21-5 seems to be making a splash, investigating now.
[10:07] jfw: idk how they think they get away with writing these "advisories" without linking/citing the code and patches under discussion.
[10:19] jfw: plus just posting them on static web & github pages with no comments...
[10:36] jfw: it sounds like the most widely applicable is the first, "RCE via OOM corruption", with no real workaround. the second, "RCE via stale global state", is pickier; the so far documented vectors don't seem to exist at all in the CentOS 6 PHP 5.3.3. in the Gales version there is the session.upload_progress.enabled, default On, so that can be turned off to mitigate.
[10:40] jfw: the offered mitigation for the first, of disabling internal memory limit, is dubious as all hell but who knows, might do some good. or expose other trouble.
[10:46] jfw: I guess I'll shutdown the web server for fixpoint et al, try to get some more sleep (which was interrupted by a different slow-burning crisis), then look into patching for Gales and finishing the site migration earlier than expected.
[20:34] jfw: the situation is quite ugly. it's not just a couple of implementation mistakes, more like an entirely broken model of exception flow control vs. memory management, or multiple of such, sort of sleeping dogs left to lie in the wretched hairball of a codebase since it seemed to work and nobody found a way to prove it exploitable... until somebody or something did.
[20:37] jfw: they took 2 months under wraps developing the fixes and now drop a 20,000-line patch (on the master branch alone) all at once which we're expected to digest & apply yesterday. just trust us this time, after we bit you and left you bleeding for 10 years.
[20:38] jfw: 21 fucking words of explanation in the commit log.
[20:39] jfw: I haven't turned up the actual exploits as yet but might go in that direction, to have some kind of guidance as to what's actually known broken so far to better focus efforts. There's some indication that CentOS 6 might actually be old enough to dodge the bullet.
[20:46] jfw: the simplest thing might be along the lines of, kill the worker process straightaway & unconditionally when memory allocation fails (the server will respawn another), and disable the obscure session upload progress thing
[20:47] jfw: but aftershocks are to be expected as that's not the only possible trigger
Day changed to 2026-10-23
[02:03] jfw: the hype may be somewhat overhyped; now I'm hearing that what's known exploitable and demonstrably so is actually... not much, which is odd given the claims being made like how great the AI help was in powering through those pesky details enough to get the security team's attention. some good news is the backport for 7.4 is much smaller to review, and at least one distro maintainer seems to have
[02:03] jfw: done a 5.6 backport already.
Day changed to 2026-10-24
[05:34] jfw: Today was mostly more research. I've turned up 4+ different 5.6 backport patches by now, none of which are bold enough to name an author, and which overlap but don't fully agree. They probably all derive from upstream's unreleased minimal backport commit for the 7.4 branch.
[05:35] jfw: Fortunately all of these are much smaller than the "complete" fixes for latest branches, so it's looking quite doable to go through each change in that pile, in view of the full 5.6 context, to check that each is correct and nothing's missed.
[05:36] jfw: There still appear to be no working public exploits nor reports of successful exploitation in the wild.
[23:28] jfw: Patch review is proceeding, though I'm breaking out in the PHP hives... they print "possible integer overflow" when there's nothing uncertain about it, they have their own strndup which behaves different from the standard one and can't decide if it's for null-terminated or length-tracking strings, they have a function whose argument count for a format string varies with preprocessor conditions
Day changed to 2026-10-26
[05:03] jfw: I've sifted through the official 7.4 backport patch, cataloging ~32 distinct changes therein (and that was the "minimal" fix), and through one of the unsourced gossip backport patches for 5.6, which leaves some followup questions, now on to the second of those before visiting the one from the Debian PHP maintainer.
[05:04] jfw: much continued lulz in the surrounding PHP code.
[12:26] whaack: morning
[12:26] whaack: are jfxpt.com and dorion-mode.com down for php maintenance?
[12:26] whaack: !e view-height
[12:26] btcexplorer: block_height: 971489
[12:26] btcexplorer: mins_since_last_block: 16435
[16:38] jfw: I'd respond only he can't seem to stay connected even after noticing the web logs are down...
[18:34] jfw: whew, made it through the three unofficial backport patches (there's surely even more floating around by now). each one included some stuff not found in the others.
[18:39] jfw: the candidate change count is up to 36, before any further codebase searching of my own.
[19:28] caai: thank you for sharing details about how you are addressing the php security exploit. good thing it doesn't affect me ..... oh wait .... it does ..... :/
[19:47] jfw: heh. it probably affects a lot of people who have no idea.
[19:59] caai: indeed. but i suspect most of them won't realize what's happening until the entire left-wing is up in flames.
Day changed to 2026-10-27
[05:13] jfw: in the patch review I've determined that the new array_init_singleton function, which was included for 7.4 but only in one of the downstream 5.6 backports, is not necessary for 5.6. arguably it's not necessary for 7.4 either and is only trying to reduce the amplification factor for triggering the OOM condition in request parsing. but in 5.6, the hash table and bucket structures are so bloated to
[05:13] jfw: begin with that the marginal savings of dropping from 8 to 2 initial elements isn't worth the bother.
[05:15] jfw: 7.x completely rewrote the array/hash table implementation from what I gather. evidently not correctly, as we now see.
[05:18] jfw: that clears up one of the biggest glaring gaps between the backports; hopefully the rest can go a little faster now...
[05:21] jfw: deciphering that hash table code was quite a slog, really.
Day changed to 2026-10-28
[04:38] jfw: progress continues slowly, I'm through the closer looks on 10 of the 36. in a new setback for php5, I found quite a find: it is possible for zend_error_noreturn to return under certain conditions, while many callers assume it truly doesn't return, and there is at least one caller that's guaranteed to have it return!
[04:56] jfw: I'm thinking I might change course a little and start pushing out partial patches into testing, to close the biggest holes and get back online before finalizing all the just-one-more-things.
[05:00] jfw: this new return-from-noreturn thing jumped out at me as I was just sitting down to add the new fix code.
Day changed to 2026-10-29
[15:10] dorion: <jfw> 21 fucking words of explanation in the commit log.
[15:11] dorion: ^^ nuts, the entire demented sop.
[15:13] dorion: none of which are bold enough to name an author << but ofc !! lolz.
[15:18] dorion: <jfw> I'm thinking I might change course a little and start pushing out partial patches into testing... << makes sense.
Day changed to 2026-10-30
[20:41] jfw: aaaaand fixpoint is back among the living, in its new home at 62.72.189.10 - finally eating my own cooking, and it's tasting fine. update your hosts files or just follow DNS - it could take up until tomorrow for old caches to refresh.
[20:49] jfw: the wotbot relocation turned up a few buggy error paths due to change of database socket and server IP and whatnot, so I've fixed those too.
[20:49] wotbot: 2026-06-21 01:45 (#jwrd) jfw: despite the channel not getting much use these days, I finished it off now so that it can move to Gales Linux along with the rest of the Fixpoint orchestra.
[20:52] jfw: the behind-the-scenes link archiver make take some more time to bring up in the new environment, but meanwhile its intake queue will keep track of the pending links.
[20:52] jfw: *may take
[20:55] jfw: the core of the PHP vulnerabilities is patched and work will continue on the long train of details.