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>
90 lines
4.0 KiB
Markdown
90 lines
4.0 KiB
Markdown
# Security policy
|
|
|
|
## Supported versions
|
|
|
|
SelfPost follows SemVer. Fixes are issued for the **latest minor release of the
|
|
2.x line** only; there is no backporting to earlier minors or to 1.x. Upgrade before
|
|
reporting if you are behind — the image tag is `ghcr.io/mixeme/selfpost:X.Y.Z`.
|
|
|
|
| Version | Supported |
|
|
|---|---|
|
|
| latest 2.x | yes |
|
|
| earlier 2.x | no — upgrade first |
|
|
| 1.x | no — upgrade to 2.x (guide § Upgrading) |
|
|
| 0.x | no (pre-release) |
|
|
|
|
A security update of a Debian package the image runs - Postfix, Cyrus SASL,
|
|
OpenSSL, Berkeley DB - arrives with the next patch release built after it:
|
|
published image tags are never rebuilt. A weekly check
|
|
(`.github/workflows/base-packages.yml`) says when one has moved, and a patch
|
|
release follows.
|
|
|
|
## Reporting a vulnerability
|
|
|
|
**Do not open a public issue.** Use GitHub's private vulnerability reporting:
|
|
the *Report a vulnerability* button under the repository's
|
|
[Security tab](https://github.com/mixeme/selfpost/security). If you cannot use
|
|
it, mail `public@mixeme.ru` instead.
|
|
|
|
Useful in a report: the image tag, the reverse proxy in front of the panel, the
|
|
steps to reproduce, and what an attacker gains. A relevant excerpt of
|
|
`mail.log` or the panel's system log helps; strip recipient addresses first.
|
|
|
|
**No response time is promised.** SelfPost is maintained by one person, and a
|
|
deadline that cannot be honoured is worse than none. Reports are read and
|
|
answered as soon as the maintainer is able; a fix ships in a patch release,
|
|
with the timeline agreed in the thread.
|
|
|
|
Disclosure is coordinated by request, not by demand: please hold public details
|
|
until a patch is out. If you get no reply, that is not a request for a
|
|
continued embargo — disclose at your own discretion. Reporters are credited in
|
|
the CHANGELOG unless they ask not to be.
|
|
|
|
## In scope
|
|
|
|
The relay's job is to accept authenticated mail from an application and hand it
|
|
to the internet as the operator's domain, and nothing else. Breaking that is in
|
|
scope:
|
|
|
|
- **Open relay** — mail accepted from an unauthenticated sender, or relayed for
|
|
a domain the sending application is not bound to
|
|
- **SASL bypass** — sending without valid credentials, or credential recovery
|
|
from anything the container exposes
|
|
- **Cross-domain access** — an application or a panel session reaching a domain
|
|
it was not granted
|
|
- **Secret disclosure** — DKIM private keys, the admin password hash, session
|
|
tokens, or backup encryption material leaking to an unauthorised party
|
|
- **Panel authentication and session flaws** — login bypass, session fixation,
|
|
CSRF on state-changing routes, privilege escalation
|
|
- **Rate-limit bypass** — evading either the Postfix-level backstop or the
|
|
per-domain and per-application limits
|
|
- **Container escape** or privilege escalation from the panel's unprivileged
|
|
user to root
|
|
|
|
## Out of scope
|
|
|
|
These are the operator's responsibility or accepted trade-offs, documented in
|
|
[docs/security.md](docs/security.md) and the
|
|
[operator guide](docs/guide.md):
|
|
|
|
- Host configuration the operator controls: a blocked port 25, a missing or
|
|
wrong PTR record, DNS records not published, a self-signed or expired
|
|
certificate on the reverse proxy
|
|
- Anything requiring the attacker to already have root on the host or write
|
|
access to the `./data` bind mount
|
|
- Missing hardening headers or TLS options on the reverse proxy — SelfPost
|
|
never terminates HTTPS itself
|
|
- Deliverability outcomes: mail rejected or filtered by a receiving provider is
|
|
a policy decision of that provider, not a defect
|
|
- Denial of service through sheer volume against a single-tenant relay
|
|
- Vulnerabilities in upstream Postfix, the Go libraries SelfPost builds on,
|
|
or the base image — report
|
|
those upstream; if SelfPost's configuration makes an upstream issue
|
|
exploitable when it otherwise would not be, that *is* in scope
|
|
|
|
## Reports we cannot act on
|
|
|
|
Automated scanner output with no demonstrated impact, and reports whose only
|
|
content is a version number compared against a CVE list, are closed without
|
|
investigation.
|