Container for sbws
  • Dockerfile 85.8%
  • Shell 14.2%
Find a file
Iain Learmonth 9e2542800a
All checks were successful
Build and publish / lint (push) Successful in 3s
Build and publish / build-and-push-arch (push) Successful in 31s
ci: rebuild and publish the image weekly
Debian publishes security updates independently of this repository, so
add a scheduled run every Sunday at 03:17 UTC. Scheduled runs go through
the same lint, build and Trivy scan as pushes to main, and publish the
image only if the scan passes. A scheduled run that fails the scan
highlights a fixable vulnerability without replacing the last good image.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-28 14:27:30 +00:00
.forgejo/workflows ci: rebuild and publish the image weekly 2026-10-28 14:27:30 +00:00
.hadolint.yaml ci: lint Containerfile and scan image with Trivy before publishing 2026-10-28 14:14:04 +00:00
Containerfile ci: lint Containerfile and scan image with Trivy before publishing 2026-10-28 14:14:04 +00:00
entrypoint.sh entrypoint: stop creating /run/sbws 2026-10-28 14:14:21 +00:00
README.md ci: rebuild and publish the image weekly 2026-10-28 14:27:30 +00:00

docker-sbws

Container image for sbws, the Tor Simple Bandwidth Scanner, built from the Debian stable packages for sbws and tor.

The image is published to:

guardianproject.dev/sr2/docker-sbws:latest

Usage

The entrypoint fixes ownership of /var/lib/sbws, drops privileges to the unprivileged sbws user (UID/GID 995) and runs /usr/bin/sbws with any arguments passed to the container.

sbws is not run in "supervised" mode (SUPERVISED=1, as used by the Debian systemd units), so all state lives under /var/lib/sbws, including the data directory, control socket and pid file of the tor instance that sbws manages (/var/lib/sbws/tor). Pass the configuration file explicitly with -c.

podman run --rm \
  -v sbws-data:/var/lib/sbws \
  -v ./sbws.ini:/etc/sbws/sbws.ini:ro \
  guardianproject.dev/sr2/docker-sbws:latest \
  -c /etc/sbws/sbws.ini scanner

To generate a bandwidth file from existing results:

podman run --rm \
  -v sbws-data:/var/lib/sbws \
  -v ./sbws.ini:/etc/sbws/sbws.ini:ro \
  guardianproject.dev/sr2/docker-sbws:latest \
  -c /etc/sbws/sbws.ini generate

See the sbws documentation for configuration options.

Building

podman build -f Containerfile -t docker-sbws:latest .

Continuous integration

The Forgejo Actions workflow in .forgejo/workflows/build-and-publish.yaml runs on pull requests, on pushes to main, and on a weekly schedule (Sundays at 03:17 UTC) so that the published image picks up Debian security updates even when the repository has not changed:

  1. Lint – the Containerfile is checked with hadolint using the settings in .hadolint.yaml. Any finding fails the build.
  2. Build – the image is built from a freshly pulled base image without the layer cache, so that it always contains the latest Debian security updates.
  3. Scan – the built image is scanned with Trivy. The build fails if any HIGH or CRITICAL vulnerability is present for which a fix is available. Unfixed vulnerabilities are reported by Debian but cannot be resolved by rebuilding, so they do not fail the build.
  4. Publish – on pushes to main and scheduled runs only, the scanned image is pushed to the registry. Pull requests are linted, built and scanned but never published.

hadolint and Trivy are installed from pinned upstream releases and verified against SHA-256 checksums. To update either tool, change the version and checksum in the env block at the top of the workflow.

If a finding needs to be accepted temporarily (for example, a fix that does not apply to how sbws uses the package), add the vulnerability ID to a .trivyignore file in the repository root with a comment explaining why.

To run the same checks locally:

hadolint Containerfile
podman build -f Containerfile -t docker-sbws:latest .
trivy image --image-src podman --scanners vuln \
  --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 \
  docker-sbws:latest