docker-net-dhcp

The upgrade path is a single documented command sequence (disable, rm, install the new tag), and it is deliberately cheap — see https://github.com/claymore666/docker-net-dhcp/blob/main/docs/reference.md#install-upgrade-uninstall. The support policy (latest release, no backports, because upgrades are cheap) is stated in SECURITY.md, and every behavioural change is recorded per release in RELEASE_NOTES.md.

GitHub Issues, with structured issue forms for bug reports and feature requests: https://github.com/claymore666/docker-net-dhcp/issues

No vulnerabilities have been reported or resolved in the last 12 months (zero published security advisories). SECURITY.md commits in advance to crediting reporters in the advisory and the release notes unless they request anonymity.

Documented in the "Reporting a vulnerability" and "Response process" sections of https://github.com/claymore666/docker-net-dhcp/blob/main/SECURITY.md — private GitHub security advisory intake, triage and confirmation, fix in a released version, published advisory with reporter credit.

The required style guides are named in the Contributing section: Go code must be gofmt-formatted and pass go vet and staticcheck; shell and workflow files must pass shellcheck and actionlint. Compliance is a stated requirement for an acceptable contribution. See https://github.com/claymore666/docker-net-dhcp#contributing

gofmt, go vet, and staticcheck run in the test workflow on every pull request, and actionlint runs as its own required status check. Branch protection on dev and main makes these checks blocking, so a non-conforming change cannot merge.

The Makefile invokes plain go build -o <out> ./cmd/<name> with no injected or overriding compiler/linker flags, so GOFLAGS, CGO_ENABLED, CGO_CFLAGS, and CGO_LDFLAGS supplied by the environment are honoured and passed through to the toolchain unchanged.

Nothing in the build strips the binaries: there is no -ldflags "-s -w", no strip, and no install -s. Symbol tables and DWARF debug information are preserved in the shipped binaries.

There is one top-level Makefile and no recursive make: it never invokes make in subdirectories. Cross-package dependencies are resolved by the Go toolchain from the package graph.

Verified empirically, not inferred. The plugin was built twice from a clean export of the same commit, the second time with docker build --no-cache so no layer or cached object could be reused, and the resulting binaries compared by SHA-256: identical both times (dhcp-handler 0eb5b698698f2d8f4e997062c77f295726915c9ba31125db1800e602edfa4bf8, net-dhcp 0ac36b87391c5bd5ea7a4b268183ca3fd86c686bf9b5d0505b97c4e0780d710b). The preconditions are pinned deliberately: dependencies fixed by go.mod/go.sum with checksum verification, the golang and alpine base images pinned by sha256 digest, Alpine package versions pinned and enforced by an apk-pin-check workflow, and a fixed build path inside the container.

Installed and removed with the standard Docker plugin convention: docker plugin install ghcr.io/claymore666/docker-net-dhcp:vX.Y.Z, and docker plugin disable + docker plugin rm to uninstall. Documented at https://github.com/claymore666/docker-net-dhcp/blob/main/docs/reference.md#install-upgrade-uninstall

There is no filesystem installation step for end users and therefore no DESTDIR-style convention to honour: the deliverable is a Docker managed plugin, installed by the daemon from a registry with docker plugin install.

A developer runs make (which builds the rootfs image, creates the plugin, and enables it) to get a working local install, and make integration-test to bring up the full test environment — the suite provisions its own dnsmasq DHCP fixtures on veth pairs, so no LAN setup or external server is needed. Standard convention (make + Docker), no bespoke bootstrap.

Go dependencies are listed machine-readably with pinned versions and checksums in https://github.com/claymore666/docker-net-dhcp/blob/main/go.mod and go.sum; runtime OS packages are version-pinned in the Dockerfile; and every release publishes an SBOM alongside the image.

Dependabot opens grouped weekly update PRs for Go modules and GitHub Actions; govulncheck runs as a required status check on every pull request and on a weekly schedule; CodeQL, Trivy, and GitHub Dependency Review also run in CI. Vulnerabilities with no fixed release available are recorded individually in .github/vuln-allowlist.txt with a written justification and a review date — never a bare identifier — and are re-evaluated by the gate on every run.

All reused components are standard Go modules resolved through go.mod, so updating one is a go get plus a lockfile change; Dependabot automates exactly that. No vendored or convenience copies of third-party source are carried in the repository.

staticcheck runs as a blocking CI check and its SA1019 rule fails the build on use of deprecated functions and APIs, so deprecated interfaces cannot silently accumulate. The stack is kept current deliberately — this fork exists partly because upstream stopped building against modern Docker; it tracks a current Go toolchain and Docker SDK.

A live integration suite runs on every pull request as a required status check, exercising all three attachment modes plus DHCPv6, restart recovery, and failure injection against a real kernel, a real Docker daemon, and real dnsmasq DHCP servers. It reports pass/fail per scenario in the workflow run.

Measured over the bug-fix commits merged in the six months to 2026-08-02: 37 fix commits, of which 23 also add or extend an automated test (a Go _test.go file or a scenario under test/integration), giving 62 percent. The misses are concentrated in the older part of the window and in CI and release-workflow fixes; every plugin behaviour fix merged since 2026-07-28 ships with a regression test. The rule is that a fix lands with the test that would have caught it — see the container-restart failures #402/#408, the v1.3.4 lease-lifecycle fixes, and TestHostConfig_NoSlowStopOptOut, which exists specifically to stop a test being weakened to make it pass.

Merged unit-plus-integration statement coverage is 85.8 percent, computed as a statement-weighted total over the shipped packages (pkg/plugin 85.0 percent of 1811 statements, pkg/dhcp 89.9 of 338, pkg/util 98.5 of 78, cmd/net-dhcp 76.4 of 72, cmd/dhcp-handler 75.0 of 16). Coverage is measured in CI by a dedicated workflow that merges the unit run with a coverage-instrumented build of the plugin exercised by the live integration suite. Per-package floors are recorded in .github/coverage-baseline.txt and enforced by a ratchet script that blocks any release regressing them.

Written policy in the Contributing section — new functionality is expected to ship with tests — backed by a per-package coverage ratchet that is a required check on the release pull request, so a feature that adds untested code cannot ship. See https://github.com/claymore666/docker-net-dhcp#contributing

The policy is stated in the documented instructions for change proposals. The README's Contributing section lists, among the requirements for an acceptable contribution: new functionality is expected to ship with tests, and a coverage ratchet enforces this at release time. See https://github.com/claymore666/docker-net-dhcp#contributing

staticcheck runs with its full default check set (all of SA, S, ST and QF) over the whole module rather than a reduced subset, and the linter version is pinned so an upgrade is a deliberate change. Unit tests additionally run under the Go race detector (go test -race).

Secure design principles are applied and argued explicitly in the assurance case at https://github.com/claymore666/docker-net-dhcp/blob/main/SECURITY.md#security-assurance-case — memory-safe implementation language, no home-grown cryptography, an explicit trust boundary around DHCP-server-supplied bytes, and the minimum privilege set the plugin can function with, declared in config.json and shown to the user at install time.