Red Queen
a11c1bbe53
- 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.
62 lines
2.3 KiB
Markdown
62 lines
2.3 KiB
Markdown
# 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.
|