- Dockerfile 85.8%
- Shell 14.2%
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> |
||
|---|---|---|
| .forgejo/workflows | ||
| .hadolint.yaml | ||
| Containerfile | ||
| entrypoint.sh | ||
| README.md | ||
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:
- Lint – the
Containerfileis checked with hadolint using the settings in.hadolint.yaml. Any finding fails the build. - 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.
- 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.
- Publish – on pushes to
mainand 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