baredevcontainer/debian repository overview

⁠debian

Minimal Debian base image for dev containers. All other images in this repository extend this image.

Like every image in this repository, it is minimal, built only from upstreams verified at build time, and published with SLSA provenance, a GitHub artifact attestation, and an SBOM; it runs as the non-root user dev. Why these images⁠ explains the reasoning, and Verifying the image⁠ below shows how to check a build.

⁠Image

ghcr.io/bare-devcontainer/debian:<tag>

Reference it from .devcontainer/devcontainer.json, pinning the digest as well as the tag:

{
  "image": "ghcr.io/bare-devcontainer/debian:trixie@sha256:<digest>"
}

⁠Dev Container Template

A ready-to-use Dev Container template for this image is available at bare-devcontainer/templates⁠. It provides the recommended configuration for this image, including security hardening.

⁠Tags

Tags are also published with a date suffix on each build (e.g., trixie-<YYYYMMDD>).

⁠Installed software

• Git & SSH: git, openssh-client, gnupg2
• Network: ca-certificates, iproute2, curl, wget
• System utilities: procps, lsof, psmisc
• Archive utilities: unzip, bzip2, xz-utils, zip, zlib1g
• File utilities: less, jq, vim-tiny
• Scripting: python3
• C/C++ build toolchain: build-essential (gcc, g++, make, and the libc headers)
• Misc: bash-completion, lsb-release, locales (en_US.UTF-8), man-db, manpages

The image runs as the non-root user dev (UID/GID 1000) and its working directory is /workspaces. remoteUser and containerUser are declared through the devcontainer.metadata label⁠, so Dev Container clients pick up the user without extra configuration. Every image built on this one inherits that label.

dev owns its home directory and nothing else, so a client that remaps it to the host user's UID leaves nothing behind: /workspaces is created as root and covered by the workspace bind mount. The dev user⁠ has the details.

dev's login shell is bash, which appends each command to $HISTFILE as it is entered rather than at exit. Under a Dev Container client, HISTFILE is /home/dev/.local/state/bash/history rather than the default ~/.bash_history, and that directory is created in the image, so mounting a volume on it keeps the shell history across container rebuilds, which is what the Dev Container template⁠ does.

⁠Not installed

• No development headers beyond libc. build-essential covers the compiler, linker, and libc headers, so a self-contained C or C++ source build works. Code that links against a third-party library still needs that library's -dev package.
• No sudo. Nothing in the container can escalate to root. Install packages at build time in your own Dockerfile (which runs as root) or through a Dev Container Feature.
• No language runtime for development. python3 is present so that scripts and tooling that assume a system Python keep working; it is not intended as a project interpreter. Use the uv⁠, mise⁠, or another language image for that.
• No editor or shell beyond the basics. bash and vim-tiny only.

⁠Supply chain

The image is built FROM the Docker Official debian image⁠, pinned in build.yaml to both a tag and a content digest so a build always resolves to the exact base that was reviewed. Renovate raises a pull request whenever a new Debian base is published. All other software comes from the Debian package archive over apt, which verifies the archive's signatures on every install.

⁠Verifying the image

Every build is published with SLSA provenance, a GitHub artifact attestation, and an SBOM. The attestation confirms that an image was built by the release workflow of this repository and has not been altered since:

gh attestation verify oci://ghcr.io/bare-devcontainer/debian:<tag>@sha256:<digest> \
  --owner bare-devcontainer

The Docker Hub mirror carries the same digests, so the same command verifies an image pulled from docker.io/baredevcontainer/debian. Verifying Published Images⁠ covers inspecting the provenance and the SBOM as well.