CI never builds Dockerfile.serve — the non-root USER 10001 shipped unverified

[macanderson]

An unbuilt Dockerfile is shipping on main

packaging/docker/Dockerfile.serve:31 sets a non-root USER 10001. The image has never been built. The Docker daemon was unavailable when the change was made (docker info failed), and — verified again today — nothing in .github/workflows/ builds this image.

So a cold --release --locked build of a 15-crate workspace inside the container has never run, and the runtime preconditions for dropping to an unprivileged uid were checked by reading only:

• port 8080 set by ENV at L28,
• the binary landing world-executable in /usr/local/bin,
• useradd shipping in debian:bookworm-slim.

Every one of those is plausible. None is verified. The failure mode is that stella serve in a container is broken for whoever builds it first — and because nothing builds it, that will be a user.

The .dockerignore change that shipped alongside it is likewise unexercised: no image build, no before/after build-context measurement.

• Add a CI job that builds packaging/docker/Dockerfile.serve and runs the resulting image far enough to prove it serves on 8080 as uid 10001.

Acceptance: the image builds in CI, and a smoke request against the container succeeds.

_{Triaged out of #622 (rows 39, 40) as worth doing — the only "no witness" row where the artifact is user-facing and completely uncovered.}

[macanderson]

Folding in one open question from #614 (items 8 and 12), which was closed today — this issue already owns the "nothing builds this image" half, so both were struck there and pointed here.

The remaining undecided piece: should the documented docker run for this image use a --read-only root filesystem? (packaging/docker/Dockerfile.serve:24, originally audit #559 item 4, deferred by #590 as "a deployment policy choice about the operator's runtime.")

It is worth answering in this ticket rather than separately, because the CI job proposed here is the first thing that could actually test it: whoever builds the image to prove USER 10001 serves on 8080 can run the same smoke request a second time with --read-only and find out whether the binary needs a writable root at all. Today that is unknowable by reading — the answer depends on whether anything in stella serve's startup path writes outside a mounted volume.

For the record, #614's spot-check claim that the non-root USER had been reverted was wrong — Dockerfile.serve:30-31 still has useradd --system --uid 10001 --user-group stella and USER 10001, exactly as this issue describes. Nothing regressed.

[macanderson]

Triage 2026-07-26 — every claim verified true; nothing in flight

Confirmed at 558474c9. There are 10 workflow files, and rg -i 'docker|Dockerfile|buildx|packaging/docker' .github/ returns exactly one hit: .github/workflows/release.yml:54, a comment about cross's default docker image. Nothing builds packaging/docker/Dockerfile.serve.

The Dockerfile is exactly as described: :30 RUN useradd --system --uid 10001 --user-group stella, :31 USER 10001, :35 ENV STELLA_SERVE_BIND=0.0.0.0:8080, :37 EXPOSE 8080. The comment at :27-28 asserts the sidecar "writes nothing to the filesystem" — precisely the untested premise the folded-in --read-only question turns on.

Draft PR #685 does not touch packaging/; its ci.yml diff adds only the file-size and cargo-doc steps. No work is in flight on this.

One obstacle to size in: CI is not currently firing usefully on PR branches here — PR #685's only check is cla (skipped), and main itself is red at 558474c9 (cargo fmt --check). A new docker job would need that unblocked to be worth anything. Related: #306, where the merge queue is wired in ci.yml but never enabled in repo settings.

This is the only issue in its group with a user-facing artifact at zero coverage — labelled P1 accordingly.