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>

tools/audit-notary/README.md

@@ -39,9 +39,31 @@ Als Cronjob, stündlich:
   CRM_TOKEN=... node /pfad/notary.mjs >> notary.log 2>&1
 ```
 
-**Force-Push serverseitig sperren.** Ohne das ist die Append-only-Eigenschaft
-nur geliehen – wer Schreibrecht auf das Repository erlangt, schreibt die
-Historie sonst einfach um. Bei GitHub/GitLab: Branch-Protection auf `main`.
+**Force-Push serverseitig sperren – das ist Pflicht, nicht Empfehlung.**
+
+Konkret muss der Server **non-fast-forward-Pushes verbieten** (Rewind-Schutz),
+nicht nur „irgendeine" Branch-Protection. Der Grund ist nicht offensichtlich:
+
+Das Skript prüft jede Signatur. Aber ein Angreifer mit Force-Push-Recht muss
+gar nichts fälschen – er kann die Reihe schlicht auf einen **älteren, echt
+signierten Stand zurückspulen** und die Datenbank passend kürzen. Alle
+Signaturen bleiben gültig, der Fingerabdruck stimmt, die Nummerierung ist
+lückenlos. Kryptographisch ist daran nichts auszusetzen; es fehlt nur das Ende.
+
+Ein Notar-Rechner, der die höhere Nummer noch lokal kennt, merkt es. Ein
+**frischer Klon merkt es nicht** – und das ist ausgerechnet der Auditoren-Fall.
+
+Deshalb zusätzlich:
+
+```bash
+# Die zuletzt bekannte Nummer mitgeben – dann fällt ein Rewind auch ohne
+# lokalen Zustand auf. Das Skript nennt sie am Ende jedes Laufs.
+NOTARY_MIN_SEQ=42 node notary.mjs --check
+```
+
+Ohne `NOTARY_MIN_SEQ` weist die Erfolgsmeldung ausdrücklich darauf hin, dass
+ein Zurückspulen nicht erkennbar war. Ein „OK" ohne diesen Zusatz bedeutet
+mehr als eines mit.
 
 ## Der entscheidende Punkt: es wird tatsächlich geprüft