7 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Sonnet 5.5	b5bb46740d	build-push: workflow_dispatch input only to rebuild a single image leg ... Gitea cannot re-run one job and a full run takes ~1h. Add a plan job that turns the optional `only` input (e.g. cac:php85) into one filtered matrix per image family; image jobs take their matrix from it and are skipped when empty. Push events / empty input plan the full set as before. Unknown values fail the plan job. Tests added to multiarch-workflow.test.py. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185ukXjXyosSkunDsdWz3mb	2026-11-12 07:52:13 -08:00
shadowdaoandClaude Sonnet 5.5	01741e735a	ci: publish cac, cac-fpm and shared-httpd multi-arch (amd64 + arm64) ... One job per matrix leg on the trusted x86 runner: amd64 built natively, arm64 under QEMU, each pushed BY DIGEST (untagged), then scripts/assemble-multiarch-index.sh creates the existing tags (:phpNN, :latest for php85 / shared-httpd :latest) from this run's digests. The arm64 step is continue-on-error with its own timeout, so an arm64 failure publishes the usual amd64-only tag and a stale arm64 is never re-attached. Build args, base-image pin, pkg-cache probe, php.net EXPECT_PHP_MIN gate, secrets and the cac-litespeed/cac-lsphp/shared-ols jobs are untouched. No Dockerfile change. Adds scripts/tests/multiarch-workflow.test.py (static wiring + tag-scheme execution) to Shell-Checks, and fixes index-platforms.test.sh line 17 which tripped lsphp-info-probe.test.sh's early-exit-reader scan on trunk. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185ukXjXyosSkunDsdWz3mb	2026-11-12 06:13:02 -08:00
shadowdaoandClaude Sonnet 5.5	8a6a6d7b44	ci: multi-arch-safe php.net guard and emergency workflow (no platform change) ... - scripts/image-label-amd64.sh: index-safe read of the amd64 image's labels (OCI index with attestations, Docker manifest list, single manifest). - scripts/php-emergency-guard.sh: used by both build-push.yaml guard sites; same decisions as the old inline step on single-platform images, but FAILS CLOSED when the labels cannot be read (only "tag not found" passes). - lsphp-source-emergency.yaml: push by digest + assemble (copy of HMB assemble-multiarch-index.sh); optional arm64; refuses to replace a multi-arch production tag with amd64-only unless allow_amd64_only. - Tests wired into Shell-Checks; main build matrix platforms unchanged. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185ukXjXyosSkunDsdWz3mb	2026-11-11 17:22:24 -08:00
shadowdaoandClaude Sonnet 5.5	ad66667053	build: arch-aware mariadb.repo and lsphp index lookup (amd64 unchanged) ... - Dockerfile, Dockerfile.fpm: select rhel$releasever-<amd64|aarch64> from uname -m (amd64 file is byte-identical; $basearch cannot be used, x86_64 path 404s). - scripts/lsphp-repo-version.sh replaces three inline binary-amd64 lookups (build-push.yaml x2, lsphp-source-emergency.yaml); arch defaults to amd64. - fixture test wired into Shell-Checks. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185ukXjXyosSkunDsdWz3mb	2026-11-11 17:01:34 -08:00
shadowdaoandClaude Opus 5.5	83c2ee9c2a	feat(lsphp): emergency build path compiling lsphp from php.net source ... For when a PHP security release is out and the LiteSpeed apt repo lags (2026-10-21: php2shell CVE-2026-109618/-109619 fixed in 8.2.35/8.3.36/ 8.4.27/8.5.12, LiteSpeed still on 8.2.34/8.3.35/8.4.26/8.5.11). Dockerfile.lsphp / Dockerfile.litespeed gain an `lsphp-src` stage that is idle unless PHP_SRC_VERSION is set; normal builds are unchanged (measured: module list, file manifest, ldd, ini and dpkg identical to the published images). When set (lsphp-src-build.sh): - tarball sha256 (php.net releases JSON) + OpenPGP signature against the committed php.net keyring, signer pinned per branch - configure flags replayed from the packaged lsphp's own Configure Command - LiteSpeed's php-litespeed-8.3 SAPI (what the packages actually compile, measured) instead of php-src's sapi/litespeed; sha256-pinned and checked against the packaged binary's LSAPI_* names - packaged compiled-in ini defaults reproduced (session.save_path on 8.2/ 8.3) and gated (`php -n` diff) - ABI gate (lsphp-abi-gate.sh, pahole) before reusing LiteSpeed's packaged PECL .so files; regression-tested in Shell-Checks lsphp-src-overlay.sh swaps only php-src-owned files (decided by dpkg) and fails the build unless extensions, versions, effective ini and feature lines match the packaged lsphp under both CLI and litespeed SAPIs. CI: lsphp-source-emergency.yaml (workflow_dispatch only). build-push.yaml refuses to overwrite a newer php.net image with an older packaged one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 09:46:22 -07:00
shadowdaoandClaude Opus 5	e28c3dcce4	fix(lsphp): correct the SIGPIPE explanation, drop the temp-dir boot precondition, close two scanner blind spots ... Three non-blocking findings from the review of 8790b02. The fix itself is unchanged in intent; this makes the reasoning around it true, removes a regression the fix introduced on the boot path, and stops the new test from under-reporting. F1 — the shipped comments explained the bug wrongly, and a wrong rule is what the next maintainer reasons from. entrypoint-lsphp.sh and render-shared-ols-config.sh both said the race is decided by PIPE CAPACITY: "while the output fits the pipe the writer always wins; once it doesn't, SIGPIPE is guaranteed." Both halves are refuted by measurement against a default 65536-byte pipe (F_GETPIPE_SZ): 41144 bytes -> 141 in 32/300 runs (11%) — well UNDER capacity 65012 bytes -> 141 in 25/30 runs — not certain even AT capacity 500 KB into a 1 MiB pipe -> 200/200 with 4096-byte writes, 0/200 with one 500 KB write and strace caught printf dying having written 12086 of 40406 bytes into a 65536-byte pipe. The mechanism is a race on whether the reader closes before the writer's final write() returns; capacity only modulates how many syscalls the writer needs. What actually separated whp02 (5/5 failures) from a dev container (10/10 clean) is the WRITER's syscall size: bash <= 5.2.15 writes ~37 KB at a time, bash >= 5.2.21 writes 80-160 bytes. The fs.pipe-user-pages-soft aside was also wrong: it clamps to two pages not one, needs one uid holding >1024 pipes, and is skipped for CAP_SYS_RESOURCE. Both blocks now state the rule that is actually true — any `writer | early-exiting-reader` under pipefail is a latent 141; payload size is not a safety argument; the only sound reasons a call site is safe are structural (no pipefail, reader provably reads to EOF, or the status is discarded) — and the same correction is applied to the three other comments that leaned on size (`ols_running` x2, fpm-parity-check.sh's pre-flight). Nor is the reader's implementation a defence: at 248 KB, mawk, gawk, `grep -q` and `head -1` all gave 141 on 10/10, and these images already differ (mawk 1.3.4 vs gawk 5.2.1). Comment-only; the test file's own section-4 output no longer contradicts the prose next to it. F2 — `<<<` added a writable-temp-dir precondition to the boot path. Above a build-dependent size bash materialises a here-string as /tmp/sh-thd.XXXXXX (measured switch: 65536 in this image's bash 5.2.21, and Debian's 5.2.15 switches between 4096 and 16384, where a ~40 KB `lsphp -i` WOULD spill). On a bare assignment a temp file it cannot create is `set -e` killing PID 1 — the exact failure this branch exists to remove, re-acquired from a different direction and gated on which bash the base image ships. In cac-lsphp:f1f2f3 under `docker run --read-only`, same payload, same statement shape: OLD (here-string) : bash: cannot create temp file for here-document -> exit 1, script dead NEW (pure bash) : REACHED NEXT STATEMENT, SCAN=[…/mods-available/], exit 0 So the boot-critical sites — the three probe helpers in entrypoint-lsphp.sh and the SCAN_DIR extraction in entrypoint-litespeed.sh — now match with `[[ ]]` and parameter expansion, which allocate nothing. The non-boot sites keep their here-strings and say why at the call site: `ols_running` in both OLS entrypoints (`lswsctrl status` is under 100 bytes, orders below any spill threshold) and fpm-parity-check.sh's `php-fpm -m` pre-flight (~1 KB, in a harness that has already written a docroot and a pool config). Matching semantics are preserved, not approximated: the anchored whole-line grep becomes a glob over a subject wrapped in newlines at BOTH ends (so first and unterminated-last lines still match), and awk's `-F'=> ' {print $2; exit}` becomes first-matching-line then the text between the FIRST and SECOND separator. Section 6 of the test asserts that against the original grep/awk patterns reading a FILE — 24 cases incl. trailing-space, prefix decoys, CRLF, a second separator, an empty value, two candidate lines, glob metacharacters in the body, and the full 40 KB fixture. Mutations verify the assertions bite: dropping the trailing-newline wrap fails 3 cases, taking the whole rest of the line fails "second separator", `##` instead of `#` fails "first of two wins", dropping the `^` anchor on the banner fails "banner not at line start". F3 — the structural scan missed shapes it implied it caught, and the extractor was unbounded. * `grep -l`/`-L`/`--quiet`/`--files-with-matches`, `-im1`-style clusters, a bare `head` before `;`, and `sed q` / `sed 'q'` / `sed 2q` / `sed '$q'` were all invisible. grep is now walked option by option the way grep reads them (so `grep -eq foo` stays the pattern "q", not --quiet), and the sed test reads the script with quote characters stripped but their contents kept. Replaying the old regexes against the new fixtures: 10 shapes missed and 2 false positives (`sed s/a/q/`, `grep -eq foo`) — both now correct. * new section 7 pins that coverage from both sides: 19 early-exit shapes must be reported, 18 read-to-EOF / quoted / non-pipeline forms must not. Without it the scan's regexes are unfalsified and can quietly stop matching, which is precisely how `grep -l` and `sed q` stayed missing. * the helper extraction is bounded. It buffers and emits nothing until it has seen the END marker (exit 4 = BEGIN without END, exit 3 = no markers), so a half-deleted pair is a marker error instead of a slurp. Measured on this entrypoint with the END marker removed: the old extractor produced 301 lines including `mkdir -p "$SCAN_DIR"` and three `rm -f "$SCAN_DIR/…"` — which the harness then sourced and ran. It failed loudly last time only because `set -u` happened to trip two statements in. The new one emits 0 bytes and says what is wrong. * the stated scope limits now include what remains: the reader list is an enumeration, not a proof (nothing knows about `perl -ne … last`, `jq`, `head -c`), and only the first word after a pipe is inspected. Verified: PHP 8.3 `--no-cache` build exit 0, 10/10 .phpt; cac-lsphp boots and logs `path parity = extension` with `Rewriting => active` and .from/.to populated from the rendered ini; cac-litespeed boots, resolves SCAN_DIR and writes 99-user-error-log.ini, OLS reports "running with PID", /healthz 200. The FPM parity harness — never executed by the previous review because no cac-fpm image existed locally — was built (Dockerfile.fpm, PHPVER=83), the extension compiled inside it, and it reports 9/9 ALL PASS, exit 0. The new test exits 0 here and exits 1 against a `git archive 9343a56` export naming all 9 offending lines. `bash -n` clean repo-wide; `shellcheck -S warning` clean on the CI set; `-S style` is byte-identical to before this commit (5 pre-existing info-level findings, 0 added — the earlier report's claim of `-S style` clean was wrong). No `.c`/`.h` file touched and the C fail-open invariant grep is still empty. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 16:03:08 -07:00
shadowdaoandClaude Opus 5	8790b027a9	fix(lsphp): stop SIGPIPE+pipefail reporting the parity extension as missing ... `entrypoint-lsphp.sh` decided whether cac_path_parity was loaded with printf '%s\n' "$LSPHP_INFO" | grep -q '^cac_path_parity support => enabled$' under `set -euo pipefail`. `grep -q` exits on its first match; printf is still writing the remaining ~40 KB of `lsphp -i`, takes SIGPIPE, exits 141, and pipefail prefers 141 over grep's 0. The branch therefore evaluated FALSE *because the extension was present* — present early enough to stop the reader — and every affected container fell back to the auto_prepend normaliser that a customer's own .user.ini silently displaces, i.e. the exact failure the extension exists to remove. Measured on whp02 against the published cac-lsphp:php83: 5/5 runs status=141 with pipefail, 0 without. The race is decided by pipe capacity, which is why it reproduced on whp02 and not on other daemons: while the payload fits the pipe the writer never blocks and always finishes first. Forced over the limit it is deterministic — 3x the same `lsphp -i` (122100 bytes) gives 141 every time in the built image. Fixed by reading with here-strings, which are not pipelines at all, so there is no second exit status for pipefail to adopt. Same grep/awk patterns; plumbing only. Same class fixed everywhere it existed under pipefail: * entrypoint-lsphp.sh parity probe, and the SCAN_DIR awk probe * entrypoint-litespeed.sh SCAN_DIR probe (a bare assignment: 141 there does not degrade, `set -e` kills PID 1), and ols_running * entrypoint-shared-ols.sh ols_running * render-shared-ols-config.sh site.meta parsing (`sed | head -1`): measured 141 at 6000 duplicate keys, which under `set -e` aborts the whole render * fpm-parity-check.sh the `php-fpm -m` pre-flight, whose whole job is to stop a harness fault being blamed on the extension Also: the fallback used to announce "cac_path_parity extension not loadable in this image" for every reason the branch was reached, including its own plumbing breaking — a false diagnosis that sends operators to rebuild a good image whose build gate passed. Verdicts now carry the evidence they rest on, and a probe that produced nothing is reported as a probe failure that establishes nothing about the image. Fail-open posture is unchanged: no probe failure is fatal. Adds scripts/tests/lsphp-info-probe.test.sh, which runs the shipped probes (extracted verbatim, so they cannot drift from what runs in production) under `set -euo pipefail` against a realistic ~40 KB phpinfo body, and statically outlaws the shape repo-wide. Against trunk it fails, naming all 9 offending lines. Wired into CI as a new Shell-Checks job, because no existing gate ever executed the entrypoint's branch logic — the .phpt suite and the Dockerfile's own `lsphp -i | grep -q` probe (which has no pipefail) were both green for the release whose entrypoint declared that same extension missing. Verified: PHP 8.3 --no-cache build green, 10/10 .phpt, 9/9 FPM harness; the built image logs `path parity = extension` and reports `Rewriting => active` with .from/.to populated; ext-removed and probe-broken variants each produce their own honest message and still start. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 15:23:56 -07:00