TLS-Gate v3.2.1: Dubletten melden einen Satz — Nachtrag zu v3.2.0
Von: Branko → OZMAI
Stand: 2. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: NACHTRAG / KORREKTUR. Ersetzt in 2026-10-02_TLS-GATE-V3-2-0-DEPLOY-ZIP-OUTBOX-UND-FAKE-MODUS-RAUS_BRANKO.md genau eine Aussage (§4, „Neu dazugekommen und ebenfalls offen: cred add …“). Die alte Datei bleibt unverändert.
Quelle: Repo TLS-Gate-Mock-Pipeline (git.crumbforest.org), Tag v3.2.1 = Commit 98a4f38; Vorstufe cred add = 379f6bf; Docs-Nachzug 7cc8b59.
Belege: tests/test_auth.sh (76), tests/test_credentials.sh (62), docker_vm/tests/p3.sh (48); Gesamtlauf siehe §3.
Legende: ✅ real/gebaut · 🧪 gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN
Keine Zugangsdaten, keine Kunden-Domains, keine Reseller-IDs.
1. Was sich gegenüber dem Eintrag zu v3.2.0 ändert
Die Notiz zu v3.2.0 nannte zwei offene Schönheitsfehler: group add mit vorhandenem Slug (PDOException-Stacktrace) und cred add mit vorhandenem Label (rohe 1062 Duplicate entry-Meldung). Beide sind behoben, und ein dritter Fall desselben Musters, user add, mit.
| Befehl | vorher | jetzt (🧪) |
|---|---|---|
cred add (Web und CLI) |
rohe SQL-Meldung, im Web sichtbar | ein Satz, nennt den Weg (replace / „Zugangsdaten ersetzen“) |
group add (CLI) |
PDOException-Stacktrace | ein Satz, Exit 1 |
user add (CLI) |
PDOException-Stacktrace, nach der Passwortabfrage | ein Satz, Exit 1, vor der Passwortabfrage |
Die Weboberfläche für Gruppen und Benutzer (users.php) prüfte schon vorab; dort war nichts zu tun. Es war ein CLI-Fehler, kein Fehler im Datenmodell: die UNIQUE-Bedingungen der DB haben die Dublette immer sicher verhindert, nur die Meldung war unbrauchbar.
2. Wie es gebaut ist
- Vorab-Prüfung (SELECT) und zusätzlich Abfangen von
SQLSTATE 23000aus dem INSERT für den Fall, dass zwei Anlagen gleichzeitig laufen. Die DB-Bedingung bleibt die eigentliche Sperre, die Prüfung davor ist nur die lesbare Seite. - Spiegel:
native_php/mitgezogen (die VM bezieht ihren Code von dort).
3. Belegt, und was nicht
- 🧪 Gegenprobe: Mit dem alten
bin/user_cli.phpscheitern genau die beiden neuen Meldungsprüfungen (group add,user add); die dritte („Dubletten ändern nichts“) besteht auch mit dem alten Code, weil die DB schon immer abgelehnt hat. Sie belegt also die Unveränderlichkeit, nicht die Meldung. Beicred addzeigt die Gegenprobe, dass ohne Vorprüfung die rohe UNIQUE-Meldung käme. - 🧪 Im Container gegen den echten Aufruf (
p3.sh): lesbare Meldung, Exit 1, keinSQLSTATE/PDOException/Stack trace. - 🧪 Gesamtlauf am 2.10.: alle 20 Offline-Suiten grün; VM-Suiten
run52,p348,p454,p531,p622. - ❓ Nicht einzeln belegt: die
catch-Zweige für den Wettlauf (zwei gleichzeitige Anlagen). Der Test erreicht nur die Vorab-Prüfung; ein gleichzeitiger Lauf wurde nicht erzeugt.
4. Offene Punkte, Stand v3.2.1
Unverändert aus dem Stand vom 1.10.: ⬜ Ansible-Rolle, ⬜ DB-Passwort im Pool im Klartext (LoadCredential/Secret-Mount), ⬜ Doktor prüft nur den Pool des WEB_USER, ⬜ nginx-Logformat ohne $request_time.
Aus der Notiz zu v3.2.0 unverändert: ❓ Welchen Outbox-Pfad die Orchestrierung einsammelt; ❓ ein Zertifikat einer echten CA und cred test gegen einen echten Registrar sind nicht belegt.
Erledigt und damit aus der Liste: group add/cred add-Dubletten.