mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 02:54:26 +00:00
kevinveenbirkenbachandClaude Opus 5.5
46fe011796
#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>
111 lines
8.9 KiB
Markdown
111 lines
8.9 KiB
Markdown
# Todos
|
||
|
||
- Implement multi language
|
||
- Implement rbac administration interface
|
||
- Enable IP6 for docker.
|
||
- backup docker to local für ca optimieren
|
||
- Drop the `php_memory_unlimited` mount ([memory-unlimited.ini](roles/sys-svc-compose-php/files/memory-unlimited.ini), `memory_limit = -1`) from each role whose image ships PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, and the file, its install task and `FILE_PHP_MEMORY_UNLIMITED_INI` once no role mounts it. It is the interim mitigation for CVE-2026-109618 and overrides the per-role `service_memory_mb` share, so a single request can exhaust the container instead of hitting a PHP limit. Still mounted by `web-app-magento` (`markoshust/magento-php:8.4-fpm`, PHP 8.4.21), `web-app-mailu` (`ghcr.io/heviat/webmail:2024.06`, the OIDC flavor, built 2025-04-04), `web-app-phpldapadmin` (`phpldapadmin/phpldapadmin:2.3.11`, built 2026-05-15) and `web-app-shopware` (`ghcr.io/shopware/docker-base:8.3`, PHP 8.3.25). `web-app-fusiondirectory` (`nfrastack/fusiondirectory:1.5`, PHP 7.4.33 on Alpine 3.15, end of life and never patched) carries it as `PHP_MEMORY_LIMIT=-1` in `templates/env.j2` instead (the image's pool sets `php_admin_value[memory_limit]` from it, so a conf.d ini cannot reach FPM) and drops it under the same rule. `web-app-magento` keeps the 756M its `nginx.conf.sample` (`PHP_VALUE`) and `pub/.user.ini` set and keeps `post_max_size` below a quarter of that limit.
|
||
- Fork [rpardini/docker-registry-proxy](https://github.com/rpardini/docker-registry-proxy) and teach the bundled nginx to handle GCP Artifact Registry redirect URLs (`/artifacts-downloads/namespaces/<ns>/repositories/<repo>/downloads/<token>`). Currently `gcr.io` blob pulls are bypassed via `NO_PROXY=…,gcr.io,storage.googleapis.com,googleusercontent.com` in [compose/registry-cache/proxy.conf](compose/registry-cache/proxy.conf), which is a workaround that disables caching for those registries. Long-term: rebase upstream's `proxy.conf` / `sub_filter` rules to recognise the new redirect shape, ship the fix in our fork, point `compose/registry-cache/Dockerfile` (or its image tag) at the fork, and drop the `NO_PROXY` bypass.
|
||
|
||
## Testing
|
||
|
||
- re-run with different credentials/configuration
|
||
- run over all distros for each app
|
||
- msg: can not use content with a dir as dest for NGINX multi distro
|
||
- split service database to postgres and mariadb
|
||
|
||
## Onion e2e (feature/svc-net-tor) — remaining failures
|
||
|
||
Status after deploy-matrix run 29657147883 (commit 407b8a8a1). Every fixable
|
||
failure class from that run is committed (hlth-csp onion-sibling skip,
|
||
onion-aware Playwright request timeouts + lint guard, joomla server-side OIDC
|
||
reachability). The items below are the ones that are NOT fixed yet. Runs
|
||
31756400129 and 31756560361 have since moved several of them; entries corrected
|
||
against those runs say so inline.
|
||
|
||
- **https on the onion IdP — investigated and REJECTED, do not re-derive.** OIDC
|
||
Discovery / RFC 8414 want an https issuer, and an onion-exclusive Keycloak has
|
||
none, so strict client libraries refuse it. Serving TLS on the onion is blocked
|
||
on four independent things, in this order: (1) `roles/svc-net-tor/templates/torrc.j2`
|
||
publishes only `HiddenServicePort 80`, and no role declares 443 in
|
||
`ports.public`/`ports.local`, so `lookup('tor_ports')` can never emit it —
|
||
flipping TLS on first makes Keycloak unreachable over Tor entirely, because
|
||
`nginx_ssl_header.j2` is one if/else and port 80 disappears; (2)
|
||
`roles/sys-front-tls-selfsigned/tasks/00_core.yml` writes an unguarded CN, which
|
||
overflows X.509's 64-byte cap on a 62-char v3 onion — `group_vars/all/02_tls.yml`
|
||
already guards exactly this for the root CA and nowhere else; (3)
|
||
`nginx_ssl_header.j2` emits HSTS in the same branch, and browsers offer no
|
||
click-through on an HSTS host with an untrusted chain, so a self-signed interim
|
||
locks real users out while staying invisible to Playwright's
|
||
`ignoreHTTPSErrors`; (4) it fixes zero libcurl consumers, because RFC 7686
|
||
refusal happens at name resolution and is scheme-independent. Unblocking needs a
|
||
CA that issues for v3 `.onion` (HARICA, CA/B Forum ballot 144) — procurement,
|
||
not code. Until then the per-consumer fixes stand: SOCKS proxy for libcurl
|
||
clients. peertube is no longer among them - it is a clearnet-only role.
|
||
|
||
- **dual-family providers** — the one real remaining design gap. On a CI onion
|
||
node, tor-enabled providers (e.g. mastodon) are onion-exclusive: their domain
|
||
list contains only the `.onion` canonical, no clearnet sibling. The
|
||
family-alignment resolver (`utils/tls_common.py:align_domain_to_consumer`,
|
||
wired into `plugins/lookup/tls.py`) correctly bails in that case, so a
|
||
clearnet-pinned consumer still receives an onion URL it can neither resolve
|
||
nor reach. First hard evidence: `web-app-fediwall` variant 2 (tor=false)
|
||
renders `microblog.<onion>` into `wall-config.json.servers`; the clearnet
|
||
browser (no SOCKS) times out waiting for mastodon wall items
|
||
(`test-walls-surface-posts.js:24`, deterministic across retries). The same
|
||
class is expected to keep `web-app-bigbluebutton`, `web-app-nextcloud`,
|
||
`web-app-opentalk` and `web-app-jitsi` red (clearnet-pinned apps whose peer
|
||
refs — OIDC/cdn/matomo/logout — resolve onion-primary). Fix direction:
|
||
providers must publish BOTH families (clearnet sibling alongside the onion
|
||
canonical) so the resolver has something to align to; includes re-applying
|
||
the deferred `KC_HOSTNAME` onion-gate for Keycloak that was dropped from the
|
||
earlier bundle because it is only needed once dual-family exists.
|
||
- **joomla local-login fallback spec** — `test-oidc-fallback.js:52` (the
|
||
`?fallback=local` emergency hatch: local Joomla admin form login must reach
|
||
the control panel). Root cause UNCONFIRMED. It is independent of the fixed
|
||
OIDC-login spec: the fallback path short-circuits before the plugin's
|
||
server-side discovery, so the committed `extra_hosts` fix does not cover it.
|
||
The `secure => true` sticky-cookie hypothesis was rejected (`.onion` is a
|
||
potentially-trustworthy origin and the e2e Firefox sets
|
||
`dom.securecontext.allowlist_onions`, so Secure cookies are accepted over
|
||
plain-http onion). Next step when it fails again post-fix: isolate the
|
||
post-submit URL — Keycloak redirect (cookie lost) vs. form reject vs. slow
|
||
control-panel render.
|
||
- **matomo container health flake (checkmk batch)** — in the checkmk job the
|
||
4th deploy play failed at `Wait for Matomo container to be healthy` with
|
||
`container inspect: map has no entry for key "State"` for the whole retry
|
||
window (container started, then vanished — likely crash + prune). Plays 1–3
|
||
in the SAME job deployed matomo healthy, so classified transient
|
||
(resource/prune pressure after ~3h). No code fix derivable. If it recurs,
|
||
investigate as a real matomo crash/OOM (container logs, mem_limit).
|
||
- **server-side OIDC reachability candidates** — joomla failed because its app
|
||
container performs server-side OIDC discovery against `http://auth.<onion>`
|
||
without an `extra_hosts` mapping. Roles with the same mechanic and no
|
||
`container_extra_hosts` lookup yet (fix is the same one-line lookup,
|
||
apply on CI evidence): wordpress (daggerhart plugin) and mediawiki
|
||
(PluggableAuth) are structurally identical PHP in-app plugins (high
|
||
likelihood); discourse is now confirmed and pinned (run 33445831564, job
|
||
Nextcloud#7); jenkins, jira, confluence, odoo, openwebui,
|
||
pretix, zammad, semaphore, jellyfin, listmonk, xwiki, mastodon consume the
|
||
issuer server-side too (unverified network path). oauth2-proxy-based apps
|
||
are NOT affected (proven green: prometheus admin SSO). Two names have left
|
||
this list on evidence: mobilizon got the lookup in 0e39f3fad after its
|
||
code-to-token call raised OAuth2.Error Connection refused twenty-four times,
|
||
and gitlab was NEVER a member - run 31756560361 shows it resolving and
|
||
connecting (peeraddr=172.30.0.10:443); its failure was the openid_connect gem
|
||
rebuilding the discovery URL over https regardless of the issuer scheme,
|
||
fixed in 2389b6e38.
|
||
- **baseline exclusions** — `web-app-fider` and `web-app-bookwyrm` (also
|
||
keycloak-job, n8n) were red before the tor branch and stay out of scope for
|
||
it; bookwyrm fails its oauth2 trusted-header session spec, fider its
|
||
baseline. Fix separately from the onion work. espocrm has left this list: its
|
||
onion variant failed in the shared admin persona (fixed in b97cf8888) and its
|
||
clearnet variant returns HTTP 500 on GET /api/v1/App/user, cause still open.
|
||
- **test-development environment jobs** — all 5 distro jobs
|
||
(arch, debian, ubuntu, fedora, centos) hit the 4h30m cap under congestion
|
||
while still progressing (playwright image pull). Environmental, no code fix -
|
||
distinct from the distro sweep's own budget, which did have one: 508669809
|
||
books a budget SIGKILL as skipped, which ad9222630 had only done for SIGTERM;
|
||
note that onion e2e inherently lengthens the routine (×5 onion timeouts,
|
||
circuit waits), so under congestion these jobs are the first to hit the cap.
|