php74

Build times (auto-updated)

any: 10m35s (2026-10-21 15:42 UTC, MAKEFLAGS=-j6)
i686: 29m4s (2026-10-21 16:50 UTC, MAKEFLAGS=-j6)
armv7h: 3h57m (2026-10-22 06:54 UTC, remote, MAKEFLAGS=-j1)
aarch64: 1h12m (2026-10-22 06:54 UTC, remote, MAKEFLAGS=-j1)

Category: adapted (moved from local-install/ 2026-10-21, see below — was previously “rebuilt only so archlinuxaba/the cluster gets it too; not maintained/adapted/owned by us”). Split package (dozens of subpackages: php74-cli, php74-fpm, php74-gd, etc.) generated by the upstream arch-phpbs tool. Needed by php74-apcu and owncloud.

ARM coverage added (2026-10-22)

Added armv7h/aarch64 to arch=() (now ('x86_64' 'i686' 'pentium4' 'armv7h' 'aarch64')), pkgrel 11.2 -> 11.3. Patch is portable: checked the one SIMD-looking hunk in the CVE patch (zend_types.h’s HT_HASH_RESET) and confirmed it’s entirely inside the pre-existing #ifdef __SSE2__ branch – ARM uses the untouched generic fallback at line ~346, so the patch is a no-op there, not a portability risk.

Board-lock collision hit once: launched php74’s ARM build while php85’s was still running on the same two boards (eurobuild5/14) – failed closed exactly as designed (ERROR: eurobuild5 is already building something else), no corruption. Force-killed the blocked php74 attempt (bottom-up SIGTERM through the ssh/oksh chain) to retry sooner rather than wait out php85’s run; had to manually clear both the local .building.lock (trap didn’t fire cleanly under the kill) and eurobuild5’s remote lock (ssh eurobuild5 rm -rf /data/INSTALL/.building.lock) before relaunching – confirms remote_build_lock’s documented no-auto-expire behavior.

New test failure on armv7h only, NOT seen on x86_64/i686/aarch64: Zend/tests/concat_003.phpt (“Concatenating many small strings should not slowdown allocations”) – a hardcoded wall-clock perf test (220,000 string concats must finish in under $t_max = 1.0 seconds). Confirmed by reading the test file directly: pure CPU-speed timing threshold, nothing to do with the CVE patch or correctness – armv7h is just slow enough to blow a 1-second budget tuned for x86 hardware. Not a regression, not patch-related; aarch64 (faster ARM board) didn’t hit it. Only [[php74]]’s existing bug45392 duplicate-error-message cosmetic regression (see CVE section below) was common to all four arches. Per the user: test failures don’t block publishing (matches the existing x86_64/i686 precedent – repo_build.sh’s make test failure doesn’t abort packaging).

CVE-2026-109618 / CVE-2026-109619 backport (2026-10-21)

PHP disclosed and patched two critical (CVSS 9.2) unauthenticated RCE flaws today, nicknamed “php2shell”: memory-exhaustion-triggered state corruption during a bailout (109618) and a related use-after-free of request-owned global state surviving into the next request on the same worker (109619). Root cause is in multipart/file-upload handling (main/rfc1867.c) interacting with Zend’s bailout/cleanup path. Official fixes shipped in PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 same day; the PHP project explicitly will not patch 8.1 or earlier (EOL).

7.4 (our version, 7.4.33) is affected too – confirmed via HeroDevs’ vulnerability directory, which lists 7.4/8.0/8.1 explicitly. Found an actual upstream-authored backport: php/php-src branch PHP-7.4-CVE-2026-109618-109619, a single commit (712e60f, “Avoid state corruption via bailout – Minimal mitigation for EOL version”) by Zend-engine core devs arnaud-lb and iluuu1994, branched exactly off our 7.4.33 base. 17 files, ~240/-59 lines (Zend/zend_alloc.c, zend_vm_execute.h, zend_hash.c, main/rfc1867.c, php_variables.c, SAPI.c, etc.).

