Sicherheitsgrenzen

memories 0.1 ist Entwicklungssoftware. Betrachten Sie eine bestandene Testsuite nicht als unabhängige Sicherheitsprüfung oder Sicherheitszertifizierung für den Produktivbetrieb.

Schutz vor

Einem Tresor-Synchronisierungsrelay, das Asset-Inhalte liest oder fälscht, nach ausdrücklicher Fingerabdruckprüfung eine Gegenstellenidentität austauscht oder authentifizierten Chiffretext verändert.
Dem Lesen einer kopierten lokalen Datenbank ohne das lokale Passwort oder, bei ausdrücklicher Einrichtung, den separaten Wrapping-Schlüssel für unbeaufsichtigten Zugriff. Der lokale Faktor auf Mobilgeräten hängt zusätzlich vom sicheren Speicher der Plattform ab.
Einem Leser, der Schreibvorgänge fälscht, einem Administrator, der die Eigentümerschaft ändert, oder einem widerrufenen Gerät, das mit seinem Benutzeridentitätsschlüssel selbst ein neues autorisiertes Gerät ausstellt.
Einer gewöhnlichen CLI/MCP-Nutzung, die versehentlich gespeicherte Zugangsdaten ausgibt, ein Passwort auf der Kommandozeile akzeptiert oder einer MCP-Berechtigung erlaubt, erhöhte Terminalrechte zu erben. Ausdrückliches unbeaufsichtigtes Lesen von Zugangsdaten liefert absichtlich Klartextbytes.
Unbemerkten Änderungen signierter Revisionen oder Audit-Einträge, Lücken in der Kette und abgeschnittenen Checkpoints relativ zum verbleibenden aktuellen Datenbankzustand.

Bewusste Einschränkungen

