# MeshForge — experimentelle Offline-Release-Prüfung Die Befehle prüfen lokale signierte Metadaten und Artefaktbytes. Sie laden nichts herunter, installieren nichts und führen nichts aus. Es gibt weiterhin keinen unabhängig bestätigten SteveCo-AI-Release-Fingerprint oder hiermit autorisierte Produktionsrelease. Eine selbst erzeugte Testidentität ersetzt diesen Gate nicht. ## Lokale Dokumente vorbereiten und signieren `release-id` berechnet ohne Schlüsselzugriff IDs für Policy, Manifest-Kandidat, Policy-Transition und lokal provisionierte Transition-Regeln. `release-sign` signiert genau einen typisierten Body und gibt das zugehörige öffentliche signierte Dokument als JSON auf stdout aus. Unterstützte `--kind`-Werte sind `policy`, `manifest`, `review`, `test`, `transition`, `transition-review` und `transition-test`; lokale `transition-rules` werden nur identifiziert, nicht signiert. Eingaben werden weder überschrieben noch automatisch ergänzt; ein vorhandener Verifier-Checkpoint wird nicht geöffnet. ```sh mf release-id --kind policy --file /reviews/policy-body.json mf release-id --kind manifest --file /reviews/manifest-body.json mf release-sign --kind policy --file /reviews/policy-body.json --data /protected/release-root mf release-sign --kind manifest --file /reviews/manifest-body.json --data /protected/release-maintainer mf release-sign --kind review --file /reviews/review-body.json --data /protected/release-reviewer mf release-sign --kind test --file /reviews/test-body.json --data /protected/release-tester ``` Die Body-Schemata und ihre verbindliche Feldreihenfolge stehen im [Release-Protokoll](../protocol/RELEASE-EXPERIMENTAL.md). Einrückung ist erlaubt; unbekannte/mehrfache Felder, Schreibweisen-Aliase, nachgestellte JSON-Daten und ungültige Body-Werte werden abgewiesen. Die Datei muss regulär, höchstens 1 MiB groß und darf kein Symlink sein. Ein `release-id` für Review/Test ist nicht definiert: Diese Belege referenzieren bereits eine Manifest-Kandidaten-ID. `--data` ist beim Signieren ausdrücklich erforderlich, hat keinen Node-Default und bezeichnet einen **vorhandenen** geschützten Schlüsselordner im [beschriebenen lokalen Format](KEY_STORAGE.md). Fehlende Schlüssel werden nicht erzeugt. Separate Release-/Reviewer-Schlüssel verwenden; einen laufenden Node-Key nicht allein wegen seiner Verfügbarkeit zur Release-Autorität erklären. Signieren prüft Form und Schlüsselkonsistenz, **keine Delegation oder Freigabe**. Ein signiertes Dokument kann deshalb für die gewünschte Policy unautorisiert oder zeitlich ungültig sein. Die getrennte Verifikation entscheidet darüber. Weitere Mitzeichner signieren denselben unveränderten Body; die öffentlichen Signaturen werden nach Schlüssel sortiert in das vollständige kanonische Bundle übernommen. Der Signierbefehl sammelt keine fremden Signaturen und behauptet keine Testausführung. Private Schlüssel erscheinen nicht in der Ausgabe. Eine neu erzeugte Identität begründet weiterhin kein unabhängig bestätigtes Founder-Vertrauen. `release-bundle` setzt diese **öffentlichen** signierten Dateien ohne zusätzliche Werkzeuge zu kanonischen Bundle-Bytes auf stdout zusammen: ```sh mf release-bundle --policy /reviews/root-1-policy.json --policy /reviews/root-2-policy.json --manifest /reviews/signed-manifest.json --review /reviews/signed-review.json --test /reviews/signed-test.json ``` Alle vier Flags sind wiederholbar. Policy-/Manifest-Mitzeichner müssen exakt denselben Body signiert haben. Signaturen werden nach Schlüssel sortiert; doppelte Unterzeichner bzw. doppelte Test-Unterzeichner/Art-Paare werden abgewiesen. Manifest/Reviews/Testbelege müssen auf die enthaltene Policy bzw. denselben Kandidaten verweisen. Grenzen: 16 Policy-, 64 Manifest-, 64 Review- und 128 Testdateien, zusammen höchstens 1 MiB gelesene Eingabebytes. Die Ausgabe ist das strikte Protokoll-JSON ohne nachgestellten Zeilenumbruch. Fehlende Reviews sind zum frühen Beobachten zulässig. **Zusammenstellen verifiziert keine Signatur oder Autorität**; auch ein syntaktisch passendes Bundle muss anschließend durch `release-observe` bzw. `release-verify`. Bestehende Dateien bleiben unverändert. ## Separat vertrauenswürdige Konfiguration Die lokale `trust.json` stammt vom Betreiber und einem unabhängig bestätigten Root-Kanal, niemals ungeprüft vom Download-Peer oder aus demselben Bundle. Feldreihenfolge ist verbindlich, Einrückung erlaubt, Duplikate/Unbekanntes verboten. Das folgende **Schema-Beispiel enthält absichtlich ungültige Platzhalter**: ```json { "root_keys": ["INDEPENDENTLY_CONFIRMED_BASE64URL_ROOT_1", "INDEPENDENTLY_CONFIRMED_BASE64URL_ROOT_2"], "root_threshold": 2, "product": "meshforge", "channel": "stable", "os": "linux", "arch": "amd64", "protocol": "dop/1", "minimum_risk": "security", "max_artifact_bytes": 134217728 } ``` Public Keys sind kanonische unpadded Base64url-Ed25519-Keys. Kein privater Key gehört in diese Datei. Plattform/Architektur und Protokoll bezeichnen das erwartete Artefakt und müssen nicht der Maschine entsprechen, auf der offline geprüft wird. `minimum_risk` ist `documentation`, `normal` oder `security`; eine niedrigere signierte Risikoklasse wird abgewiesen. Die Klassifizierung ist eine verantwortete menschliche/Policyentscheidung, keine automatische Analyse der Patch-Sicherheit. ## Befehle Ein bereits vorhandenes geschütztes State-Verzeichnis wählen; niemals bestehenden Checkpoint löschen oder umbenennen, um Rollback-/Review-Schutz zu umgehen. ```sh mf release-trust-init --trust /trusted/trust.json --state /trusted/release-state mf release-observe --trust /trusted/trust.json --state /trusted/release-state --bundle /downloads/release.bundle.json mf release-verify --trust /trusted/trust.json --state /trusted/release-state --bundle /downloads/release.bundle.json --artifact /downloads/meshforge ``` `release-trust-init` erstellt exklusiv einen neuen Checkpoint mit gebundenen Roots, Schwelle, Ziel und Limits. Er ersetzt keinen vorhandenen oder korrupten State. `release-observe` authentifiziert vorhandene Metadaten und merkt den ersten lokalen Beobachtungszeitpunkt; die Ausgabe `observed_not_authorized` ist keine Freigabe. Reviews können noch fehlen, und die policydefinierte Frist beginnt frühestens beim ersten lokalen Beobachten des exakten Kandidatenhashes. `release-verify` prüft sämtliche erforderlichen Signaturen, Delegationen, Gruppen, Testbelege, Fristen und den vollständigen begrenzten Artefaktstream. Erst danach wird der aktuelle Checkpoint unter Prozesslock erneut geprüft und fortgeschrieben. Die Ausgabe `verified_bytes_only_not_installed` gilt für die tatsächlich gelesenen Bytes; ein später veränderter Dateipfad ist damit nicht autorisiert. Ein Warte- oder Fehlerergebnis ist keine Freigabe. Ein manipulierter Binärinhalt bewegt den Accepted-Checkpoint nicht. Bereits akzeptierte unveränderte gültige Kandidaten können idempotent geprüft werden. ## Persistenz und Grenzen Bekannte gültig signierte Ablehnungen und negative Testbelege bleiben bis zum Kandidatenablauf erhalten; ein späteres Bundle kann sie nicht durch Weglassen rückgängig machen. Gefälschte negative Belege verändern den State nicht. Begrenzte Pending-/Negativdaten verdrängen keine lebenden Ablehnungen; Überlast führt zu Ablehnung beziehungsweise zeitbegrenzter Quarantäne. Der Verifier behauptet nicht, alle weltweit existierenden Reviews gesehen zu haben. Initial wird ausschließlich Policy-Sequenz 1 akzeptiert und ihr Hash gepinnt. Ohne ausdrücklich bei Initialisierung provisionierte `transition_rules` bleiben Policywechsel gesperrt. Der optionale [Governance-Ablauf](GOVERNANCE_CLI.md) erfordert ein stärkeres Rootquorum, alte Security-Delegierte als Reviewer/Testsigner und unveränderliche lokale Floors; er erhält die Release-Historie. Rootrotation und Emergency-Bypass bleiben deaktiviert. Eine nach Aktivierung später gelernte gültige Ablehnung der Transition erzeugt eine terminale Quarantäne ohne sicheren Recoverypfad. Ein neuer State-Ordner ist kein sicherer Ersatz für eine fehlende Migration. Versionierte lineare Release-Nachfolger müssen zum akzeptierten Vorgänger passen; ein anderer Kandidat derselben Sequenz oder ein Rücksprung wird abgewiesen. Trusted Filesystem und Uhr bleiben Voraussetzungen. Privilegierter vollständiger State-Rollback ist ohne externe monotone Vertrauensquelle nicht erkennbar. Gruppen- Unabhängigkeit und tatsächliche Qualität externer Testreports sind nicht allein kryptografisch beweisbar; signierte Reporthashes belegen die jeweilige Aussage. Peerzahlen/Sterne spielen keine Rolle. Keine externe Sicherheitsabnahme, keine Root-Trust-Bootstrap-, Installer-, Auto-Update- oder Produktionsfreigabebehauptung. [Protokoll](../protocol/RELEASE-EXPERIMENTAL.md), [Release-Policy](RELEASE_POLICY.md), [Bedrohungsmodell](THREAT_MODEL.md).