Gegenbuch: Rewind auf signierten Praefix benennbar gemacht (Pentest R178-01)

Das Signatur-Gate faengt Force-Push mit fremder oder unsignierter Historie -
aber ein Rewind auf einen aelteren, echt signierten Stand ist signaturseitig
einwandfrei. Angreifer spult origin/main auf einen frueheren Checkpoint zurueck
und kuerzt die Datenbank passend: alle Signaturen G, Pin korrekt, Reihe
lueckenlos. Ein Notar-Klon mit lokalem Vorlauf merkt es, ein frischer
Auditoren-Klon meldete OK - ausgerechnet im dokumentierten Pruef-Fall.

Das laesst sich im Skript nicht kryptographisch erkennen, die Historie ist echt.
Deshalb zwei Dinge statt eines Scheinfixes: NOTARY_MIN_SEQ als Bezugspunkt (ist
die Reihe kuerzer, Alarm; jeder Lauf nennt die Nummer), und ohne diesen
Bezugspunkt sagt die Erfolgsmeldung ausdruecklich, dass ein Zurueckspulen nicht
erkennbar war.

README: serverseitiger Rewind-Schutz (non-fast-forward verbieten) jetzt als
Pflicht formuliert, samt Begruendung und dem Hinweis, dass ein frischer Klon
den Rewind nicht sieht.

Kleinkram: NOTARY_SIGNER_FINGERPRINT wird beim Einlesen getrimmt (ein
Zeilenumbruch loeste 4/4 Fehlalarme aus, die auf den korrekten Fingerabdruck
zeigten); die "nie gepusht"-Meldung priorisiert Untersuchen statt Pushen.
Beim Testen selbst gefunden: der erste git-Aufruf war ungeschuetzt und warf bei
kaputtem Klon einen Stacktrace.

Verifiziert: Rewind 3->1 mit gekuerzter DB -> frischer Klon ohne Bezugspunkt OK
mit Vorbehalt, mit NOTARY_MIN_SEQ=3 -> Alarm exit 2; Pin mit Zeilenumbruch kein
Fehlalarm; regulaerer Lauf unveraendert.

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

docs/todo.md

@@ -97,6 +97,44 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🔄 Gegenbuch: Rewind auf signierten Praefix benennbar gemacht (Pentest R178-01)** (2026-08-18)
+  - Fund: Mein Signatur-Gate faengt Force-Push mit **fremder oder unsignierter**
+    Historie – aber ein **Rewind auf einen aelteren, echt signierten Stand**
+    ist signaturseitig einwandfrei. Angreifer spult `origin/main` auf einen
+    frueheren Checkpoint zurueck und kuerzt die Datenbank passend: alle
+    Signaturen `G`, Pin korrekt, Reihe lueckenlos. Ein Notar-Klon mit lokalem
+    Vorlauf merkt es; ein **frischer Auditoren-Klon** meldete `OK`, exit 0 –
+    also ausgerechnet im dokumentierten Pruef-Fall.
+  - **Ehrliche Einordnung:** Das laesst sich im Skript nicht kryptographisch
+    erkennen, die Historie ist ja echt. Also zwei Dinge statt eines
+    Scheinfixes:
+    1. `NOTARY_MIN_SEQ` – die zuletzt bekannte Nummer als Bezugspunkt. Ist die
+       Reihe kuerzer, ist das das Bild eines Rewinds → Alarm. Jeder Lauf nennt
+       die Nummer am Ende, damit sie ueberhaupt bekannt sein kann.
+    2. Ohne diesen Bezugspunkt sagt die Erfolgsmeldung jetzt ausdruecklich,
+       dass ein Zurueckspulen **nicht** erkennbar war – „OK“ soll nicht mehr
+       Gewissheit behaupten als vorhanden ist.
+  - README: serverseitiger **Rewind-Schutz (non-fast-forward verbieten)** ist
+    jetzt als Pflicht formuliert, mit der Begruendung warum Signaturpruefung
+    allein dagegen nichts ausrichtet – und mit dem ausdruecklichen Hinweis,
+    dass ein frischer Klon den Rewind nicht sieht.
+  - Kleinkram aus seinem Bericht: `NOTARY_SIGNER_FINGERPRINT` wird beim
+    **Einlesen** getrimmt (ein Zeilenumbruch loeste sonst 4/4 Fehlalarme aus,
+    die auf den *korrekten* Fingerabdruck zeigten); die „nie gepusht“-Meldung
+    priorisiert jetzt **Untersuchen** statt Pushen und nennt den passenden
+    `git log`-Befehl – „pushen“ haette einen falsch signierten Commit dauerhaft
+    in die Kette gebracht.
+  - Beim Testen selbst gefunden: der allererste git-Aufruf war ungeschuetzt und
+    warf bei kaputtem Klon einen Node-Stacktrace – jetzt erklaerende Meldung.
+  - Verifiziert: Rewind 3→1 bei passend gekuerzter DB → frischer Klon ohne
+    Bezugspunkt `OK` **mit Vorbehalt**, mit `NOTARY_MIN_SEQ=3` → **Alarm
+    exit 2**; Pin mit Zeilenumbruch → kein Fehlalarm mehr; regulaerer Lauf
+    unveraendert. Testlabor und Port geraeumt.
+  - Seine Bestaetigungen: Pin-Ableitung faellt bei Key-Literal/GPG-Key-ID
+    korrekt fail-closed aus; der Rollback bei Pin-Mismatch ist vollstaendig,
+    und selbst ein Absturz zwischen Commit und Reset wird vom
+    „nie gepusht“-Check aufgefangen.
+
 - [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