Gehostete Self-Service-Konten verwenden gesalzene Argon2id-Passworthashes und unabhängige Tresore; der Betreiber kontrolliert den gehosteten Speicher weiterhin und kann ihn entschlüsseln. Die E-Mail-Registrierung verlangt vor dem Festlegen eines Passworts einen einmalig verwendbaren, ablaufenden Bestätigungscode für das Postfach. Im Benutzernamenmodus gibt es keine verifizierte Kontaktadresse. SMTP verlangt TLS mit Zertifikatsprüfung; Zugangsdaten verbleiben in der geschützten Dienstkonfiguration. Anmeldeberechtigungen laufen nach einer Stunde ab; der Widerruf beim Browser-Logout erfolgt offline nach bestem Bemühen. Authentifizierungsdrosselungen sind prozesslokal, begrenzt und grob: Sie begrenzen CPU-/E-Mail-Missbrauch, sind aber kein verteilter Dienst zur Missbrauchsverhinderung. Konfiguration und Einschränkungen der Wiederherstellung beschreibt docs/center.md.
Memories Web ist ein Client eines gehosteten Centers, kein lokal im Browser verschlüsselter Tresor. Bearer-Token und zurückgegebene Inhalte liegen im Seitenspeicher, werden bei Trennung, Hintergrundwechsel, Verlassen der Seite oder fünf Minuten Inaktivität gelöscht und nicht im Browserspeicher persistiert. Das Löschen von JavaScript-Speicher ist nicht garantiert; Erweiterungen und Debugging-Werkzeuge können ihn untersuchen, und heruntergeladene Dateien bleiben auf dem Datenträger. Token sind an den gewählten HTTPS-Origin gebunden (Loopback-HTTP für die Entwicklung); Weiterleitungen und Cookies sind deaktiviert. Ein erlaubter Web-Origin kann mit einem autorisierten Bearer auf gehostete Inhalts-APIs zugreifen, nicht auf Admin- oder Ticketverwaltungsrouten. CORS ersetzt keine serverseitige Autorisierung. Dem Webhost, der Skripte liefert, wird das Token anvertraut; verwenden Sie das mitgelieferte /app/ des Centers mit demselben Origin, wenn dies die gewünschte Vertrauensgrenze ist. Siehe Anleitung zum Webclient.
Der optionale Hosting-Modus des Centers (memories-center --data) ist ein separater serverseitig verschlüsselter Tresor, kein Ende-zu-Ende-verschlüsselter Gerätespeicher. Das vom Betreiber gehaltene MEMORIES_CENTER_VAULT_PASSWORD öffnet den Store im Daemon-Format; Hostbetreiber und jeder mit Passwort und Datenträger können sämtliche gehosteten Klartexte lesen. Hosted-Grant-RPC ist eine abgeschlossene Schnittstelle für Tresorinhalte mit operationslokaler Rechteerhöhung, einschließlich privater/Datei-/geschützter Schreibvorgänge und ausdrücklicher Zugangsdatenlieferung. Daemon-MCP bleibt ohne erhöhte Rechte und unverändert. Ein Admin-Bearer allein kann keine Tresor-APIs verwenden, aber Administratoren können separate Berechtigungen mit eingeschränktem Umfang oder dauerhafte Mitglieder ausstellen. Die Admin-Sperre im Hosting-Modus verwirft Store-Schlüssel; das Entsperren erfordert das Betreiberpasswort über vertrauenswürdiges HTTPS. Dauerhafte Mitgliedstoken in der nur dem Eigentümer zugänglichen members.json sind Klartext-Zugangsdaten, keine Tresorschlüssel: Schützen Sie ihre Dateien, Sicherungen und einmaligen Antworten. Ein vom Center ausgestelltes Entsperrticket hinterlegt das Gerätepasswort nicht treuhänderisch und erhöht keine Geräte-/MCP-Rechte. Für SaaS konfigurierte Daemon-Clients teilen den injizierten Hosting-Bearer; lokale MCP-Berechtigungen können ihn nicht erben. Die Migration alter Notizen behält eine Klartextdatei memories.json.bak; schützen/entfernen Sie diese nach der Überprüfung. Das vollständige Bedrohungsmodell und die beabsichtigten Unterschiede beschreibt docs/center.md.
Kompromittierte Endpunkte, Betriebssystemadministratoren, bösartige autorisierte Programme, Speicherinspektion, Keylogger und Benutzer, die absichtlich Klartext kopieren, liegen außerhalb der Vertraulichkeitsgrenze. Eigene Rust-Schlüsselpuffer werden mit Nullen überschrieben; für OS-Swap, Crash-Dumps, Speicherallokationen von Abhängigkeiten und von Darts Garbage Collector verwaltete Strings ist das Löschen nicht garantiert. Die Schlüsselverwahrung für unbeaufsichtigten Desktop-Zugriff bietet Backends für Windows DPAPI, macOS Keychain, Linux Secret Service und owner-file. Diese schützen auf Ebene des Betriebssystemkontos, garantieren aber keine hardwaregestützte Verwahrung; owner-file speichert seinen Wrapping-Schlüssel als Klartext, auf den nur der Eigentümer zugreifen darf. Keines der ausgelieferten Backends garantiert hardwaregestützte Schlüsselverwahrung auf dem Desktop.
Das Relay kann Verkehrsmetadaten beobachten, Verbindungen blockieren, Chiffretext selbst aufzeichnen, Widerrufe verzögern oder die Geräteflotte partitionieren. Der ausgelieferte Server schreibt keine Assets, doch ein bösartiger Server kann nicht gezwungen werden, auf Verkehrsaufzeichnung zu verzichten. Tresor-Peer-Synchronisierung (/v1/channel) ist Ende-zu-Ende-verschlüsselt. Remote-Daemon-Relay-RPC (/v1/rpc/{room}/{slot}) überträgt dagegen authentifiziertes JSON: Das Relay oder der TLS-Terminierungspunkt kann das gemeinsame Listen-Token und die Anfrage-/Antwortnutzlasten lesen.
Ein Offline-Widerruf kann frühere Klartexte, Schlüssel oder Sicherungen nicht löschen. Ein Endpunkt, der den Widerruf noch nicht erhalten hat, kann seine alte lokale Kopie weiterhin verwenden. Der Export an ein bekanntermaßen widerrufenes Gerät wird blockiert, und neue Epochen verwenden neue Schlüssel. Ein Widerruf verwirft außerdem eingereihte Cloud-Exporte und macht erfasste Arbeit vor der nächsten Objektoperation ungültig. Eine bereits gestartete Netzwerkanfrage kann nicht zurückgerufen werden.
Das Audit belegt signierte Inhalte und Kontinuität relativ zum bekannten Zustand, nicht, dass ein kompromittiertes Gerät jeden Zugriff aufgezeichnet hat. Der Austausch der gesamten Datenbank und aller lokalen Nachweise gegen eine ältere konsistente Sicherung kann ohne einen neueren Peer-Checkpoint oder externen Anker nicht erkannt werden. Es gibt keinen vertrauenswürdigen Zeitstempeldienst.
Fehlgeschlagene Operationen werden auditiert, wenn eine nutzbare, autorisierte lokale Signieridentität entsperrt ist. Versuche im vollständig gesperrten Zustand werden ratenbegrenzt, erzeugen aber keinen dauerhaften signierten Audit-Eintrag. Abrupte Abstürze hinterlassen zuvor festgeschriebene Liefer-/Ausführungsabsichten, statt Ergebnisse zu erfinden.
Ein Prozess desselben Benutzers befindet sich innerhalb der lokalen Betriebssystemkontogrenze. IPC authentifiziert den Betriebssystembenutzer; die Rechteerhöhung im Terminal nutzt zusätzlich die Eltern-PID. Dies isoliert weder von einem bösartigen Prozess desselben Benutzers noch bietet es eine dauerhafte Sitzungsidentität, die gegen PID-Wiederverwendung immun ist. IPC akzeptiert bis zu 16 gleichzeitige Clients. Windows-Named-Pipe-Framing bleibt blockierend: Stockende Clients desselben Benutzers können diese Plätze belegen, doch ein einzelner stockender Client oder Cloud-Transfer blockiert nicht alle anderen Verbindungen. Unix-Frame-I/O hat begrenzte Fristen. Dienstoperationen, die die Schreibsperre halten, einschließlich vertrauenswürdiger Kindprozessausführung, bleiben serialisiert. Ausführungsbindungen sind die Ausnahme: Der Dienst autorisiert, entschlüsselt und auditiert unter der Sperre und gibt sie dann frei, während das gebundene Programm läuft.
Ausführungsbindungen (credential bind) sind eine bewusste, durch sudo autorisierte Erweiterung der Grenze erhöhter Rechte für ein Programm. Solange eine Bindung nicht abgelaufen ist (standardmäßig 8 Stunden, höchstens 720) und der Store entsperrt ist, kann jeder cli:-Aufrufer desselben Benutzers dieses Programm mit seinen gebundenen Zugangsdaten ohne Rechteerhöhung ausführen. Diese Aufrufer erhalten die Programmausgabe, in der exakte Vorkommen der Zugangsdaten ersetzt wurden, nicht die Zugangsdaten selbst; das Programm, seine Plugins/Erweiterungen und seine Nachfolgeprozesse erhalten jedoch den Klartext und können ihn offenlegen (kodierte Ausgabe, Netzwerk, Dateien). Bindungen sind gerätelokaler verschlüsselter Zustand, werden nie synchronisiert, bei Wiederherstellung einer Sicherung gelöscht und für MCP-, Remote- (ws:/relay:), unbeaufsichtigte und mobile Aufrufer abgelehnt. Deny-Regeln werden vom Dienst für die tatsächlich an das Programm übergebenen Argumente durchgesetzt; Ask-Regeln nur durch den Claude-Code-Hook, der ein Komfort-Router und keine Grenze ist: Ein von ihm übersehener Befehl läuft ohne Zugangsdaten, und ein Prozess desselben Benutzers kann run --binding direkt aufrufen (der Hook prüft auch direkte Aufrufe, die er sehen kann). Alles, was niemals unbeaufsichtigt laufen darf, gehört in eine Deny-Regel.
Optionales HTTP/WebSocket-Listen und Relay-RPC stellen nach Vorlage eines gemeinsamen Geheimnisses dasselbe gerahmte service::Request-Protokoll bereit (WebSocket-Binär-JSON: AuthFrame, dann Wire). Das Listen-Token wird ausschließlich über --listen-token / MEMORIES_LISTEN_TOKEN übergeben (oder erzeugt und einmalig ausgegeben); es wird nie in TOML gespeichert. Der Vergleich erfolgt in konstanter Zeit. Beim Sperren des Stores wird das Token gelöscht. Remote-Aufrufer verwenden stabile Namensräume für erhöhte Rechte, ws:remote / relay:remote, und können die cli:{pid}-Rechteerhöhung eines lokalen Terminals nicht erben; unlock/sudo über diesen Transport erhöht die Rechte des Remote-Namensraums für nachfolgende Einmalverbindungen. Desktop-HTTP-/Relay-Hosts stellen nach unlock/sudo den üblichen lokalen IPC-Operationssatz bereit (einschließlich Run, CryptoJob, MCP-Berechtigungen, Remote-Sitzungen, Proxys, Zugangsdatenkopie und Sicherung), mit denselben Prüfungen erhöhter Rechte. Tokeninhaber sind daher auf diesem Host so mächtig wie ein lokaler Client mit erhöhten Rechten — schützen Sie das Token entsprechend. Mobile FFI und Share behalten die mobile Sperrliste bei (kein Run/CryptoJob/MCP grant/remote/proxy auf dem Telefon; Share verweigert zusätzlich Klartextkopien von Zugangsdaten und Sicherungs-Dumps). HTTP-Listen verwendet standardmäßig Loopback; das Binden an eine Nicht-Loopback-Adresse erfordert --allow-non-loopback und gibt eine Warnung aus. Reines HTTP/WS benötigt keine Zertifikate; --tls-cert / --tls-key aktivieren bei Bedarf HTTPS/WSS. Relay-RPC erfordert für Nicht-Loopback-Relays WSS, eine 43 Zeichen lange Raum-ID mit hoher Entropie und das Listen-Token. Tresorsynchronisierung verwendet weiterhin /v1/channel; direktes RPC verwendet /v1/rpc und Relay-RPC /v1/rpc/{room}/{slot}. Die eingeschränkte WebUI-Schnittstelle ist separat und darf keine allgemeine Request-Brücke werden.
Optionale Autorisierungs-Center ([[centers]]) machen einen Endpunkt zu einem Center-verwalteten Gerät: Lokaler Selbst-Bootstrap (init/restore) und lokales Ausstellen von MCP-Berechtigungen werden verweigert. Bootstrap und Berechtigungen kommen als vom Center signierte Tickets, die gegen konfigurierte public_key-Werte geprüft werden. Berechtigungstickets enthalten bewusst gewählte Geltungsbereiche (allow_all, read, write, read_write, read_write_delete); ältere Tickets mit booleschem write werden auf read / read_write abgebildet. Mehrere Center können konfiguriert werden; bereits eines reicht aus, um Selbst-Bootstrap zu verbieten. Das Entsperren mit Tresorpasswort bleibt lokal — Center verteilen Richtlinien, keine Tresorschlüssel. Schützen Sie Center-Signiergeheimnisse und Admin-Token wie Root-Zugangsdaten. Siehe docs/center.md.
Fingerabdrücke ausführbarer Dateien werden unmittelbar vor dem Start geprüft. Es gibt keine OS-Sandbox, Pflicht zu signiertem Code, atomare Ausführung über Dateihandles oder Eingrenzung von Nachfolgeprozessen. Eine vertrauenswürdige ausführbare Datei kann Plugins laden oder Arbeit delegieren.
Zwischenablagekopien gewöhnlicher/privater Erinnerungen, ausdrücklich kopierte Zugangsdaten und exportierte Dateien verlassen den verschlüsselten Store durch Benutzerhandlung. credential_copy ist eine bewusste lokale, sudo-autorisierte Ausnahme von den Ausgabebeschränkungen für Zugangsdaten: Der authentifizierte Client erhält UTF-8-Klartext für die Systemzwischenablage. Die CLI gibt nur den Kopierstatus aus; auf Mobilgeräten werden Bestätigung und Erfolg angezeigt, ohne das Geheimnis darzustellen. MCP kann keine Kopien anfordern. Zwischenablageinhalte bleiben nach dem Sperren erhalten und können durch OS-Verlauf/-Synchronisierung oder andere Apps aufbewahrt werden; garantiertes Löschen der Zwischenablage gibt es nicht. credential generate erzeugt Schlüsselmaterial im Tresor; seine Generierungsantwort und credential public geben öffentliche Schlüssel oder Zertifikate zurück, niemals private Schlüssel. Ausdrückliches Kopieren von Zugangsdaten kann gespeichertes privates UTF-8-Schlüsselmaterial unter derselben Autorisierungsgrenze an die Zwischenablage liefern. RSA-Schlüssel haben 3072 oder 4096 Bit.
file exec ist ein CLI-seitig autorisierter Dateiexport mit anschließender lokaler Ausführung, der die vorhandene Dateileseberechtigung und Lieferauditierung nutzt. Er kann weder Zugangsdaten lesen noch MCP-/Mobilbefugnisse erweitern. Das vom Benutzer gewählte Programm erhält einen Klartext-Snapshot in einem temporären Verzeichnis, auf das nur der Eigentümer zugreifen darf, erbt CLI-Umgebung und -Streams und kann Inhalte ohne Ausgaberedaktion offenlegen. Kein Fingerabdruck der ausführbaren Datei wird fest angeheftet, ebenso wenig wie beim manuellen Ausführen einer exportierten Datei. Sperren/Widerruf können diese Kopie nicht zurückrufen. Normales Beenden des Kindprozesses, Startfehler und behandelte Unterbrechungen lösen die Entfernung aus; erzwungenes Beenden, Stromausfall oder Schließen der Windows-Konsole können Klartext hinterlassen. Entfernen ist kein sicheres Löschen. Nur der direkte Vordergrund-Kindprozess wird überwacht, keine abgekoppelten Nachfolgeprozesse. Die Dateiausführung hält die Dienstsperre des Daemons nicht.
Der HTTPS-Zugangsdatenadapter unterstützt Bearer und Cookie GET/POST und gibt nur den Status zurück, keine beliebigen Antwortdaten. Vom Daemon verwaltete SSH-, FTP-, TCP-, MySQL-, Redis- und PostgreSQL-Sitzungen erfordern sudo sowie propose/approve/exec für jede Anweisung. Nicht genehmigte Tickets können nicht ausgeführt werden. SSH-Hostschlüssel sind über SHA-256 fest angeheftet. Die SSH-Clientauthentifizierung verwendet ein gespeichertes Passwort oder einen importierten privaten OpenSSH-Schlüssel und kann ein gespeichertes OpenSSH-Zertifikat anhängen. Verschlüsselte private Schlüssel und Signieren per SSH-Agent sind nicht implementiert. Zugangsdaten werden nicht ausgegeben; Remote-Ausgaben sind begrenzt. MCP kann keine Remote-Sitzungen öffnen oder genehmigen. Loopback-SSH- und Datenbankproxys werden mit sudo gestartet, binden ausschließlich an 127.0.0.1 und authentifizieren sich vorgelagert mit gespeicherten Geheimnissen, sodass Agenten niemals Schlüssel erhalten. Jeder Prozess, der den lokalen Port erreichen kann, kann das autorisierte Remote-Konto ohne Genehmigung einzelner Befehle nutzen; Loopback ist keine OS-Benutzerauthentifizierung. Lokaler Datenbankverkehr ist Klartext. Sperren, Ablauf der Tresor-Inaktivitätsfrist und Stop schließen Listener und aktive Verbindungen. Proxys laufen unabhängig von Aktivität nach 30 Minuten ab. MCP kann Proxys weder starten noch auflisten oder stoppen. Jeder Proxy akzeptiert höchstens 16 Verbindungen; die Authentifizierung hat eine Frist von 30 Sekunden und begrenzte Handshake-Pakete. Datenbank-TLS der Proxys verwendet rustls, einschließlich PostgreSQL-/MySQL-Protokollaushandlung. PostgreSQL SCRAM prüft die Serversignatur. Vollständige MySQL-SHA-256-Passwortauthentifizierung wird ohne verifiziertes TLS verweigert; RSA-Passwortaustausch ist nicht implementiert. Weiterleitung von PostgreSQL-Abbruch-/Startoptionen und MySQL-Kompression werden nicht unterstützt. Datenbanksitzungen verwenden standardmäßig Passwortauthentifizierung mit TLS (Hostnamenprüfung; optional zusätzliche PEM-CA-Zugangsdaten). --no-tls ist eine bewusste Wahl. Zertifikat-Pinning und Clientzertifikate sind nicht implementiert.
Berechtigungen gelten für einen gesamten Tresor. Leser können dessen Assets entschlüsseln; die Clientoberfläche kann keine kryptografische Unterscheidung zwischen dem Lesen und dem Kopieren von Inhalten durchsetzen, die einem Mitglied bereits gewährt wurden.