Applied as a standalone patch file, php74-cve-2026-109618-109619.patch, added to both source=() and _patches=() (the latter is what actually gets looped over with patch -p1 in prepare() – adding to source=() alone does nothing). Dry-run verified it applies cleanly to a pristine 7.4.33 extraction before wiring it in.
pkgrel 11.1 -> 11.2 (packaging-only deviation, no pkgver change – per the user, upstream AUR will presumably patch this properly eventually, so keep this a local pkgrel bump, not a fork of pkgver).
Category migration, not just a patch: this is now a real local deviation (a patch, not an unmodified upstream copy), so per feedback_local_adaptions_go_in_adapted it no longer belongs in local-install/ – moved to arch/adapted/php74/, removed the local-install/php74 line from scripts/install_only_packages, added an entry to arch/adapted/README. The pre-existing, already-uncommitted working-tree state in /data/INSTALL/php74 (the arch=() and libtiff fixes from the 2026-08-19 session, pkgrel 11.1) was carried forward into this migration, not discarded.
ABI check: the patch’s only zend_types.h change is inside the HT_HASH_RESET macro body (adds a size < 64 branch before the existing SIMD path) – no struct field added/reordered, so _zend_array size/layout is unchanged. Extensions (php74-apcu, php74-redis, php74-igbinary) should remain ABI-compatible without a forced rebuild, though rebuilding them against the patched core eventually wouldn’t hurt.
Known side effect, found via the test suite: tests/lang/bug45392.phpt (“ob_start()/ob_end_clean() and memory_limit”) now FAILS on both x86_64 and i686 (passed pre-patch at 11.1 – confirmed against the old php74-7.4.33-11.1-i686-check.log). Root-caused by hand: built a CLI binary from this exact patched build and ran the test’s script directly with stdout/stderr separated. The actual fatal-error mechanism still works correctly (OOM during ob_start()-buffered output still raises “Allowed memory size of N bytes exhausted” as expected) – but the message is now written to stderr twice (PHP Fatal error: ... then a second, unprefixed Fatal error: ...), where pre-patch it apparently only fired once. Consistent with the patch’s own description (“Replace bailout on OOM with UnwindExit”) – the old abrupt longjmp bailout likely cut execution off before a second reporting call site could run; the new, safer unwind lets both fire. Cosmetic/log-noise only: nothing leaks to the HTTP response body, no crash, no incorrect value – just a duplicated line in the error log for this one OOM+output-buffering interaction. Only failing test out of 3671. Flagged to the user as a known, accepted trade-off rather than something that blocked the build – revisit if it turns out to matter in practice (e.g. doubled alerting/log volume on an app that hits memory_limit under ob_start() a lot).
arch/adapted/php74 is untracked in git as of this writing – per policy Claude never runs git add/git commit itself (feedback_never_git_commit_or_push); the user needs to git add adapted/php74 scripts/install_only_packages adapted/README (and the arch/ submodule pointer update, if any) themselves, or cleanup_all.sh’s git clean -fd on adapted/ will delete it (feedback_adapted_needs_git_add_immediately).

Build notes (2026-08-19)

arch=("$CARCH") doesn’t work with our tooling. Upstream ships a dynamic self-resolving arch=() (an arch-phpbs generator trick, presumably meant for a build wrapper that re-invokes makepkg per target arch). repo_build.sh parses arch=(...) as literal text from the PKGBUILD file (sed -n 's/^arch=($.*$)$/\1/p'), so it read the literal string $CARCH – not a real arch – and would have built nothing. Fixed by replacing it with a real literal array, arch=('x86_64' 'i686' 'pentium4').
Missing dependency: c-client. A hard makedepends (needed for the imap extension) that wasn’t available anywhere – not in official repos, not previously published to archlinuxaba, only on AUR. Built and published it first (see memory/c-client.md).
Missing libtiff makedepend, only surfaced on 32-bit. The gd extension’s configure check failed with Package 'libtiff-4', required by 'gdlib', not found on i686/pentium4 (not x86_64) – archlinux32’s gd build apparently still links against libtiff where the current x86_64 gd doesn’t declare it in gdlib.pc. Fixed by adding libtiff to makedepends explicitly.
pentium4 fails, GD symbols unlinkable. After the libtiff fix, pentium4’s configure got past the gdlib >= 2.1.0 check but then failed to link any basic GD symbol (gdImageCreate etc. all report “no” from the -lgd link test), with configure: error: GD build test failed. i686 (same gd package family) does NOT hit this – pentium4-chroot-specific. Not root-caused further; left pentium4 in arch=() per explicit user instruction (build/publish what works, don’t keep chasing it) – pentium4 will just show FAILED on every rebuild and get skipped, which repo_build.sh tolerates fine as long as other arches succeed.
Self-inflicted stale-publish incident: a leftover, already-built pkgrel=11 artifact set (predating this session, before the arch=()/libtiff fixes bumped pkgrel to 11.1) was still sitting in the pkgdir on the first successful build attempt. Both the correct 11.1 and the stale 11 x86_64 packages got uploaded in the same run, and since repo-add is keyed by pkgname (last write wins, not highest version), the stale 11 ended up live, clobbering the fix. Caught by checking upload order in the log (grep -n "php74-cli-7.4.33-11") after the fact. Fixed with a second clean rebuild (pkgdir was already swept of old artifacts by repo_build.sh’s own untracked-file cleanup by then, so the retry only ever produced 11.1 files). Lesson: always check for and clean stale .pkg.tar.zst artifacts in a package’s dir before the first build of a session, not just when something looks wrong after the fact – a stale artifact can silently outrace a correct one through repo_publish.sh if pkgrel bumps didn’t fully clear the old file first.
pkgrel "11" -> "11.1" (local-install, X.Y scheme; note this PKGBUILD holds pkgrel as a quoted string, not a bare integer – quoting still works fine with the X.Y scheme).
End state: x86_64 and i686 publish cleanly (122 packages each: ~61 subpackages x {package, debug} roughly). pentium4 excluded (in arch=() but always fails, tolerated).