From 0bf24a00ba566f84d2b7fc21429ca8875b9838ae Mon Sep 17 00:00:00 2001 From: Sylvester Damgaard Date: Tue, 20 Oct 2026 18:05:33 +0200 Subject: [PATCH] deps: cbox-init 3.8.3, fpm-exporter 3.1.2 - the publish pipeline is unblocked No php-base, php-fpm, php-cli or php-fpm-nginx tag has been promoted since 2026-10-08. The Trivy pre-promotion gate was failing on every run on main, and by design that moves no tags - so the published images kept their old digests while main moved on. That is why the published php-fpm still carried cbox-init 3.7.1 twelve days after 3.8.2 was pinned here, and why today's seven bug fixes could not reach anybody. The Debian layer scanned clean the whole time. The gate failed on the two Go binaries this image COPYs in: cbox-init stdlib 1.26.8, x/net v0.58.0 4 HIGH findings fpm-exporter stdlib 1.26.7 3 HIGH findings CVE-2026-78667 net/http: DoS via crafted HTTP Range headers CVE-2026-78669 DoS via excessive HTTP/2 SETTINGS frames (in stdlib AND in x/net's http2) CVE-2026-97031 crypto/tls: DoS via ECH outer extension references Both tools were rebuilt upstream on Go 1.26.10, cbox-init also on x/net v0.60.0, and re-released. The CVEs are gone from the artifacts rather than added to the .trivyignore baseline - that was the other option and the wrong one. Verified on the published binaries before pinning them: go version -m reports go1.26.10 (and x/net v0.60.0 for cbox-init), the release checksums verify, both download scripts accept the new pins, and a gate-equivalent Trivy scan reports 0 findings on each gobinary. No behaviour change in either tool. --- CHANGELOG.md | 1 + versions.json | 8 ++++---- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index ca2b6d4..273e7ee 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,6 +5,7 @@ All notable changes to Cbox PHP Base Images. ## [Unreleased] ### Fixed +- **cbox-init 3.8.3 and fpm-exporter 3.1.2: the image publish pipeline is unblocked** - no php-base, php-fpm, php-cli or php-fpm-nginx tag had been promoted since 2026-10-08. The Trivy pre-promotion gate was failing on every run on `main`, and by design that moves no tags: the published images kept their old digests while `main` moved on, which is why the published php-fpm still carried cbox-init 3.7.1 twelve days after 3.8.2 was pinned here. The Debian layer scanned clean the whole time; the gate failed on the two Go binaries this image COPYs in. `cbox-init` carried Go stdlib 1.26.8 and `golang.org/x/net` v0.58.0, `fpm-exporter` carried stdlib 1.26.7, and between them they tripped CVE-2026-78667 (net/http DoS via crafted Range headers), CVE-2026-78669 (DoS via excessive HTTP/2 SETTINGS frames, present in both stdlib and x/net) and CVE-2026-97031 (crypto/tls DoS via ECH outer extension references) - all HIGH, all denial-of-service, and not theoretical for binaries that serve metrics on :9090/:9114 and a readiness endpoint on :9091. Both tools were rebuilt upstream on Go 1.26.10 (cbox-init also on x/net v0.60.0) and re-released; the three CVEs are gone from the artifacts rather than added to the `.trivyignore` baseline, which was the other option and the wrong one. Verified on the published binaries before pinning them: `go version -m` reports go1.26.10 and x/net v0.60.0, the checksums match, and a gate-equivalent Trivy scan reports 0 findings on each gobinary. No behaviour change in either tool - **`PUID`/`PGID` were accepted and silently ignored on every image except php-fpm-nginx** ([#44](https://github.com/cboxdk/php-baseimages/issues/44)) - the docs present them as a property of these images ("the most common Docker problem"), but only php-fpm-nginx remapped anything. On `php-fpm`, `php-cli` and `nginx` the variables were read by nothing, so `www-data` kept uid 33 and every file the container wrote into a bind mount came out owned by somebody the host user could not edit - the exact problem the variables exist to solve. php-cli stung most: it is the image people mount a project into for `composer install` and `artisan`, and every artefact it produced was uid 33. The cause was duplication - php-fpm-nginx carried a private superset of the mapping function while `entrypoint-lib.sh` shipped a weaker copy that nothing called. There is one implementation now, in the library, and all four entrypoints call it. In the standalone `nginx` image the user remapped is `nginx` (uid 101), because that is who its workers run as, and its startup chowns follow it instead of targeting `www-data` - a user nginx does not run as. Rootless images still skip the mapping (the container is already the app user), a non-root container still warns instead of failing, and a non-numeric value now names the variable it came from (`PUID must be a number (got 'bob')`) instead of a bare "Value must be numeric" - **Queue workers, the scheduler, Horizon and Reverb ran as root even when `PUID`/`PGID` mapped the app user** ([#34](https://github.com/cboxdk/php-baseimages/issues/34)) - php-fpm and nginx ran as the mapped `www-data`, every Cbox Init app process stayed root. Each cache file, compiled view, log line and git object a job wrote came out root-owned, and the php-fpm workers could not write there afterwards. cbox-init has supported `user:` on a process all along; the shipped `cbox-init.yaml` just never set it. The app processes now carry `user: ${CBOX_APP_USER:-}`, which the entrypoint resolves to `$APP_USER` (`www-data`) when the container starts as root. It resolves deliberately to EMPTY when the container cannot drop privileges at all - the rootless images, `--user 1000:1000`, OpenShift's arbitrary UID - because cbox-init fails a process closed when it cannot setuid, and "the workers run as the wrong user" is a far smaller problem than "the workers do not run"; there the container's own user already *is* the app user. `CBOX_INIT_PROCESS__USER` still wins over both. Fixed in php-cli as well - **`WORKDIR` moved everything except the processes** ([#35](https://github.com/cboxdk/php-baseimages/issues/35)) - `working_dir` was hardcoded to `/var/www/html` in `cbox-init.yaml`, so on a release-based layout (`WORKDIR=/app/current`, the Envoyer/Forge/Deployer shape) the entrypoint, php-fpm and nginx used the real path while every worker crash-looped on `Could not open input file: artisan`. Each app process now starts in `${WORKDIR:-/var/www/html}`, as does the Laravel log tail in the php-fpm process, and php-cli's startup chown follows `WORKDIR` instead of always chowning `/var/www/html` diff --git a/versions.json b/versions.json index a9c5fa4..e167e9b 100644 --- a/versions.json +++ b/versions.json @@ -64,13 +64,13 @@ }, "tools": { "composer": "2", - "cbox_init": "3.8.2", + "cbox_init": "3.8.3", "bun": "1.3.14", "ngx_brotli": "a71f9312c2deb28875acc7bacfdd5695a111aa53", - "fpm_exporter": "3.1.1", + "fpm_exporter": "3.1.2", "fpm_exporter_sha256": { - "linux-amd64": "570d2b3d3284179c47acff8efd8f73ea650e42a2c6bd08c0a8e95cb4b0e3ca98", - "linux-arm64": "d9773dfef3f6efbbbea0fe8be40ea79652d71ea24b20bfe89690ab026e205442" + "linux-amd64": "69b78e1ffbb6f1e9bc31b84a257d0379f1c58b039d6bcb9c3473e9c225237940", + "linux-arm64": "b6e53628030d63bd5503faa7f8227de7fc1762f3b13b81fbad7879f4c9738b9d" } }, "deprecation_policy": {