Unbeaufsichtigte Desktop-Befugnis

Unbeaufsichtigte CLI/MCP ist eine separate, ausdrücklich zu aktivierende lokale Bearer-Befugnis, keine gewöhnliche MCP-Berechtigung oder sudo-Sitzung. Die Einrichtung verlangt ein interaktives Terminal, die eingegebene Zustimmung ENABLE, Entsperren mit Passwort und Passwort-sudo. Spätere Lesezugriffe benötigen die ausdrücklich gewählte Clientdatei, keine wiederholten Passwortabfragen. Ihr Tresorgeltungsbereich umfasst gewöhnliche und private Erinnerungen/Karten, ursprüngliche Dateibytes und den Verlauf des aktiven Tresors, einschließlich ausdrücklich angeforderter gespeicherter Zugangsdaten als UTF-8-Klartext. Generische Lesezugriffe lehnen Zugangsdaten ab; Verweise geschützter Karten werden nicht automatisch aufgelöst. Quarantänerevisionen werden verweigert. Es gibt keine Schnittstelle für Asset-Änderungen, Ausführung, Administration, Synchronisierung, Sicherungs-Dumps, Suche/Modellausführung oder Fortschreiben von OTP-Zählern. Aktuelle Gerätemitgliedschaft und Berechtigungsumfang werden bei jedem Lesezugriff geprüft; vor der Ausgabe wird eine signierte Lieferabsicht gespeichert, und Audit-/Speicherfehler verweigern die Lieferung.

