[djdomi]

Summary

• Add conditional --allow network.host to the local DOCKER_BUILDKIT=1 docker build scan path when Rust acceleration selects host networking.
• Add a governance guard so the local scan build cannot keep --network host without the matching entitlement wiring.

Fixes #565

Why

The buildx-action publish paths already pass allow: network.host when RUST_BUILDX_NETWORK=host. The local scan build used the same host network selection but did not pass the matching BuildKit entitlement, so trusted secret-backed Rust acceleration could diverge between scan and publish paths.

Risk / Rollback

• Risk is limited to the local scan image build path.
• The entitlement is only passed when the selected scan network is host; bridge/default behavior is unchanged.
• Rollback is reverting this PR; doing so restores the scan/publish network entitlement mismatch.

Validation

• docker build --help and docker buildx build --help both expose --allow on this runner.
• docker run --rm -v "$PWD:/work" -w /work ghcr.io/wiki-mod/lancache-ng/build-tools:latest actionlint .github/workflows/build-push.yml
• Targeted guard confirmed allow_args+=(--allow network.host) and "${allow_args[@]}" are wired into the local scan build.
• git diff --check

Follow-up

• None for this issue.

[djdomi]

CLD-1783680662

Review: correct pattern, but the actual open question from the issue isn't answered yet

The code change itself is right: --allow network.host is now added conditionally, only when scan_build_network = host, matching the pattern already used by the two buildx-action-based build steps elsewhere in this workflow. No risk of it firing on the default/bridge path.

But issue #565's actual open question was whether classic DOCKER_BUILDKIT=1 docker build (no explicit docker buildx build/named container-driver builder) even enforces the same entitlement sandboxing that docker buildx build does with a container driver -- and it explicitly said this needs verification via an actual CI run with secrets present, not a code-only judgment call. The PR's validation section only confirms that docker build --help/docker buildx build --help both list --allow as a recognized flag on this runner -- that's syntax acceptance, not proof the flag does anything for this specific driver/invocation.

Not blocking on this since the change is safe either way (correct if needed, harmless no-op if not, and only reachable on the rare secret-backed host-network path) -- but would be good to actually confirm with a real run that has RUST_BUILDX_NETWORK=host and secrets present, so we know whether this flag is load-bearing or decorative here.

[djdomi]

CLD-1783681254

Follow-up: researched this, the fix as written is likely incomplete

Checked Docker's actual documentation and the docker/buildx issue tracker on how network.host entitlement enforcement really works:

• For the docker-container builder driver, network.host has been granted by default since buildx v0.13.0 -- --allow network.host on the build command is enough by itself.
• For the plain docker driver (the Docker daemon's own built-in BuildKit, used whenever no explicit buildx builder has been created), the daemon itself must separately be started with --allow-insecure-entitlement network.host (or the equivalent buildkitd.toml setting) for the --allow network.host build flag to actually take effect. Without that daemon-side flag, the entitlement isn't granted just because the build command asks for it.

Checked which driver this specific step actually uses: the container-scan job (where the "Build local scan image" step with the fix lives) never calls docker/setup-buildx-action itself -- that only happens in other, separate jobs (validate-compose, etc.), and GitHub Actions jobs don't share builder state across jobs. So this step is on the plain docker driver, using the self-hosted runner's daemon-embedded BuildKit -- exactly the case that needs the daemon-level flag, not just the build-command flag.

So as written, --allow network.host here likely doesn't actually do anything unless the self-hosted runners' Docker daemons have separately been started with --allow-insecure-entitlement network.host (an infrastructure-level config, not something this workflow file controls).

Suggested fix

Rather than depending on runner-daemon-level dockerd flags (fragile, easy to silently drift if a runner gets reprovisioned), add a docker/setup-buildx-action step to this job before the scan build and switch this step to docker buildx build (explicit) instead of plain docker build -- that puts it on the docker-container driver, which gets network.host by default per the buildx v0.13.0+ behavior, with no daemon-side config dependency at all.

Sources:

• https://docs.docker.com/reference/cli/docker/buildx/build/
• driver: set network.host entitlement by default for container drivers docker/buildx#2266 ("set network.host entitlement by default for container drivers")
• Insecure Entitlement "network.host" not working docker/buildx#835 ("Insecure Entitlement network.host not working")

[djdomi]

CLD-1783683828

Fix pushed: switched to an explicit docker-container Buildx builder

Pushed bdd61b0. Per the earlier research finding, added a docker/setup-buildx-action step before the scan build and switched docker build -> docker buildx build --load (the --load is required since the docker-container driver doesn't build straight into the local image store like the plain driver does, and the following Trivy step needs the image loaded locally). This puts the build on the driver that gets network.host entitlement by default (buildx v0.13+, docker/buildx#2266), removing the dependency on the self-hosted runners' Docker daemons having --allow-insecure-entitlement network.host configured -- which this workflow file has no way to verify or control.

Added a governance guard confirming the setup-buildx-action step and docker buildx build invocation stay in place, matching this file's existing self-enforcement pattern for the other related checks.

This should now fully resolve the original technical uncertainty, not just move the flag around.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.