mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 5.5
e3d2a24bcd
The interim CVE-2026-109618 mitigation lived in the shared hardening.ini, so every PHP role ran without a memory limit until the last image was patched, and no role's service_memory_mb share applied. Registry metadata of the images pinned on main shows that 16 of the 20 consumers already ship PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or the Alpine/Debian build of it). Four predate the fix: markoshust/magento-php:8.4-fpm (8.4.21), ghcr.io/heviat/webmail:2024.06 (the Mailu OIDC flavor, built 2025-04-04), phpldapadmin/phpldapadmin:2.3.11 (built 2026-05-15) and ghcr.io/shopware/docker-base:8.3 (8.3.25). - Move memory_limit = -1 into its own content-addressed ini (FILE_PHP_MEMORY_UNLIMITED_INI) and mount it only in magento, mailu, phpldapadmin and shopware. - hardening.ini keeps expose_php, session.upload_progress.enabled and fatal_error_backtraces as permanent hardening. - Joomla's php-upload.ini loads as conf.d/uploads.ini again: no -1 has to be outranked anymore. - The root TODO names the four images that still need the override. Refs #1126 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
24 lines
529 B
YAML
24 lines
529 B
YAML
---
|
|
data:
|
|
type: volume
|
|
name: joomla_data
|
|
mounts:
|
|
- service: joomla
|
|
target: /var/www/html
|
|
|
|
php_upload:
|
|
type: config
|
|
source: "{{ [lookup('container', 'web-app-joomla', 'directories.instance'), 'php-upload.ini'] | path_join }}"
|
|
mode: "0444"
|
|
mounts:
|
|
- service: joomla
|
|
target: /usr/local/etc/php/conf.d/uploads.ini
|
|
|
|
php_hardening:
|
|
type: config
|
|
source: "{{ FILE_PHP_HARDENING_INI }}"
|
|
mode: "0444"
|
|
mounts:
|
|
- service: joomla
|
|
target: /usr/local/etc/php/conf.d/zz-infinito-hardening.ini
|