Der unabhängige Master-Key-Wrapper bewahrt passwortbasiertes Entsperren/Wiederherstellen. Sein Wrapping-Schlüssel wird separat über ausdrücklich gewähltes windows-dpapi (DPAPI des aktuellen Benutzers), macos-keychain (nicht synchronisierende Keychain) oder linux-secret-service (Secret Service auf dem Sitzungsbus) gehalten. owner-file ist eine bewusst gewählte Option mit geringerem Schutz: Klartext-Wrapping-Material, das nur durch Betriebssystemkonto-Berechtigungen geschützt ist. Es gibt keinen automatischen Fallback. Lesezugriffe beim Start fordern weder Schlüsselbund-Entsperren noch eine Authentifizierungsoberfläche an; nicht verfügbare, gesperrte oder genehmigungspflichtige Schlüsselverwahrung führt zur sicheren Verweigerung. Ein Protokollclient kann beliebiges anbieterspezifisches UI-Verhalten nicht kontrollieren. Diese Backends gewährleisten weder Geheimhaltung gegenüber Prozessen desselben Kontos oder OS-Administratoren noch hardwaregestützte Verwahrung.

Ein erfolgreicher unbeaufsichtigter Start lädt Schlüssel, während die gewöhnliche Autorisierung gesperrt bleibt. Er entsperrt keine gewöhnlichen CLI-/MCP-, sudo-, Cloud- oder RAG-Operationen. Manuelles lock löscht Schlüssel und unterbindet unbeaufsichtigten Start dauerhaft über Neustarts hinweg; Entsperren mit Passwort allein setzt ihn nicht fort. unattended resume verlangt passwortautorisierte Verwaltung im lokalen Terminal. revoke entfernt eine Berechtigung dauerhaft; disable deaktiviert die Befugnis und widerruft alle Berechtigungen vor der Backend-Bereinigung. Ein fehlgeschlagener dauerhafter Schreibvorgang der Sperre gibt einen Fehler zurück, daher kann Persistenz auf einem nicht beschreibbaren Gerät nicht zugesichert werden. Bereits gelieferter Klartext kann durch Sperren, Widerruf oder Deaktivieren nicht zurückgerufen werden.

Die Clientdatei ist eine geheime Bearer-Berechtigung, getrennt von gewöhnlichen MCP-Berechtigungsdateien und an den ausgewählten Store gebunden. Der Wrapping-Schlüssel ist an die kanonische Store-/Header-Identität gebunden. Unbeaufsichtigte Befugnis ist nicht in logischen Sicherungen, Gerätekopplung oder Tresorsynchronisierung enthalten. Das Kopieren der gesamten Rohdatenbank kopiert dennoch ihre zusätzliche Wrapper-/Befugnistabelle; auch das Kopieren von Clientdateien oder Verwahrungsmaterial kann die Befugnis erhalten. Rollback des gesamten Geräts und sicheres Löschen bleiben außerhalb der Garantien. Halten Sie diese Dateien aus Versionsverwaltung, Logs und gemeinsamen Sicherungen heraus.

