nexo312/trading-system-docs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trading-system-docs/tolaria/tolaria-write-auth/AUTH3A_HUMAN_APPROVAL_AUTHENTICITY_GAP.md
Red Queen a11c1bbe53 AUTH.3A: C5 Caller Auth Integration (SAVE/DELETE Credential, fail-closed, Tests, Sensitivity, Gap-Doku) 
- rq_c5c.py: TolariaClient save_token/delete_token DI, _require_token fail-closed,
  write()/delete() senden Bearer (SAVE/DELETE), read()/list() ohne Credential
- rq_c5_cli.py: _delete_executor liest nur DELETE-Credential (Least Privilege)
- test_c5c.py: write()-Tests injizieren synthetisches SAVE-Token
- test_c5_auth3a.py: isolierte AUTH.3A-Testsuite (19 Tests, Fake/Mock Tolaria)
- auth3a-sensitivity.sh: 8 Sensitivitaets-Mutationen (A-H) -> ROT
- AUTH3A_HUMAN_APPROVAL_AUTHENTICITY_GAP.md: Gap dokumentiert (OPEN, nicht repariert)

Keine echten Tokens. Keine ENV-Mutation. Kein Deployment. Keine produktive Auth-Aktivierung.
2026-08-27 08:42:26 +00:00

2.3 KiB
Raw Blame History

AUTH.3A — HUMAN APPROVAL AUTHENTICITY GAP (Dokumentation)

Status: OPEN (nicht in AUTH.3A repariert — bewusste Scope-Begrenzung) Mission: AUTH.3A (C5 Caller Auth Integration) Datum: 2026-08-27

Gap-Beschreibung

Der bekannte PRE_HERMES-Gap:

  • approved_by="human:christian" ist ein frei waehlbares CLI-Argument (rq_c5_cli.py, --approved-by mit Default "human:christian").
  • Es gibt keine kryptographische Bindung der Human-Approval an Christian (keine Signatur, kein Nonce-Beweis, kein Out-of-Band-Verifikationskanal).

Das bedeutet: Ein Angreifer mit Schreibzugriff auf die C5-DB (oder auf den CLI-Aufruf) koennte eine Approval mit approved_by="human:christian" faelschen, ohne dass dies kryptographisch nachweisbar waere.

Scope-Begrenzung (AUTH.3A)

AUTH.3A repariert diesen Gap NICHT. Gruende:

  1. AUTH.3A ist strikt auf C5-Caller-Auth-Integration begrenzt (SAVE-/DELETE-Credential fuer die legitimen Writer).
  2. Die Approval-Authenticity ist ein eigenstaendiges Security-Thema (eigene Mission, eigene Freigabe durch Christian).
  3. Keine Scope-Ausweitung ueber die AUTH.3A-Freigabe hinaus.

Was AUTH.3A sicherstellt (in Bezug auf DELETE)

AUTH.3A fuegt dem DELETE-Pfad ein zweites, unabhaengiges Gate hinzu:

  • Gate 1 (bestehend): gueltige persistierte Human-Approval (DeleteExecutor._validate_approval — Approval existiert, APPROVED, bindet exakt Commit/Objekt/Pfad).
  • Gate 2 (AUTH.3A, neu): gueltiges DELETE-Credential (TolariaClient._require_token — fail-closed, kein Request ohne Token).

Beide Gates sind zwingend und unabhaengig:

  • DELETE-Credential ersetzt NIE die Human-Approval.
  • Human-Approval ersetzt NIE das DELETE-Credential.
  • Fehlt eines von beiden → FAIL CLOSED (kein Request gesendet).

Verbleibende Luecke (nicht in AUTH.3A)

Die Authentizitaet der Human-Approval selbst (dass sie wirklich von Christian stammt) bleibt ungeloest. Das DELETE-Credential schuetzt vor unautorisierten Ausfuehrern, aber nicht vor einer gefaelschten Approval.

Kennung

HUMAN_APPROVAL_AUTHENTICITY_GAP = OPEN

Naechste Schritte (separate Freigabe erforderlich)

  • Eigene Security-Mission zur kryptographischen Bindung der Human-Approval an Christian (z. B. Signatur, Nonce-Beweis, Out-of-Band-Verifikation).
  • Kein Teil von AUTH.3A / AUTH.3B / AUTH.4.