deps: cbox-init 3.8.3, fpm-exporter 3.1.2 — the publish pipeline is unblocked

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_<NAME>_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`

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": {