Center-verwaltete Stores lehnen unbeaufsichtigte Befugnis ab. HTTP/WebSocket, Relay-RPC, mobile FFI/Share und WebUI können diesen Weg auch mit gewöhnlicher Rechteerhöhung nicht nutzen. Die Berechtigungen und Zugangsdatenbeschränkungen von gewöhnlichem mcp serve --grant-file bleiben unverändert. Das separate mcp serve-unattended --client-file legt dem empfangenden Client absichtlich Geheimnisse offen. Base64url ist Kodierung, keine Verschlüsselung: KI-Anbieter, Transkripte, Werkzeuglogs und Caches können dekodierte Geheimnisse oder die kodierten Werte behalten oder übertragen. Nur-Lese-Zugriff macht die Offenlegung von Geheimnissen nicht harmlos.

Die Linux-Ende-zu-Ende-Abdeckung verwendet owner-file-Verwahrung mit dem echten Daemon und CLI/MCP. Die isolierte Linux-Secret-Service-Protokollfixture ist kein Test eines echten Desktop-Schlüsselbunds. Windows DPAPI, macOS Keychain sowie die Prüfung mit echtem Schlüsselbund/nativer Oberfläche ohne UI bleiben Freigabekriterien für Releases; eine unabhängige Prüfung steht aus. Siehe Nutzungs- und Validierungsdetails.

Retrieval- und Modelldienste

BM25-Indizes und normalisierte Vektoren sind begrenzte speicherinterne Caches autorisierter gewöhnlicher Erinnerungen/Karten. Sie werden bei Richtlinien-/Inhaltsänderungen invalidiert und beim Sperren gelöscht. Indizes enthalten niemals Zugangsdatenkörper oder bewusst private Inhalte; Datei-Assets und ungelöste/widersprüchliche Revisionen bleiben ausgeschlossen. Das ausdrückliche Einlesen eines Text-/Markdown-Dokuments erstellt eine gewöhnliche Wissenskarte; der Betreiber darf deshalb keinen vertraulichen Text als gewöhnliche, im Tresor öffentlich zugängliche Daten importieren. Temporärer SQLite-Suchspeicher wird auf Arbeitsspeicher erzwungen; gecachte Inhalte sind nicht in Sicherungen oder Cloud-Exporten enthalten. Die Einschränkungen des Prozessspeichers gelten weiterhin.

Lokales EmbeddingGemma läuft im Prozess mit einer nativen Inferenzbibliothek; seine öffentlichen Modelldateien werden nur durch einen ausdrücklichen Installationsbefehl heruntergeladen oder lokal bereitgestellt. ONNX-Telemetrie wird bewusst deaktiviert, bevor Inferenzsitzungen erstellt werden. Eingebaute Downloads heften eine Repository-Revision fest und prüfen jede Datei vor der Veröffentlichung mit SHA-256. Modelldateien haben ihre eigene Gemma-Lizenz. Sie sind kein geheimes Material und keine unabhängig geprüfte Sicherheitsgrenze.

Das Konfigurieren einer Remote-Embedding-URL erlaubt autorisierten RAG-Operationen, alle geeigneten Dokumentabschnitte an diesen Endpunkt zu senden. Generierung sendet die Frage und ausgewählte Quellabschnitte; gelerntes Reranking sendet seine Kandidaten. Der Kunde muss den konfigurierten Modellanbietern und Proxys vertrauen. Modellschritte mit Nicht-Loopback-Anbietern werden für rein gerätelokale Tresore vor der Inferenz abgelehnt. Lokale Inferenz und ausdrücklich konfigurierte Loopback-Dienste bleiben verfügbar. Gewöhnliche MCP-Clients können Anbieter-URLs, Zugangsdaten oder Proxyeinstellungen nicht in Werkzeugargumenten auswählen und bleiben auf den Tresor und die Berechtigungen für gewöhnliche Inhalte ihrer Berechtigung beschränkt. API-Schlüssel werden über den Namen einer Umgebungsvariable referenziert, niemals als wörtliche Konfigurations- oder CLI-Werte. Fehlerhafte HTTP-Antwortkörper werden unterdrückt, und direkte Wiedergaben von Authentifizierungsmaterial in generierten Antworten werden abgelehnt; ein bösartiger konfigurierter Anbieter bleibt außerhalb der lokalen Vertraulichkeitsgrenze.

Remote-Modell-URLs erfordern HTTPS; HTTP ist nur auf Loopback erlaubt. Weiterleitungen von Modell-APIs werden verweigert. Loopback-Anfragen umgehen Proxys; andere Anfragen können HTTP(S)/SOCKS-Proxys oder die Proxyumgebung nutzen. Wiederholungen sind begrenzt und auf vorübergehende Verbindungs-/Lesefehler, HTTP 429 und ausgewählte 5xx-Antworten beschränkt. Wiederholungen können Modellberechnung/Abrechnung wiederholen. TLS-Prüfung wird nicht deaktiviert.

Modellarbeit hält den Schreibmutex des Dienstes nicht. Sperren, abgelaufene/widerrufene Berechtigungen oder geänderter Quellzustand unterdrücken verspätete Ergebnisse und verhindern nachfolgende Schritte. Eine laufende Anfrage/Inferenz kann zu Ende gehen, und bereits remote offengelegter Text kann nicht zurückgerufen werden. Retrieval-Quellen sind Daten, keine Anweisungen; die Generierung hat keine Anwendungswerkzeuge. Gültige Zitier-IDs beweisen weder die sachliche Fundierung einer Antwort noch beseitigen sie das Prompt-Injection-Risiko durch nicht vertrauenswürdigen Quelltext.

Desktop-Statusdashboard

Lokale TOML-Konfiguration enthält ausschließlich nicht geheime Speicher-/Relay-/Desktop-Einstellungen. Ausdrücklich ausgewählte fehlende Dateien, unbekannte Schlüssel und fehlerhafte Werte werden vor dem Öffnen eines Stores abgelehnt. Relative Speicherpfade werden relativ zum Verzeichnis der ausgewählten Datei aufgelöst. Eine Pfadänderung wählt einen anderen Store und migriert keine Daten. Die Relay-URL-Prüfung behält die vorhandenen Anforderungen an Remote-TLS und das Verbot von Zugangsdaten in URLs bei.

