Neuberechnung der Kette als eigene Gegenbuch-Alarmbedingung (R186 Frage b)
Der Tester fragte praezise: Loest cleanup -> rehash OHNE erneutes Siegeln, ueber NICHT versiegelten Inhalt, etwas Automatisches aus - oder nur die Prosa in verify, die ein Mensch lesen muss? Gemessen statt behauptet: Es loeste bereits aus, aber als Nebenwirkung. Ein Rehash aendert jeden Hash, also stimmt der beglaubigte Kettenkopf nicht mehr und der bestehende Vergleich schlug an. Das funktioniert, ist aber ein Zufallstreffer - verschoebe sich der Anker, waere der Melder lautlos weg. Und die Meldung hiess "Eintrag wurde veraendert" statt "die Kette wurde neu berechnet", also Wirkung statt Ursache. Jetzt haengt der Alarm an der Sache selbst: Das Gegenbuch fuehrt rehashCount/rehashLast im Buch mit und meldet jede neue Neuberechnung seit der letzten Beglaubigung mit exit 2, samt Zeitpunkt, Zeilenzahl und dem Befund, der unmittelbar davor galt. Dieselbe Lehre wie R184-01 (Gate am Ausloeser statt an der Wirkung) und R185-01 (Wurzelwechsel statt valid). Reihenfolge geaendert, und das war noetig: Der neue Melder steht VOR dem Kopf-Hash-Vergleich, sonst haette immer die unpraezisere Meldung gewonnen. Und der Kopf-Vergleich wird nach einer bestaetigten Neuberechnung uebersprungen - sonst waere die Bestaetigung wertlos, weil ein Rehash den Kopf zwangslaeufig aendert. Beim Bauen aufgefallen, nicht im Entwurf. NOTARY_REHASH_ACK wird mit der ID des Rehash-Eintrags bestaetigt, nicht mit true; IDs steigen streng, ein stehen gelassener Wert passt beim naechsten Vorgang nicht mehr. Ein fehlender beglaubigter Eintrag alarmiert weiterhin immer: bestaetigt wird die Neuberechnung, nicht das Verschwinden von Zeilen. Getestet mit echtem Gegenbuch gegen ein echtes CRM, SSH-signiertes lokales Buch: Waesche ohne Datenbankzugriff -> CRM meldet valid:true und chainGaps:[], Gegenbuch exit 2 mit der Neuberechnung als Ursache. Falsche Ack-ID weiter exit 2, richtige exit 0, Folgelauf ruhig. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 5
@@ -153,6 +153,17 @@ const SEAL_ACK = (process.env.NOTARY_SEAL_ACK || '').trim();
|
||||
const siegelBestaetigt = (wurzel) =>
|
||||
SEAL_ACK.length >= 16 && !!wurzel && wurzel.startsWith(SEAL_ACK);
|
||||
|
||||
// Bestaetigung fuer eine Neuberechnung der Kette (Pentest R186, Frage (b)).
|
||||
//
|
||||
// Bestaetigt wird mit der ID des juengsten Rehash-Eintrags. IDs steigen
|
||||
// streng, ein stehen gelassener Wert passt also beim naechsten Rehash nicht
|
||||
// mehr - dasselbe selbstentwertende Prinzip wie bei NOTARY_SEAL_ACK, nur mit
|
||||
// einem Wert, den man vorlesen kann.
|
||||
const REHASH_ACK = (process.env.NOTARY_REHASH_ACK || '').trim();
|
||||
// Wurde in diesem Lauf eine Neuberechnung ausdruecklich bestaetigt? Dann ist
|
||||
// der veraenderte Kettenkopf die erwartete Folge und kein eigener Befund.
|
||||
let rehashBestaetigt = false;
|
||||
|
||||
if (!CRM_URL) {
|
||||
console.error('CRM_URL muss gesetzt sein.');
|
||||
process.exit(1);
|
||||
@@ -755,6 +766,17 @@ const letzter = bisher[bisher.length - 1];
|
||||
if (!CRM_TOKEN) await anmelden();
|
||||
const aktuell = await hole('/api/audit-logs/checkpoint');
|
||||
|
||||
// Die Vollpruefung wird IMMER geholt, auch beim allerersten Lauf: Aus ihr
|
||||
// stammt die Zahl der protokollierten Neuberechnungen, und die gehoert schon
|
||||
// in den ersten Eintrag - sonst gaebe es beim zweiten Lauf keine Grundlage,
|
||||
// gegen die sich ein neuer Rehash abheben koennte.
|
||||
const pruefung = await hole('/api/audit-logs/verify', 'POST');
|
||||
const rehashListe = Array.isArray(pruefung?.rehashes) ? pruefung.rehashes : null;
|
||||
const rehashAnzahl = rehashListe ? rehashListe.length : null;
|
||||
const rehashLetzte = rehashListe && rehashListe.length
|
||||
? rehashListe[rehashListe.length - 1].id
|
||||
: null;
|
||||
|
||||
if (letzter) {
|
||||
if (aktuell.maxId !== null && aktuell.maxId < letzter.maxId) {
|
||||
alarm(
|
||||
@@ -767,7 +789,6 @@ if (letzter) {
|
||||
// Eintraege endgueltig loeschen und die Luecken per Tombstone als „erklaert“
|
||||
// ausweisen – die Meldung liest sich dann harmlos. Fuer das Gegenbuch zaehlt
|
||||
// das Feld, nicht der Satz.
|
||||
const pruefung = await hole('/api/audit-logs/verify', 'POST');
|
||||
if (pruefung && pruefung.valid === false) {
|
||||
alarm(
|
||||
'Die Prüfung im CRM meldet die Kette als NICHT unversehrt (valid: false).\n' +
|
||||
@@ -779,8 +800,77 @@ if (letzter) {
|
||||
}
|
||||
|
||||
const rueck = await hole(`/api/audit-logs/checkpoint?atId=${letzter.maxId}`);
|
||||
// Ein fehlender beglaubigter Eintrag ist IMMER ein Befund - auch wenn eine
|
||||
// Neuberechnung bestaetigt wurde. Bestaetigt wird der Rehash, nicht das
|
||||
// Verschwinden von Zeilen.
|
||||
if (rueck.atHash === null) alarm(`Der beglaubigte Eintrag ${letzter.maxId} existiert nicht mehr.`);
|
||||
if (rueck.atHash !== letzter.chainHead) {
|
||||
|
||||
// ---------------------------------------------------------------
|
||||
// Neuberechnung der Kette (Rehash) als EIGENE Alarmbedingung.
|
||||
//
|
||||
// Ein Rehash wurde bisher nur als Nebenwirkung gefangen: Er aendert jeden
|
||||
// Hash, also stimmt der beglaubigte Kettenkopf nicht mehr und der Vergleich
|
||||
// weiter oben schlaegt an. Das funktioniert - aber es ist ein Zufallstreffer
|
||||
// und keine gebaute Warnung. Verschoebe sich der Anker irgendwann (anderer
|
||||
// beglaubigter Wert, anderer Vergleich), waere der Melder lautlos weg.
|
||||
//
|
||||
// Deshalb haengt der Alarm jetzt an der Waffe selbst, nicht an ihrer Spur -
|
||||
// dieselbe Lehre wie R184-01 (Gate am Ausloeser statt an der Wirkung) und
|
||||
// R185-01 (Wurzelwechsel statt `valid`).
|
||||
//
|
||||
// Das Restrisiko, das dieser Melder abdeckt: `cleanup` + `rehash` OHNE
|
||||
// erneutes Siegeln, ueber Inhalt, der gar nicht versiegelt ist. Dort greift
|
||||
// weder das Bestandssiegel noch der Wurzelwechsel.
|
||||
if (rehashAnzahl !== null && typeof letzter.rehashCount === 'number') {
|
||||
if (rehashAnzahl > letzter.rehashCount) {
|
||||
const neue = rehashAnzahl - letzter.rehashCount;
|
||||
if (REHASH_ACK && String(rehashLetzte) === REHASH_ACK) {
|
||||
rehashBestaetigt = true;
|
||||
console.log(
|
||||
`Neuberechnung bestätigt (NOTARY_REHASH_ACK=${REHASH_ACK}). ` +
|
||||
'NOTARY_REHASH_ACK danach wieder leeren.',
|
||||
);
|
||||
} else {
|
||||
const l = rehashListe[rehashListe.length - 1];
|
||||
const vb = l.vorbefund;
|
||||
alarm(
|
||||
`Die Hash-Kette wurde neu berechnet (${neue} neue${neue === 1 ? 'r' : ''} Vorgang` +
|
||||
`${neue === 1 ? '' : 'e'} seit der letzten Beglaubigung).\n` +
|
||||
` zuletzt: ${l.zeitpunkt} (Eintrag ${l.id}, ${l.neuBerechnet} Zeilen)\n` +
|
||||
(vb
|
||||
? ` Befund unmittelbar davor: ${vb.manipuliert} beanstandet, ${vb.luecken} Lücken\n`
|
||||
: ' Der Zustand davor ist nicht mehr feststellbar.\n') +
|
||||
(l.signiert ? '' : ' ACHTUNG: Dieser Rehash-Eintrag trägt keine gültige Signatur.\n') +
|
||||
'Ein Rehash verknüpft alle Einträge neu. Lücken, die vorher eine Löschung\n' +
|
||||
'sichtbar gemacht hätten, verschwinden dabei aus der Kette – die Prüfung im CRM\n' +
|
||||
'meldet danach wieder „lückenlos". Genau deshalb ist das hier ein Alarm und\n' +
|
||||
'kein Hinweis.\n' +
|
||||
'War es geplant, bestätigen und danach wieder leeren:\n' +
|
||||
` NOTARY_REHASH_ACK=${rehashLetzte}`,
|
||||
);
|
||||
}
|
||||
}
|
||||
} else if (rehashAnzahl !== null && typeof letzter.rehashCount !== 'number') {
|
||||
// Gegenbuch aus der Zeit vor diesem Melder: Es gibt keine Grundlage, gegen
|
||||
// die sich etwas abheben koennte. Stillschweigend zu alarmieren waere ein
|
||||
// Fehlalarm bei jedem Bestandsbuch; stillschweigend zu uebernehmen waere
|
||||
// eine unsichtbare Annahme. Also: uebernehmen und es sagen.
|
||||
console.log(
|
||||
`Grundlage für die Rehash-Überwachung wird gesetzt: ${rehashAnzahl} protokollierte ` +
|
||||
'Neuberechnung(en) im CRM. Ab dem nächsten Lauf fällt jede weitere auf.',
|
||||
);
|
||||
}
|
||||
|
||||
|
||||
// Der Kopf-Hash-Vergleich steht bewusst NACH der Rehash-Pruefung.
|
||||
//
|
||||
// Zwei Gruende: Erstens benennt der Rehash-Alarm die Ursache, waehrend
|
||||
// „Eintrag wurde veraendert“ nur die Wirkung beschreibt - bei gleicher Lage
|
||||
// ist die praezisere Meldung die nuetzlichere. Zweitens aendert eine
|
||||
// Neuberechnung ZWANGSLAEUFIG jeden Hash; stuende dieser Vergleich davor
|
||||
// oder ungeschuetzt dahinter, liesse sich eine bestaetigte Neuberechnung nie
|
||||
// aufloesen und die Bestaetigung waere wertlos.
|
||||
if (rueck.atHash !== letzter.chainHead && !rehashBestaetigt) {
|
||||
alarm(
|
||||
`Der Eintrag ${letzter.maxId} wurde nachträglich verändert.\n` +
|
||||
` beglaubigt: ${letzter.chainHead}\n jetzt : ${rueck.atHash}`,
|
||||
@@ -910,6 +1000,9 @@ const eintrag = {
|
||||
chainHead: aktuell.chainHead,
|
||||
sealRoot: aktuell.sealRoot,
|
||||
sealLeafCount: aktuell.sealLeafCount,
|
||||
// Grundlage fuer die Rehash-Ueberwachung des naechsten Laufs.
|
||||
rehashCount: rehashAnzahl,
|
||||
rehashLast: rehashLetzte,
|
||||
};
|
||||
const neuerInhalt = [...bisher, eintrag].map((e) => JSON.stringify(e)).join('\n') + '\n';
|
||||
|
||||
|
||||
Reference in New Issue
Block a user