#1259 moved the interim CVE-2026-109618 mitigation (memory_limit = -1)
out of the shared hardening.ini into memory-unlimited.ini and mounted it
only in the roles whose images it had inventoried. Its branch predates
#1263, which gave FusionDirectory the php_hardening mount, so after both
merged FusionDirectory ran with the image default of 128M again.
A conf.d mount would not have fixed it: the nfrastack image writes
php_admin_value[memory_limit] into its FPM pool
(/etc/php7/pools.d/www/www-settings.conf) from PHP_MEMORY_LIMIT, and a
pool php_admin_value outranks every conf.d ini. Measured on main: CLI
128M, FPM 128M. So even before #1259 the hardening ini only ever lifted
the CLI limit.
nfrastack/fusiondirectory:1.5 runs PHP 7.4.33 on Alpine 3.15, end of
life and never patched, so the role carries the mitigation until it
moves to a PHP 8 image.
- Set PHP_MEMORY_LIMIT=-1 in templates/env.j2. The image seds it into
php.ini and the pool, so CLI and FPM both report -1.
- The root TODO lists FusionDirectory with the image and the reason it
uses the variable instead of the mount; the role TODO names which
setting carries which CVE mitigation.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
FusionDirectory was the one PHP role #1115 left without the shared
hardening ini, so its PHP 7.4 kept session.upload_progress enabled and
a finite memory_limit, the two settings behind CVE-2026-109619 and
CVE-2026-109618.
The nfrastack image runs Alpine's php7 with /etc/php7/conf.d as scan
dir. Its init only links module inis there and chmods/chowns the tree;
php-ext reset, which empties conf.d, runs at build time only. A
read-only config at conf.d/zz-infinito-hardening.ini therefore
survives the init and loads after 99-*.ini, so it wins.
The PHP line itself stays on 7.4: FusionDirectory certifies 1.4 to
1.6 for PHP 7.4 only, nfrastack/container-fusiondirectory builds only
on PHP 7.4 and Alpine 3.15, and the PHP 8 port is upstream's
unreleased php8 branch. TODO.md records that state and the options.
The php_hardening entry sits above data in meta/volumes.yml and the
TODO note replaces only the mounted item, so the pending
feature/store-i18n changes to both files still merge cleanly.
Refs #1120
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Proxy:
- server_tokens off, X-Powered-By stripped from upstream responses,
HSTS max-age raised to one year.
- No global X-Content-Type-Options: under nosniff, ORB (step 3.4)
blocks no-cors cross-origin responses typed text/html, e.g. tracking
beacons answered with an empty 204.
PHP (CVE-2026-109618, CVE-2026-109619):
- New role sys-svc-compose-php installs a shared ini (expose_php Off,
session.upload_progress.enabled 0, fatal_error_backtraces 0 for
PHP 8.5, interim memory_limit -1) and a PHP-FPM [www] drop-in
(pm.max_requests = PHP_FPM_MAX_REQUESTS) once per stack host,
before 04_files renders any compose file.
- The host file names carry a sha1 prefix of the controller-side
source, so a content change alters every PHP app's compose.yml and
recreates it, also on remote deploys where compose_volumes cannot
read the stack host file and hashes the path instead.
- 20 PHP roles mount the ini as a compose/swarm config into their
image's scan dir; moodle, nextcloud and shopware also mount the FPM
drop-in. Magento keeps its own pool: its php-fpm.conf has no
include= and is rendered without notify.
- Joomla's php-upload.ini now loads as zzz-joomla-uploads.ini so its
own memory_limit wins: the media API compares Content-Length with
toBytes(memory_limit) and rejects every upload at -1.
TODOs record the memory_limit revert condition and accepted
trade-offs, Akaunting on PHP 8.1, FusionDirectory on PHP 7.4 and the
public Keycloak admin console.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Remove TODO.md from four roles whose only TODO entry was an
"Implement this role" / "Implement <auth>" item that has long since
been delivered:
- web-app-jenkins ("Implement this role")
- web-app-fusiondirectory ("Implement this role")
- web-app-gitea ("Implement OIDC")
- web-app-shopware ("Implement OIDC", "Implement LDAP")
Each role ships a complete implementation today (tasks/, templates/,
meta/services.yml + variants.yml, OIDC/LDAP setup tasks where
applicable, playwright.spec.js coverage), so the TODO no longer
reflects reality.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
kevinveenbirkenbachandClaude Opus 5.5