Die optionale WebUI lauscht nur auf 127.0.0.1. GET /api/status und der eingeschränkte Editor POST /api/cards sind durch ein zufälliges 256-Bit-Token geschützt, das für jeden Prozess erstellt wird. Der Launcher legt das Token in das URL-Fragment; die Seite entfernt es aus der Adressleiste, hält es im Sitzungsspeicher des Tabs und verwendet einen Authorization-Header. Die vollständige Start-URL ist eine Dashboard-Berechtigung und sollte nicht geteilt werden. Anfragen mit unerwartetem Host, fremdem Origin oder Cross-Site-Fetch-Metadaten werden verweigert. CORS-Zugriff, Drittanbieterressourcen und Framing werden nicht angeboten. Die Statusprojektion bleibt schreibgeschützt. Kartenbearbeitung nutzt eine separate bewusst gewählte Positivliste in der zugehörigen CLI mit höchstens vier gleichzeitigen Anfragen und einem Anfragegrenzwert von 1 MiB. Sie erlaubt gewöhnliche Karten-/Typoperationen, kein Entsperren, sudo, Dateilesen, Zugangsdatenlesen, Offenlegen von Geheimnissen, Berechtigungen oder Prozessausführung. Private Assets werden vor der Rückgabe von Karteninhalten geprüft. Sensible Felder werden maskiert, und ihr interner strukturierter Körper wird nie zurückgegeben. Biometrie-/PIN-Einrichtung im Browser ist nicht implementiert: Verifizierte native Mobil-/CLI-Wege verarbeiten sensible Werte. Das Start-Token autorisiert jetzt gewöhnliche Kartenschreibvorgänge und Vorlagen-CRUD; schützen Sie es entsprechend. Dies ist keine allgemeine IPC-Brücke.

Der lokale Monitor fragt den Daemon über dessen gewöhnliches authentifiziertes IPC in einem kurzlebigen Unterprozess ab, mit einer Frist von drei Sekunden zur Begrenzung blockierter Windows-Pipe-Lesezugriffe. Er löscht Details bei fehlgeschlagenen Abfragen; Sperren verbirgt Details bei der nächsten Abfrage. Abfragen erneuern weder die Entsperr-Inaktivitätsfrist noch gewähren sie erhöhte Rechte. Desktop-Status bleibt für MCP-Berechtigungen nicht verfügbar. Ein bösartiges Programm im selben Betriebssystemkonto bleibt innerhalb der vorhandenen lokalen Vertrauensgrenze.

Das Tray kann den lokalen Daemon durch eine ausdrückliche Menüaktion starten. Das Schließen von Tray/Dashboard beendet dessen HTTP-Listener und Überwachung; es beendet oder entsperrt keinen unabhängig laufenden Daemon. Authentifizierung bleibt in der CLI.

Kryptografische Desktop-Aufträge

crypto_job erfordert lokale erhöhte Terminalrechte und einen Digest, der den exakten öffentlichen Plan, Eingabe-/Werkzeugfingerabdrücke und Zugangsdatenreferenzen bindet. MCP und mobile FFI können es nicht aufrufen. Zugangsdaten müssen zum autorisierten Tresor gehören. Eine signierte Absicht wird vor externer Ausführung festgeschrieben, und Erfolg/Fehler werden auditiert. Die Werkzeugkette bleibt innerhalb der vertrauenswürdigen Betriebssystemkontogrenze; Hashing ausführbarer Dateien beschränkt keine Bibliotheken, Hilfsprogramme, Kindprozesse oder Netzwerkzugriffe.

Private Schlüssel/Passwörter werden als temporäre Dateien in einem nur dem Eigentümer zugänglichen Arbeitsverzeichnis materialisiert (Unix-Berechtigungen oder geschützte Windows-DACL). Argumente enthalten Dateipfade, niemals injizierte Zugangsdatenwerte. Werkzeugausgaben werden unterdrückt. Normale Bereinigung entfernt das Arbeitsverzeichnis und ruft gegebenenfalls die Bereinigung von GPG-Agent/temporärer Keychain auf. Abruptes Beenden kann Klartext oder Hilfsprozesse hinterlassen; es gibt keine Garantie sicheren Löschens oder einer Eingrenzung des Prozessbaums. Die temporäre Keychain von iOS hat ein leeres Passwort und verlässt sich auf Arbeitsverzeichnisberechtigungen. Dies ist keine hardwaregestützte Schlüsselverwahrung. Ausdrücklich entschlüsselte Ausgabe ist eine Klartextdatei.

Der erste iOS-Adapter unterstützt eine provisionierte .app mit Frameworks/dylibs, ohne verschachtelte Apps/Erweiterungen oder Links. Die Codesignaturprüfung prüft nicht die Apple-Provisionierungsberechtigung. OpenPGP-Ausgabe besteht aus abgetrennten Signaturen oder verschlüsselten Daten, nicht automatisch zusammengesetztem PGP/MIME. Formate und Plattformgrenzen beschreibt Kryptografische Aufträge.

CLI-Erfassung von Zugangsdaten

catch verlangt die bestehende sudo-Sitzung des Terminals, bevor es Eingaben abfragt, stdin liest oder seinen ausdrücklich ausgewählten Quellbefehl startet. Der Dienst prüft die Autorisierung beim Speichern der Zugangsdaten erneut. Die Erfassung importiert nur in geschützten Zugangtdatenspeicher; sie selbst stellt kein Lesen/Exportieren von Zugangsdaten über CLI oder MCP bereit.

Befehlserfassung liest ausschließlich stdout, schließt stdin des Kindprozesses und verwirft dessen stderr. Erfasster Text und Parserfehler werden niemals ausgegeben. Fehlgeschlagene Befehle, Zeitüberschreitungen, zu große Eingaben, mehrdeutige Regex-Ergebnisse und doppelte JSON-Objektschlüssel speichern keine Zugangsdaten. Geparste JSON-Strings werden bei Erfolg und Parsefehler gelöscht; temporäre Puffer im Besitz von Abhängigkeiten unterliegen weiterhin den obigen Speichergrenzen. Der Aufrufer muss dem gewählten Programm vertrauen: Es behält gewöhnliche OS-Berechtigungen und kann eigene Dateien, Logs oder Netzwerkverkehr schreiben. Die Bereinigung bei Zeitüberschreitung beendet den direkten Kindprozess, nicht dessen Nachfolgeprozesse. Erfassung ist ausdrückliche Eingabe-/Befehlsverarbeitung, keine Überwachung anderer Terminals oder Tastatureingaben. Bestehende Quelldateien und Shell-Verlauf bleiben unverändert. Verwenden Sie synthetische Testdaten und halten Sie Geheimnisse aus Befehlsargumenten heraus.

Cloud-Autorisierung

