René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Extra CA bundle in builds and containers; tests for secrets on tmpfs (Spinbox integration)","articleBody":"Spinbox is adding devcontainer support and a new secrets model (installation → team → user scopes). Builds and containers run inside a workspace VM whose outbound traffic goes through an egress proxy. For hosts where a rule injects a credential, the proxy terminates TLS with its own CA; every other host is relayed as bytes. Spinbox will call this CLI with:\n\n- `--secrets-file` pointing at a JSON file on tmpfs, holding the workspace's resolved `env` secrets;\n- `DOCKER_CONFIG` pointing at a tmpfs directory when a registry credential is delivered as a file;\n- `TMPDIR` on tmpfs.\n\nNothing secret may reach the workspace disk, because a prebuild's disk becomes a snapshot shared with a team.\n\nMost of this already works. One feature is missing, and three behaviours need tests so they don't regress.\n\n## 1. Trust an extra CA bundle in builds and in the container (missing)\n\nA `RUN` step, or a Feature's `install.sh`, that calls a host the proxy injects for fails TLS: the build container trusts only the image's own CAs. The same is true for processes in the running container.\n\nProposed: `--ca-bundle \u003cfile>` on `build`, `up` and `run-user-commands` (name open). The file is a full PEM bundle (system CAs + the proxy's CA), so tools that replace the system pool keep working.\n\n- **Feature install RUNs** (the CLI writes these, in `imagemeta/extend.go`): mount the bundle as a BuildKit secret, as is already done for `--secrets-file` ids, e.g. `--mount=type=secret,id=devcontainer-ca-bundle,target=/run/devcontainer/ca-bundle.crt`, and set for that RUN only: `SSL_CERT_FILE`, `NODE_EXTRA_CA_CERTS`, `REQUESTS_CA_BUNDLE`, `CURL_CA_BUNDLE`, `GIT_SSL_CAINFO`.\n- **User Dockerfile**: the CLI cannot change its RUNs. Pass the same secret id to buildx so a Dockerfile can opt in with `RUN --mount=type=secret,id=devcontainer-ca-bundle,target=...`, and document it.\n- **Running container** (`up`): bind-mount the bundle read-only at the same path and set the same variables in the container's environment, so lifecycle hooks and the user's shells trust it.\n- Mount it, never `COPY` it: the image must be the same with and without a bundle, so the cache key and the prebuilt image don't depend on the proxy. The CA is public, so the reason is reproducibility, not secrecy.\n- Without buildx: a warning, as `buildxSecrets` does today.\n\nTests: a Feature RUN and an opted-in Dockerfile RUN reach an HTTPS server signed by a test CA, and fail without the flag. The built image's layers and config don't contain the bundle. In the container, `curl` and `node` trust the server.\n\n## 2. `DOCKER_CONFIG` on tmpfs (works; needs a test)\n\n`oci/auth.go:76` and `docker/context.go:51` already honour `DOCKER_CONFIG`. Add a test that registry resolution and `bridgeBuildAuth` read credentials from a `DOCKER_CONFIG` directory outside `$HOME`, where `config.json` is a symlink to another directory. Spinbox serves it from a FUSE or tmpfs mount, so it never puts a file at `~/.docker/config.json`; its prebuild scan flags that path whatever it contains.\n\n## 3. `--secrets-file` on `up` (works; needs a test)\n\n`up` already passes the file to the Dockerfile and Feature builds (`up.go:1408`) and to lifecycle hooks (`up.go:1216`). Add one end-to-end test that `up --secrets-file` gives both a `RUN --mount=type=secret,id=K` and a `postCreateCommand` the value, and that the value is in no image layer, no image config (`docker history`) and no container label.\n\n## 4. Temporary build auth follows `TMPDIR` (works; document it)\n\n`ResolveBuildAuth` writes the resolved registry credentials to `os.MkdirTemp(\"\")` and removes them after the build. Say in the docs that it uses `TMPDIR`, so a caller that must keep credentials off disk knows to point `TMPDIR` at tmpfs.\n\nSpinbox side, for context: the plan covers secret scopes, delivery through tmpfs and FUSE, and prebuilds. It ships alongside devcontainer support.\n","author":{"url":"https://github.com/aledbf","@type":"Person","name":"aledbf"},"datePublished":"2026-11-07T16:53:19Z","url":"https://github.com/spin-stack/devcontainer-cli/issues/50"}