Gegenbuch: Fingerabdruck-Pin verpflichtend und vollstaendig angewandt (R177)

R177-01 (MEDIUM): Der Pin war optional. Ohne ihn war der Vertrauensanker die
gesamte allowed_signers-Menge, nicht der eine Notar-Schluessel: ein zweiter
dort gelisteter Schluessel konnte das Gegenbuch waschen und force-pushen, und
%G? war G. R176-01 hatte "jeder selbst erzeugte Schluessel" geschlossen, "jeder
erlaubte Schluessel" blieb offen. Fix: Pin wird aus user.signingkey abgeleitet;
laesst er sich nicht bestimmen, wird abgebrochen statt die ganze Liste zu
akzeptieren.

R177-02 (MEDIUM): Der Schreib-Lauf prueft den frischen Commit nur auf %G?,
nicht auf den Pin. Ein Notar-Host mit falsch konfiguriertem Schluessel meldete
"beglaubigt" und pushte - und ab da war die Kette dauerhaft rot, behebbar nur
per Force-Push, den die Branch-Protection gerade verhindern soll. Fix:
Pin-Abgleich am frischen Commit vor dem Push, bei Abweichung Ruecknahme.

Kleinkram: NOTARY_ALLOW_LOCAL faerbt Erfolgsmeldungen ein und pusht nicht mehr
ins Leere; CRM-Fehler liefern eine erklaerende Zeile statt Node-Stacktrace.

Verifiziert mit drei SSH-Schluesseln gegen echten Remote: keyC-Angriff -> Alarm
exit 2 auch ohne gesetzten Pin; Schreiblauf mit falschem Schluessel ->
zurueckgerollt, nichts gepusht; CRM nicht erreichbar/401 -> saubere Meldung;
Lokalmodus eingefaerbt; saubere Historie ohne Fehlalarm.

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

docs/todo.md

@@ -97,6 +97,40 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **📌 Gegenbuch: Fingerabdruck-Pin verpflichtend und vollstaendig angewandt (Pentest R177)** (2026-08-18)
+  - **R177-01 (MEDIUM)** – Der Pin war optional. Ohne ihn war der
+    Vertrauensanker die gesamte `allowed_signers`-**Menge**, nicht der eine
+    Notar-Schluessel: Ein zweiter dort gelisteter Schluessel (Kollege,
+    Alt-Key, geteilte Datei) konnte das Gegenbuch waschen, force-pushen – und
+    `%G?` war `G`. Live gezeigt, exit 0. R176-01 hatte „jeder selbst erzeugte
+    Schluessel“ geschlossen, „jeder **erlaubte** Schluessel“ blieb offen.
+    Fix: Pin wird aus `user.signingkey` automatisch abgeleitet
+    (`ssh-keygen -lf` → `SHA256:…`); laesst er sich nicht bestimmen, wird
+    **abgebrochen** statt die ganze Liste zu akzeptieren.
+  - **R177-02 (MEDIUM)** – Der Schreib-Lauf prueft den frischen Commit nur auf
+    `%G?`, nicht auf den Pin. Ein Notar-Host mit falsch konfiguriertem
+    Schluessel meldete „beglaubigt“ und **pushte** – und ab da war die Kette
+    bei jeder Folgepruefung dauerhaft rot, behebbar nur per Force-Push, den
+    die Branch-Protection gerade verhindern soll. Selbst-DoS ohne Signal.
+    Fix: Pin-Abgleich am frischen Commit **vor** dem Push, bei Abweichung
+    Ruecknahme und Abbruch.
+  - Kleinkram aus seinem Bericht: `NOTARY_ALLOW_LOCAL=true` faerbt jede
+    Erfolgsmeldung jetzt ein („nur lokal, kein externer Anker“) und pusht
+    nicht mehr ins Leere; CRM-Fehler (nicht erreichbar, 401/403, kein JSON)
+    liefern eine erklaerende Zeile statt eines Node-Stacktrace.
+  - Verifiziert mit drei SSH-Schluesseln gegen echten Remote: keyC-Angriff
+    (in `allowed_signers`, aber nicht der Notar-Key) → **Alarm exit 2 auch
+    ohne gesetzten Pin**; Schreiblauf mit falschem Schluessel → zurueckgerollt,
+    **nichts gepusht**, keine Geisterzeile; CRM nicht erreichbar / 401 →
+    saubere Meldung, exit 1; Lokalmodus → Erfolgsmeldung eingefaerbt;
+    **saubere Historie: vier Laeufe plus Pruefmodus ohne Fehlalarm**.
+    Alle Testartefakte geloescht, Ports frei.
+  - Seine Antworten uebernommen: (a) `%GF` ist kryptographisch an die Signatur
+    gebunden und nicht faelschbar – Non-Finding; (b) Code 3 bleibt getrennt von
+    Code 2, „ich weiss es nicht“ darf nicht als „Manipulation“ gemeldet werden;
+    (c) „Notar-Host **und** Key kompromittiert“ bleibt bewusst offen – dagegen
+    hilft nur Branch-Protection am Remote, im Skript nicht erzwingbar.
+
 - [x] **🔑 Gegenbuch: nur wirklich vertrauenswuerdige Signaturen, fail-closed ohne Remote (Pentest R176)** (2026-08-18)
   - **R176-01 (HIGH)** – Mein Signatur-Gate akzeptierte `%G?` = `G` **oder**
     `U`. Bei SSH-Signaturen bedeutet `U` woertlich „gute Signatur, aber kein