Cloud-Anmeldung verwendet Browser-Autorisierungscode mit PKCE und State-Prüfung. Mobile verwendet AppAuth und eine registrierte native Weiterleitung; der Wechsel in den Hintergrund sperrt den Tresor, und die Rückkehr aus dem Browser verlangt vor dem Tokenaustausch eine neue lokale Autorisierung. Mobile Zugriffs-/Aktualisierungstoken bleiben innerhalb von Rust. Vordergrundsynchronisierung läuft außerhalb von FFI-Registry- und Dienstsperren; Hintergrundsperren invalidiert verspätete Importe, Tokenaktualisierungen und Antworten. Die CLI tauscht Codes außerhalb des Dienstmutex mit festen HTTPS-Endpunkten aus und übermittelt Token anschließend über lokales authentifiziertes IPC. Der Dienst verlangt ein einmaliges, ablaufendes Ticket, gebunden an Aufrufer/Anbieter/Client-ID, plus aktuelles sudo. Sperren und Logout invalidieren Tickets, einschließlich Antworten laufender Netzwerkanfragen. Die lokale CLI bleibt innerhalb der vertrauenswürdigen Betriebssystemkontogrenze.

OAuth-Token/Clientgeheimnisse werden im gerätelokalen Zustand verschlüsselt und von exportierten Sicherungen, Gerätekopplung, Tresorsynchronisierung, Suche und MCP ausgeschlossen. Der Status legt nur Kontometadaten und Ablauf offen. Logout entfernt lokale Token, nicht die anbieterseitige Zustimmung oder historische Kopien der lokalen verschlüsselten Datenbank. Remote-Widerruf nutzt die Einstellungen des Anbieters für verbundene Apps. Kontoautorisierung gewährt keinen Tresorzugriff. Ein Runner für unveränderliche Objekte reiht empfängeradressiert verschlüsselte Tresorhüllen ein und wendet sie über OneDrive- und Google-Drive-Anwendungsordner an. Anbieteradapter und Tokenaktualisierung werden mit lokalen Fixtures getestet; echte Anbieterkonten wurden nicht validiert. Outbox-/Inbox-Belege bleiben in verschlüsseltem gerätelokalem Zustand und sind von Sicherungen, Kopplungspaketen und MCP ausgeschlossen. Sperren und Logout invalidieren laufende Transferbestätigungen; unvollständige Aufträge bleiben nach dem Entsperren fortsetzbar. Cloud-Objektnamen sind Chiffretext-Hashes, keine Tresortitel oder Kontokennungen.

Grenzen geschützter Karten

Erstellen/Ersetzen geschützter Karten erfordert sudo und speichert atomar eine öffentliche Metadatenkarte plus Zugangsdaten. Kontopasswörter, dotenv-Werte, HTTP-Token und OTP-Seeds gelangen nie in den gewöhnlichen Volltextindex. Dotenv-Vorschauen maskieren jeden Wert mit festem ***; generische Lesezugriffe und Exporte geben das Geheimnis nie zurück. Die ausdrückliche lokale Zugangsdaten-Kopieroperation unterstützt unter der obigen Zwischenablagegrenze auch geschützte Karten, einschließlich ihrer Seeds/Token/Passwörter. Gewöhnliches MCP kann gewöhnliche Zusammenfassungen durchsuchen, aber keine geschützten Geheimnisse erstellen, OTP-Codes generieren oder authentifizierte Anfragen senden. Metadaten und vollständige Revisionsinhalte bleiben im Ruhezustand und während der Synchronisierung verschlüsselt.

Import und Export von Website-Anmeldedaten

Website-Anmeldedaten sind eine geschützte login-Karte (öffentliche Website-URLs und Benutzername; das Passwort sind die gespeicherten Zugangsdaten). login_import erfordert sudo und eine schreibberechtigte Rolle; es normalisiert Browser-CSV (in crates/core geparst), ein schreibgeschützt gelesenes Firefox-Profil, Windows Credential Manager oder einen entschlüsselten Export in denselben Importweg. Deduplizierung vergleicht das entschlüsselte Passwort vorhandener Anmeldedaten innerhalb der Dienstgrenze in konstanter Zeit; identische Anmeldedaten werden übersprungen, abweichende Anmeldedaten derselben Website mit demselben Benutzernamen werden zu einer separaten Karte, sofern --update nicht angegeben ist, und ein einzelner Import ist begrenzt (2000 Zeilen). Die Browser-Spalte note wird verworfen, sofern sie nicht ausdrücklich angefordert wird, da Notizen in den gewöhnlichen Index gelangen. Direktes Firefox-Lesen unterstützt ausschließlich das moderne PBES2-Wrapping (PBKDF2-HMAC-SHA256 + AES-256-CBC) von key4.db mit 3DES-CBC-Anmeldewerten und einem bekannten oder leeren Hauptpasswort; älteres 3DES-PKCS#12-Wrapping wird gemeldet, nicht entschlüsselt. Das Lesen des Browserspeichers schwächt den Schutz dieses Browsers nicht und unterliegt der obigen Betriebssystemkontogrenze.

login_export verlangt sudo und verweigert rein gerätelokale Tresore. Das verschlüsselte Format (memories/logins/v1) versiegelt Einträge unter einem unabhängigen Passwort mit Argon2id und XChaCha20-Poly1305 und kann in jeden Tresor importiert werden. Das Chromium-kompatible CSV-Format ist Klartext, der den verschlüsselten Store verlässt: Es ist wie credential_copy eine bewusste lokale Ausnahme, nur für einen lokalen cli:-Aufrufer zulässig (niemals MCP, HTTP-/Relay-Remote-Aufrufer oder mobile FFI/Share, sowohl durch eine Aufrufer-Positivliste als auch die mobile Sperrliste durchgesetzt), schreibt vor der Klartextrückgabe eine signierte Lieferabsicht fest und schreibt eine nur dem Eigentümer zugängliche Datei mit entschärfter Tabellenkalkulations-Formelinjektion. Der Betreiber muss diese Datei schützen und löschen.

TOTP- und HOTP-Generierung ist die ausdrücklich autorisierte Ausgabe eines kurzlebigen Codes, kein Seed-Export. Die Generierung wird ohne Code oder Seed auditiert. HOTP persistiert bei jeder Generierung den erhöhten Zähler mit der Kartenrevision. Standardmäßige SHA-1-OTP-Unterstützung dient der Interoperabilität; ansonsten nutzt die Anwendung ihre vorhandenen modernen Algorithmen für authentifizierte Verschlüsselung und Signaturen. TOTP erfordert eine korrekte lokale Uhr. Dieser Client kann einen Prüfer nicht daran hindern, einen akzeptierten Code erneut zu verwenden. otpauth://-URI-Import akzeptiert nur totp/hotp-Typen; otpauth-migration://-Import dekodiert Google-Authenticator-MigrationPayload-Exporte ausschließlich in totp/hotp-Karten und legt den Seed niemals über Suche oder gewöhnliches MCP offen. Ausdrückliche unbeaufsichtigte Zugangsdaten-Lesezugriffe können den gespeicherten Seed offenlegen.

