Repository navigation
Switch apache debian image to hardened image #412
Description
I guess that now that docker is doing hardened images, we could switch the main debian image to be hardened as the alpine one has minimal cves normally.
See https://hub.docker.com/hardened-images/catalog/dhi/httpd/guides
We might need some basic changes:
- decouple the runtime image from the "build" image
- the hardened image already run with the
www-datauser, using port 8080 - we need to pull from
docker-image://dhi.io/httpd:${httpd-version}and docker-image://dhi.io/httpd:${httpd-version}
Activity
fzipi commentedon Aug 18, 2026
Parking #420 on one question that no amount of CI fixing will answer: the hardened image has no i386 build.
That is the failing job on #420 —
build (apache-debian-latest, linux/i386)ends inno match for platform in manifest: not found. The other red jobs in that run were fail-fast cancellations, and the manifest itself was readable, so the registry credentials are fine. Switching means the apache-debian images stop shippinglinux/386.What the switch buys, scanned with the same flags as the gate in #459:
httpd:2.4.68dhi.io/httpd:2.4.68Two thirds fewer, and nothing left that a rebuild could fix. It would make apache-debian the cleanest image we publish.
So the question is whether anyone runs the i386 images. I could not find that out from the registries: Docker Hub's public API reports pull counts per repository (6.37M overall) but not per architecture, and the GHCR package API needs a token with
read:packages, which mine does not have. The tags do carry the arch — every currentapachetag listsamd64, arm64, 386— so we are publishing it, we just cannot see whether it is being pulled.If you depend on the
linux/386apache images, please say so here. Without that signal the options are:docker.io/httpdand keep all platforms@fzipi if you can get me a token with
read:packages, or read the pull-by-tag numbers from the Docker Hub account, that would settle it with data rather than silence.fzipi commentedon Aug 18, 2026
Following up with what data exists, since silence should not be the only input.
GHCR is a dead end. The package versions API returns
id,name,url,created_at,updated_atandmetadata— no download or pull count for container packages. Theread:packagesscope would not have produced numbers, so that request is withdrawn.Docker Hub does expose something useful, though not counts: its public tags API reports
last_pulledper architecture. Across 253 published tags that include a 386 image:Reproducible with:
Reading it honestly: for about four fifths of tags the 386 manifest was last fetched within minutes of another architecture, which is what a scanner or mirror walking the whole manifest list looks like, not a user choosing a platform. The remaining fifth — 23 apache tags — shows the 386 image pulled on its own, hours away from the others, so something out there does fetch 386 specifically.
What the data cannot say is how much.
last_pulledis one timestamp per manifest, so a single curious pull and a fleet of production nodes look identical, and a bot pulling only 386 looks like a user.So this stays a judgement call, with the shape of it now clear: an unknown but non-zero number of 386 consumers against 249 → 84 vulnerabilities on the apache-debian base. If nobody speaks up here, the least disruptive path is option 1 from my earlier comment — apache-debian moves to amd64 and arm64, nginx and apache-alpine keep 386 — with a note in the README and the release notes so anyone affected finds out before the tag disappears.