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>
21 lines
548 B
YAML
21 lines
548 B
YAML
name: base packages
|
|
|
|
# Every Monday: has a Debian package the mail path runs on moved since the
|
|
# last release was built? A red run is the nudge to cut a patch release
|
|
# (security audit 2026-10-17, I5; .github/scripts/base-packages.sh).
|
|
on:
|
|
schedule:
|
|
- cron: "17 5 * * 1"
|
|
workflow_dispatch:
|
|
|
|
permissions:
|
|
contents: read
|
|
|
|
jobs:
|
|
watch:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
|
|
- name: Compare with trixie
|
|
run: sh .github/scripts/base-packages.sh
|