Clientgesteuerte IDs rein gerätelokaler Tresore werden im verschlüsselten Zustand persistiert. Ihre Inhalte sind von Gerätekopplung und exportierten Sicherungen ausgeschlossen, und Synchronisierungs-/Mitgliederexport wird verweigert. Ein kompromittierter Rechner oder veränderter vertrauenswürdiger Client kann diese Kontrollen auf Anwendungsebene umgehen. Es wird keine Geheimhaltung gegenüber einem autorisierten Mitglied beansprucht, das bereits die kryptografischen Schlüssel eines gemeinsamen Tresors besitzt.

Die Vorlage schützt dedizierte Geheimnisfelder. Benutzer müssen Geheimnisse aus gewöhnlichen Titeln, Notizen, Tags und Quellfeldern heraushalten. Der Import löscht eine bestehende dotenv-Datei, Zwischenablageinhalte oder früheren Shell-Verlauf nicht sicher.

Wiki-Geheimnisreferenzen

protect_secret verlangt lokales sudo und Schreibzugriff. Es erstellt atomar Zugangsdaten und ersetzt alle exakten Treffer des angegebenen nicht leeren Geheimnisses in einem aktuellen Erinnerungs-/Kartenkörper durch {{secret:LABEL}}. Eine typisierte Zuordnung innerhalb desselben Tresors löst das Label zu seinen Zugangsdaten auf; die Markierung allein gewährt keinen Zugriff. Labels bestehen aus 1-64 ASCII-Buchstaben, Ziffern, Unterstrichen oder Bindestrichen. Ein auch in Metadaten enthaltenes Geheimnis wird ebenso abgelehnt wie widersprüchliche Dokumente und wiederverwendete Labels. Gewöhnliche Änderungen erhalten die Zuordnung; generische Schreibvorgänge können Referenzen weder anhängen noch ändern. Lesen, Suche, Liste, Graph und MCP lösen diese Referenzen nicht auf. Kopieren löst nach Autorisierung die aktuellen Zugangsdaten auf und schreibt vor der Klartextrückgabe an den lokalen Client eine Audit-Lieferabsicht ohne Geheimnis fest. Diese Absicht beweist nicht, dass der anschließende Schreibvorgang in die OS-Zwischenablage erfolgreich war. Zwischenablagekopien erfordern UTF-8 ohne NUL-Bytes; das Kopieren einer OTP-Karte liefert ihren Seed, keinen generierten Einmalcode.

Ersetzung betrifft ausschließlich den aktuellen Körper, nicht signierten Revisionsverlauf, Wiederherstellungsarchive, andere Dokumente, Sicherungen oder zuvor geteilte Kopien. Sie ist keine automatische Geheimniserkennung oder anbieterseitige Schlüsselrotation. Bereits offengelegte Schlüssel müssen bei ihrem Aussteller widerrufen/rotiert werden. Neue geschützte Referenzen erfordern aktualisierte Clients; alte Clients können das hinzugefügte Inhaltsfeld nicht dekodieren. Ersetzungsregeln und Clientverhalten beschreibt die Nutzungsanleitung.

Ressourcen- und Betriebsgrenzen

Argon2id: 64 MiB, drei Iterationen, eine Lane, 32-Byte-Ausgabe; feste versionierte Parameter, zufälliges 16-Byte-Salt. Keine Passwortlängenbeschränkung auf Anwendungsebene.
XChaCha20-Poly1305 mit zufälligen 24-Byte-Nonces; separate authentifizierte Kontexte für Masterschlüssel, Zustand, Checkpoints, Sicherungen, Transport und 256 KiB große Inhaltsabschnitte.
Höchstens 16 MiB kodierter Asset-Körper pro Revision (binäre Importe haben base64-Overhead). Der gesamte verschlüsselte Zustand wird transaktional in SQLite neu geschrieben; dies ist für kleine Bibliotheken gedacht, nicht für Dateispeicherung im Multi-Gigabyte-Bereich.
Vollständige Synchronisierungshülle: 32 MiB Relay-Grenze. Vier gleichzeitige Räume mit jeweils zwei Peers, begrenzte Warteschlangen, 16 eingehende Frames/Sekunde, 60 Sekunden Empfangsinaktivitätsgrenze und zehn Minuten maximale Verbindungslebensdauer. Keine Offline-Zustellung.
Ein beschäftigter vertrauenswürdiger Kindprozess kann den lokalen Dienst bis zu fünf Minuten belegen; ein Kindprozess einer Ausführungsbindung belegt während dieser Zeit nur seine eigene IPC-Verbindung. HTTPS-Operationen haben 30 Sekunden Zeitlimit. Aufbewahrung ist nur anhängend; Bereinigung von Audit-/Versionshistorie und inkrementelle Synchronisierung sind zurückgestellt.
Die Auflösung von Berechtigungskonflikten verlangt, dass derselbe Eigentümer auf beiden Zweigen autorisiert bleibt. Komplexere Eigentumsstreitigkeiten führen zur sicheren Verweigerung und benötigen ein bewusstes zukünftiges Wiederherstellungsverfahren.

Bereitstellung

Binden Sie das Relay hinter TLS an Loopback. Deaktivieren Sie Reverse-Proxy-Protokollierung von Anfrage-/Antwortkörpern, Datenträgerpufferung, Core-Dumps und persistente Container-Volumes. TLS schützt Transportmetadaten vor dazwischenliegenden Netzwerken; Ende-zu-Ende-Verschlüsselung schützt Assets sogar vor dem TLS-Terminierungspunkt. Der Beispielcontainer verwendet einen Nicht-Root-Benutzer.

Erstellen Sie Sicherungen vom Client aus. Das Relay ist kein Sicherungssystem. Bewahren Sie das unabhängige Sicherungspasswort separat auf und testen Sie die Wiederherstellung, bevor Sie sich auf eine Sicherung verlassen.

Melden Sie Sicherheitsmängel vertraulich an den Repository-Eigentümer. Fügen Sie öffentlichen Issues keine echten Passwörter, Zugangsdatenwerte, entschlüsselten Inhalte oder vollständigen Produktionspakete bei.