Nachweis selbst pruefen

Schritt 1 — Werkzeug herunterladen

In einen leeren Ordner:

curl -O https://bewusstki.de/downloads/verify-bundle/verify.js
curl -O https://bewusstki.de/downloads/verify-bundle/package.json
npm install

verify.js ist der komplette, unabhaengige Pruefcode — kein vorgefertigtes Binary, kein Netzwerkzugriff waehrend der eigentlichen Pruefung. Der Quelltext liegt zusaetzlich offen unter github.com/Alex-Proof/alex-mrtb-verify-bundle.

Schritt 2 — Am Beispiel ausprobieren, bevor es zaehlt

curl -O https://bewusstki.de/downloads/verify-bundle/sample-bundle.json
curl -O https://bewusstki.de/downloads/verify-bundle/invalid-tampered-bundle.json
node verify.js sample-bundle.json
node verify.js invalid-tampered-bundle.json

Erwartung: das erste Paket liefert ein gruenes verified, das zweite (absichtlich nachtraeglich veraendert) liefert invalid_signature. Erst wenn beides wie erwartet aussieht, macht es Sinn, ein echtes Paket zu pruefen.

Schritt 3 — Ein echter Auftrag: PR #37

PR #37 ist eine tatsaechlich von ALEX ausgefuehrte, oeffentlich sichtbare Aufgabe — Freigabe, RFC-3161-Zeitstempel und die Bestaetigung eines unabhaengigen Beobachters gleichzeitig, nicht gemergt, aber komplett einsehbar: github.com/Alex-Proof/alex-controlled-agent-demo/pull/37.

curl -O https://bewusstki.de/downloads/verify-bundle/demo-pr-37.json
node verify.js demo-pr-37.json

Schritt 4 — Historischen Schluessel nachschlagen

Der aktuelle Trust-Anchor gilt nur ab seinem eigenen valid_from. Unter trust_anchor_registry.revocations[] im selben Dokument steht fuer jeden abgeloesten Schluessel ein eigener Eintrag mit key_id und public_key_pem — den passenden per signer_key_id suchen:

curl -s https://bewusstki.de/.well-known/alex-pubkey.json -o pubkey.json
node -e "
const pubkey = require('./pubkey.json');
const bundle = require('./demo-pr-37.json');
const revocations = pubkey.trust_anchor_registry.revocations;
function resolve(keyId, activeId, activePem, outFile) {
  const pem = keyId === activeId ? activePem : (revocations.find(r => r.key_id === keyId) || {}).public_key_pem;
  if (!pem) throw new Error('kein passender Schluessel fuer ' + keyId + ' gefunden');
  require('fs').writeFileSync(outFile, pem);
}
resolve(bundle.signer_key_id, pubkey.key_id, pubkey.public_key_pem, 'historical-key.pem');
resolve(bundle.approval_attestation.signer_key_id, pubkey.approval_signer.key_id, pubkey.approval_signer.public_key_pem, 'historical-approval-key.pem');
"
node verify.js demo-pr-37.json historical-key.pem historical-approval-key.pem

Jetzt VERIFIED: Signatur, Hash-Kette, RFC-3161-Zeitstempel und der Diff gegen den echten GitHub-Commit stimmen. Derselbe Ablauf funktioniert unveraendert fuer PR #31, #33, #35, #36, #38 und #39 — nur PR-Nummer und heruntergeladene Datei aendern sich. Die Registry fuehrt zwei Rotationen zurueck (Server-Umzug 14.09.2026, KMS-Migration 04.09.2026); je aelter das Paket, desto weiter zurueck der passende Eintrag.

Schritt 5 (tiefer) — Den Diff selbst gegen GitHub nachrechnen

VERIFIED oben beweist: Signatur und Hash-Kette sind in sich stimmig. Es beweist noch nicht, dass der im Paket signierte Diff auch tatsaechlich der Diff ist, den GitHub fuer denselben Commit zeigt. Ein Skript, das genau das zusaetzlich nachrechnet (Klon des Verifiers, Klon des Demo-Repos, echter git diff, SHA-256-Vergleich), ohne Vorbedingungen ausser bash/curl/git/Node:

curl -O https://raw.githubusercontent.com/Alex-Proof/alex-mrtb-verify-bundle/main/prove-pr-37.sh
bash prove-pr-37.sh

Beweist Integritaet und die Uebereinstimmung des signierten Diffs mit GitHub. Ob die Loesung den Auftrag fachlich erfuellt, entscheidet weiterhin die menschliche Review.

Schritt 6 — Receipt-System v1: Verdict direkt auf GitHub ansehen

Seit 16.09.2026 haengt ALEX zusaetzlich zum Bundle ein strukturiertes Verdict-Objekt an den Pull Request - als echter GitHub-Check, nicht nur als Kommentar. Am kuratierten Beispiel-Repo alex-receipt-demo: PR ansehen ↗, Reiter „Checks" → „ALEX Evidence Receipt" ↗ zeigt VERIFIED · review · 6/6 mit sechs Einzelposten (Requested scope, Granted permissions, Changed files, Tests/CI, Dependencies, Independent verification).