mixandClaude Opus 5.5
68493dc097
Security audit 2026-10-17, findings I4 and I5 (low), stage 5. I4: every action is pinned by commit with its version in a comment - the latest release of the major each used, so nothing changes in behaviour (checkout v4.4.0, setup-go v5.6.0, setup-buildx-action v3.12.0, build-push-action v6.19.2, login-action v3.7.0; commits read with git ls-remote, the tags are lightweight). govulncheck v1.9.0 runs on the source in test.yml, and in release.yml on the image's panel and selfpost-backup binaries before the push (-mode=binary: the base image's Go, which may lag the runner's - a fixed stdlib advisory then fails the release until golang:1.26-trixie moves, which is the point). certbot is pinned to v5.8.0 and Caddy to 2.11.7 (Docker Hub, 2026-10-17). provenance/SBOM stay off until the GHCR cleanup keeps attestations, as the plan says. I5: published tags are never rebuilt, so a Debian security fix reaches operators with the next release. The guide (§ Upgrading) and SECURITY.md say so; base-packages.yml runs .github/scripts/base-packages.sh every Monday: what debian:trixie-slim would install for postfix, libsasl2-2, libsasl2-modules-db, sasl2-bin, openssl, libssl3t64, libdb5.3t64 against the table in development.md (the 2.14.3 image's versions), red when one moved. Tried on the test server: green as it stands, red with a version changed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
80 lines
3.7 KiB
YAML
80 lines
3.7 KiB
YAML
|
|
# Alternative reverse-proxy: nginx. PEM files land on the host exactly like the
|
|
# Apache+certbot scenario — nginx and certbot are close cousins here, both
|
|
# writing/reading plain PEM under /etc/letsencrypt.
|
|
#
|
|
# This is a FRAGMENT, not a full replacement for ../docker-compose.yml: it
|
|
# adds an nginx + certbot pair and removes the panel's host port publish (nginx
|
|
# takes over 80/443 and proxies to the panel over the compose network
|
|
# instead). Merge it with the base file — run this from the deploy/ directory
|
|
# (Compose resolves every relative path in both files against the directory of
|
|
# the FIRST -f file, i.e. deploy/, which is why paths below are ./nginx/... -
|
|
# docs.docker.com/compose/how-tos/multiple-compose-files/merge/: "Paths are
|
|
# evaluated relative to the base file"):
|
|
#
|
|
# docker compose -f docker-compose.yml -f nginx/docker-compose.nginx.yml up -d
|
|
#
|
|
# First-run certificate issuance, before nginx has a certificate to serve -
|
|
# run once, with port 80 free (certbot answers the challenge itself;
|
|
# --webroot would need nginx already serving /.well-known). --entrypoint is
|
|
# needed: the service's own entrypoint is the renewal loop below, an
|
|
# `sh -c` that ignores any arguments given to `run`
|
|
# (docs.docker.com/reference/compose-file/services/#entrypoint; assumptions
|
|
# D-guide:301):
|
|
# docker compose -f docker-compose.yml -f nginx/docker-compose.nginx.yml \
|
|
# run --rm -p 80:80 --entrypoint certbot certbot certonly --standalone \
|
|
# -d mail.example.com --email you@example.com --agree-tos --no-eff-email
|
|
|
|
services:
|
|
selfpost:
|
|
ports: !override
|
|
- "465:465"
|
|
- "587:587"
|
|
- "25:25"
|
|
# No host publish for 8080 here: nginx reaches it over the compose
|
|
# network at selfpost:8080 instead (see nginx.conf.example).
|
|
volumes: !override
|
|
- ./data:/data
|
|
- .:/selfpost-deploy:ro
|
|
# certs/ holds two links, fullchain.pem and privkey.pem, to
|
|
# /etc/letsencrypt/live/mail.example.com/ - a path inside the
|
|
# container: certbot's directory below is mounted there whole, because
|
|
# its live/ files are relative links into archive/ (mounting live/ alone
|
|
# left them pointing at nothing). docs/guide.md, "Reverse proxy", nginx.
|
|
- ./certs:/etc/postfix/tls:ro
|
|
- ./nginx/certbot-etc:/etc/letsencrypt:ro
|
|
|
|
nginx:
|
|
image: nginx:1.27
|
|
restart: unless-stopped
|
|
# A ceiling on processes and threads (security audit 2026-10-17, I3).
|
|
pids_limit: 256
|
|
depends_on:
|
|
- selfpost
|
|
ports:
|
|
- "80:80"
|
|
- "443:443"
|
|
volumes:
|
|
- ./nginx/nginx.conf.example:/etc/nginx/conf.d/selfpost.conf:ro
|
|
- ./nginx/certbot-etc:/etc/letsencrypt:ro
|
|
- ./nginx/certbot-www:/var/www/certbot:ro
|
|
|
|
certbot:
|
|
# Pinned like every image here: "latest" moves under a running server
|
|
# (security audit 2026-10-17, I4). Bump it deliberately.
|
|
image: certbot/certbot:v5.8.0
|
|
pids_limit: 64
|
|
volumes:
|
|
- ./nginx/certbot-etc:/etc/letsencrypt
|
|
- ./nginx/certbot-www:/var/www/certbot
|
|
# Renewal twice a day is certbot's own recommended cadence; it no-ops
|
|
# until a certificate is within its renewal window.
|
|
# (eff-certbot.readthedocs.io, User Guide, "Automated Renewals": the
|
|
# sample cron runs "certbot renew" at 0 and 12 h; renew acts only on a
|
|
# certificate near expiry.) The first certificate was issued --standalone
|
|
# (see the top of this file), and certbot renews with the plugin it was
|
|
# issued with "unless you specify other plugins or options" (same page,
|
|
# "Renewing certificates") - by then nginx holds port 80 and serves the
|
|
# webroot, so renewal names it; a renewal that succeeds with it saves it.
|
|
entrypoint: sh -c 'trap exit TERM; while :; do certbot renew --webroot -w /var/www/certbot; sleep 12h & wait $${!}; done'
|