docs: close the encryption-key backlog note and log the session

The note predated 7bda56d and f574884, so two of its three points were already shipped when it was picked up. Records what each commit actually closed, and that the .env deny rules block the two committed template files that hold no secrets. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-11 15:19:13 +02:00
parent 379606ee34
commit 61948440ab
3 changed files with 39 additions and 52 deletions
@@ -1,63 +0,0 @@
---
-created: 2026-08-11
-title: Verschluesselungsschluessel — fest eingebauter Vorgabewert in der Basis-Compose, Dokumentation in der Beispiel-Umgebung fehlt vermutlich
-area: infra
-severity: minor
-trigger: vor der ersten Installation bei einem externen Kunden; intern folgenlos, solange die Variable gesetzt ist
-files:
-  - docker-compose.yml:46
-  - docker-compose.prod.yml:44
-  - .env.example
-  - .env.prod.example
---
-
-## Problem
-
-Seit 4f687ea sind alle Zugangsdaten in der Datenbank verschluesselt — Kalender,
-SMTP, DKV-Postfach, Ausschreibungs-Postfach und nun auch das LDAP-Bind-Passwort.
-Der Schluessel dafuer kommt aus der Umgebungsvariable `CALENDAR_ENCRYPTION_KEY`
-und liegt bewusst NICHT in der Datenbank.
-
-Zwei Luecken drumherum:
-
-**1. Vorgabewert in der Basis-Compose.** `docker-compose.yml:46` lautet
-
-```
-CALENDAR_ENCRYPTION_KEY: ${CALENDAR_ENCRYPTION_KEY:-5dbbaba2...}
-```
-
-Ist die Variable nicht gesetzt, startet die Anwendung also trotzdem — mit einem
-Schluessel, der im Repository steht und damit jedem bekannt ist, der den Code
-hat. Die Verschluesselung sieht dann vorhanden aus, traegt aber nicht. Ein
-stiller Fehlstart ist hier schlechter als ein lauter: `docker-compose.prod.yml:44`
-macht es bereits richtig und verlangt die Variable ohne Vorgabe.
-
-**2. Dokumentation.** Ob `.env.example` / `.env.prod.example` den Schluessel
-erklaeren, konnte ich am 2026-08-11 nicht pruefen (Dateizugriff in der Sitzung
-blockiert) — beim Umsetzen also zuerst nachsehen. Falls er dort fehlt oder ohne
-Erklaerung steht, weiss bei einer Neuinstallation niemand, dass ein eigener
-Wert erzeugt werden muss und was passiert, wenn er spaeter verloren geht.
-
-Aufgefallen am 2026-08-11, als der User fragte, wo der Schluessel liegt und ob
-man ihn exportieren kann.
-
-## Solution
-
-1. Den Vorgabewert aus `docker-compose.yml:46` entfernen, sodass ein Start ohne
-   gesetzten Schluessel scheitert statt still einen bekannten zu verwenden.
-   Vorher pruefen, was das fuer die lokale Entwicklung heisst — moeglicherweise
-   braucht `docker-compose.dev.yml` dann einen eigenen, klar als Wegwerf-Wert
-   gekennzeichneten Eintrag, damit ein frisch geklontes Repo weiterhin
-   hochfaehrt.
-2. In beiden Beispiel-Umgebungsdateien den Schluessel dokumentieren: wie er
-   erzeugt wird (`openssl rand -hex 32`), dass er zu jedem Datenbank-Backup
-   gehoert und getrennt davon aufbewahrt werden sollte, und dass ein verlorener
-   Schluessel bedeutet, dass alle gespeicherten Zugangsdaten neu eingetragen
-   werden muessen.
-
-Optional im selben Zug, weil es beim Lesen sonst jedes Mal irritiert: der Name
-`CALENDAR_ENCRYPTION_KEY` stammt daher, dass das Kalender-Modul die
-Verschluesselung zuerst brauchte. Er gilt laengst fuer alle Zugangsdaten der
-Plattform. Eine Umbenennung muesste den alten Namen als Rueckfallebene lesen,
-sonst faellt jede bestehende Installation beim naechsten Start auf die Nase —
-siehe auch die Notiz dazu im LdapModule.