image: the TLS key's group is the panel's alone, 10997 (audit I1)

Security audit 2026-10-17, finding I1, stage 2; the help mockup is ff3a118.
The guide had operators give the TLS private key to group 10998 so the
panel can archive it, and the Dockerfile puts postfix in that group (for
sasldb2 and the maps): `docker exec -u postfix head privkey.pem` printed
the live key. postfix-config.sh copies the key to a root-only directory
precisely so that a compromised Postfix daemon cannot read it - the mounted
original undid that.

Now a group backupkey (gid 10997, outside the system range like 10998)
whose one member is the panel; the guide (Apache/certbot, nginx, Taking a
full backup, the backup table), Help, and the backup's refusal name 10997
and say why; postfix-config.sh, extract-cert.sh and the Dockerfile's
comments follow. A key still given to 10998 keeps working for the backup.
CHANGELOG has an Upgrading note.

e2e: the stage gives its key to 10997 at 0640 when the runner is root
(stageKeyMode; 0644 otherwise), and testFullBackupRestore, after the
refusal that now names chgrp 10997, checks that the postfix uid cannot read
/etc/postfix/tls/privkey.pem and the panel can.

Docs: security.md § Output and process (the groups); guide; CHANGELOG;
plan.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

build/Dockerfile

@@ -109,9 +109,10 @@ RUN groupadd --system --gid 10999 panel  && useradd --system --uid 10999 --gid p
 # (set up in entrypoint.sh) - lets Postfix read the sasldb2/sender map and
 # connect to the panel's milters. The DKIM keys are the panel's alone. (The
 # supervisor control socket has a group of its own, `supervisor`, below.)
-# The id is fixed, because the host sees it: an operator gives the TLS
-# private key on the host to this group by number, so that the panel can put
-# it into a full backup (guide § Taking a full backup). It lies outside the
+# The id is fixed, because the host saw it: until 2.14.4 an operator gave the
+# TLS private key on the host to this group by number - now to backupkey,
+# below, which Postfix is not in - and a key given then still names it. It
+# lies outside the
 # range the distribution hands out to system groups, 100-999 (adduser 3.152,
 # /etc/adduser.conf: "Default: FIRST_SYSTEM_GID=100, LAST_SYSTEM_GID=999";
 # passwd 1:4.17.4-2, /etc/login.defs: SYS_GID_MIN 101, SYS_GID_MAX 999 - both
@@ -127,6 +128,16 @@ RUN groupadd --system --gid 10998 selfpost \
  && usermod -aG selfpost panel \
  && usermod -aG selfpost postfix
 
+# The host's TLS private key is given to this group, not to selfpost, so that
+# the panel can put it into a full backup (guide § Taking a full backup) and
+# no Postfix daemon can read it: postfix is in selfpost, and a memory-safety
+# bug in an smtpd reached from the internet would otherwise yield the key of
+# the mail and of the panel (security audit 2026-10-17, I1). Postfix itself
+# serves a root-only copy (postfix-config.sh). The panel is the one member.
+# Fixed for the same reason as selfpost's, next to it.
+RUN groupadd --system --gid 10997 backupkey \
+ && usermod -aG backupkey panel
+
 # The panel reads the mail queue with `postqueue -p` (and the status page's
 # queue card). postqueue is setgid postdrop, which normally gives it the group
 # needed to reach Postfix's showq socket - but the documented deployment runs