schalli
2bd9029c0c
Fallout from encrypting the LDAP bind password: the base compose file still carries a hardcoded fallback key, so an install that never sets the variable starts anyway and encrypts everything with a value that is in the repository. The prod compose already requires it, which is the behaviour the base file should have too. Whether the example env files explain the key could not be checked in that session, so the item says to look first rather than asserting it is missing. Also notes, as an optional follow-up, why the variable is called CALENDAR_ENCRYPTION_KEY and what a rename would have to handle. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.9 KiB
created, title, area, severity, trigger, files
| created | title | area | severity | trigger | files | ||||
|---|---|---|---|---|---|---|---|---|---|
| 2026-08-11 | Verschluesselungsschluessel — fest eingebauter Vorgabewert in der Basis-Compose, Dokumentation in der Beispiel-Umgebung fehlt vermutlich | infra | minor | vor der ersten Installation bei einem externen Kunden; intern folgenlos, solange die Variable gesetzt ist |
|
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
- Den Vorgabewert aus
docker-compose.yml:46entfernen, sodass ein Start ohne gesetzten Schluessel scheitert statt still einen bekannten zu verwenden. Vorher pruefen, was das fuer die lokale Entwicklung heisst — moeglicherweise brauchtdocker-compose.dev.ymldann einen eigenen, klar als Wegwerf-Wert gekennzeichneten Eintrag, damit ein frisch geklontes Repo weiterhin hochfaehrt. - 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.