Design discussion: tamper-evident reuse results (hash-chained repair_cache/events)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- javascript, sqlite
Direzione di ricerca
Inizia con l’affermazione relativa al threat-model nel README e ispeziona le superfici append-only repair_cache ed events, insieme a workflow_status. Confronta la catena prev-hash proposta e il controllo in stile workflow_verify con il ciclo di vita esistente del workflow; completato significa avere un design concordato che segnali la prima divergenza senza concatenare i passaggi né aggiungere dipendenze esterne.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
repair_cache rows are inputs to future execution decisions: a reused result bypasses a fresh agent call, and its output flows into downstream nodes. Today the SQLite file has no integrity protection — the README is upfront that the service is "not protected against other local processes". This is not about attackers; it is about agent mistakes: a buggy tool call, a careless script, or a well-meant cleanup that silently edits or drops reuse rows would be undetectable before those rows are trusted again.
Would you be open to a small hash chain over the append-only surfaces?
repair_cacheinserts andeventsare append-only today; chain them prev-hash style (SHA-256 over the canonical row plus the previous head) and keep the chain head whereworkflow_statuscan report it, so a human or the dashboard can check "the results I am about to reuse are the ones earlier runs actually produced"- mutating rows (
steps) stay out of the chain — they change through their lifecycle by design - a
workflow_verify-style call (or an extension ofworkflow_status) recomputes the chain and reports the first divergence instead of a vague mismatch
Constraints we think matter: chain only append-only surfaces; the threat model is accidental mutation, not adversaries; no git, network, or account dependencies. We run a similar append-only hash-chain trail in our own open-source agent-governance engine (sih-engine — NDJSON event trails with prev-hash and a verify sensor), and are happy to work out a full design and a PR if this fits the roadmap — we would rather align on the shape first.
- Lingua principale
- JavaScript
- Stelle
- 17
- Fork
- 13
- Merge medio
- 2g 23h
- PR unite (30g)
- 19
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di MiniMax-AI/MiniMax-Code-Plugins
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
Tutte le issue di MiniMax-AI/MiniMax-Code-Plugins
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
avniproject/avni-client#2135 ·
-
automated broken-link
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
-
agent/security hive/hosted-available-lke648397-260827-5n31 security
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
babalae/bettergi-scripts-list#3674 ·
-
A-Release-Notes C-Editing D-Modest S-Ready-For-Implementation
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
bevyengine/bevy-website#2595 ·