Limites de sécurité

memories 0.1 est un logiciel en développement. Ne considérez pas la réussite d'une suite de tests comme un audit de sécurité indépendant ou une certification de sécurité pour la production.

Protections assurées

Un relais de synchronisation de coffres qui lirait ou falsifierait le contenu des ressources, substituerait l'identité d'un pair après une vérification délibérée de son empreinte, ou modifierait un texte chiffré authentifié.
La lecture d'une copie de la base de données locale sans le mot de passe local ou, lorsqu'elle a été délibérément activée, la clé d'enveloppement sans surveillance distincte. Le facteur local mobile dépend également du stockage sécurisé de la plateforme.
Un lecteur qui falsifierait des écritures, un administrateur qui changerait la propriété, ou un appareil révoqué qui utiliserait sa clé d'identité utilisateur pour s'attribuer un nouvel appareil autorisé.
Le CLI/MCP ordinaire qui afficherait accidentellement un identifiant stocké, accepterait un mot de passe sur une ligne de commande, ou permettrait à une capacité MCP d'hériter de l'élévation du terminal. Les lectures délibérées d'identifiants sans surveillance livrent intentionnellement des octets en clair.
La modification non détectée de révisions signées ou d'entrées d'audit, les ruptures de chaîne et la troncature de points de contrôle par rapport à l'état actuel restant de la base de données.

Limites délibérées

Les comptes hébergés en libre-service utilisent des hachages de mots de passe Argon2id salés et des coffres indépendants ; l'opérateur conserve néanmoins le contrôle du stockage hébergé et peut le déchiffrer. L'inscription par e-mail exige un code de vérification de boîte mail à usage unique et à durée limitée avant de définir un mot de passe. Le mode nom d'utilisateur n'a pas d'adresse de contact vérifiée. SMTP exige TLS avec vérification du certificat ; les identifiants restent dans la configuration protégée du service. Les autorisations de connexion expirent après une heure ; la révocation lors de la déconnexion du navigateur est effectuée au mieux hors ligne. Les limitations d'authentification sont locales au processus, bornées et grossières : elles limitent les abus de CPU et de courrier, mais ne constituent pas un service distribué de prévention des abus. Voir docs/center.md pour la configuration et les limites de récupération.
Memories Web est un client d'un Center hébergé, pas un coffre chiffré local au navigateur. Il conserve les jetons porteurs et le contenu retourné dans la mémoire de la page, les efface à la déconnexion, au passage en arrière-plan, à la fermeture de la page ou après cinq minutes d'inactivité, et ne les persiste pas dans le stockage du navigateur. L'effacement de la mémoire JavaScript n'est pas garanti, les extensions et les outils de débogage peuvent l'inspecter, et les fichiers téléchargés restent sur disque. Les jetons sont liés à l'origine HTTPS choisie (HTTP de boucle locale pour le développement) ; les redirections et les cookies sont désactivés. Une origine Web autorisée peut accéder aux API de contenu hébergé avec un jeton porteur autorisé, mais pas aux routes d'administration ou de gestion des tickets. CORS ne remplace pas l'autorisation du serveur. L'hôte Web qui fournit les scripts reçoit la confiance nécessaire pour détenir le jeton ; utilisez le /app/ fourni avec Center et de même origine lorsque c'est la limite de confiance souhaitée. Voir le guide du client Web.
Le mode hébergé facultatif de Center (memories-center --data) est un coffre chiffré distinct côté serveur, pas un stockage d'appareil chiffré de bout en bout. Le MEMORIES_CENTER_VAULT_PASSWORD détenu par l'opérateur ouvre le Store au format du démon ; les opérateurs de l'hôte et toute personne disposant du mot de passe et du disque peuvent lire tout le contenu hébergé en clair. Le RPC des autorisations hébergées est une interface fermée de contenu du coffre, avec une élévation locale à l'opération, comprenant les écritures privées/de fichiers/protégées et la livraison délibérée d'identifiants. Le MCP du démon reste sans élévation et inchangé. Le jeton porteur administrateur seul ne peut pas utiliser les API du coffre, mais les administrateurs peuvent émettre des autorisations distinctes à portée limitée ou des membres durables. Le verrouillage administrateur hébergé supprime les clés du Store ; le déverrouillage exige le mot de passe opérateur via HTTPS de confiance. Les jetons de membres durables dans members.json, accessible uniquement au propriétaire, sont des identifiants en clair, pas des clés de coffre : protégez leurs fichiers, sauvegardes et réponses uniques. Un ticket de déverrouillage émis par Center ne met pas le mot de passe de l'appareil sous séquestre et n'élève pas les privilèges de l'appareil/MCP. Les clients du démon configurés pour SaaS partagent le jeton porteur hébergé injecté ; les capacités MCP locales ne peuvent pas en hériter. La migration des anciennes notes conserve un memories.json.bak en clair ; protégez-le/supprimez-le après vérification. Voir docs/center.md pour le modèle de menace complet et les différences intentionnelles.
Les terminaux compromis, les administrateurs du système d'exploitation, les programmes autorisés malveillants, l'inspection de la mémoire, les enregistreurs de frappe et les utilisateurs copiant délibérément du texte en clair sont hors de la limite de confidentialité. Les tampons de clés Rust sont remis à zéro lorsqu'ils sont détenus par le code ; l'effacement du swap du système, des vidages après plantage, des allocations de dépendances et des chaînes Dart gérées par le ramasse-miettes n'est pas garanti. La garde sans surveillance sur ordinateur dispose des backends Windows DPAPI, macOS Keychain, Linux Secret Service et owner-file. Ils offrent une protection liée au compte du système, pas une garantie de garde matérielle ; owner-file stocke sa clé d'enveloppement en clair, accessible uniquement au propriétaire. Aucun backend livré ne garantit une garde matérielle sur ordinateur.
Le relais peut observer les métadonnées du trafic, bloquer des connexions, conserver son propre enregistrement du texte chiffré, retarder les révocations ou partitionner le parc. Le serveur livré n'écrit aucune ressource, mais il est impossible de forcer un serveur malveillant à ne pas enregistrer le trafic. La synchronisation entre pairs de coffres (/v1/channel) est chiffrée de bout en bout. Le RPC distant du démon via relais (/v1/rpc/{room}/{slot}) transporte en revanche du JSON authentifié : le relais ou le terminateur TLS peut lire le jeton d'écoute partagé et les charges utiles des requêtes/réponses.
Une révocation hors ligne ne peut pas effacer le texte en clair, les clés ou les sauvegardes antérieures. Un terminal qui n'a pas reçu une révocation peut toujours utiliser son ancienne copie locale. L'exportation vers un appareil connu comme révoqué est bloquée et les nouvelles époques utilisent de nouvelles clés. La révocation supprime aussi les exportations cloud en attente et invalide le travail capturé avant l'opération suivante sur un objet. Une requête réseau déjà démarrée ne peut pas être rappelée.
L'audit prouve le contenu signé et la continuité par rapport à l'état connu, pas qu'un appareil compromis a enregistré chaque accès. Le remplacement de toute la base de données et de toutes les preuves locales par une sauvegarde cohérente plus ancienne ne peut pas être détecté sans un point de contrôle plus récent d'un pair ou un ancrage externe. Aucun service d'horodatage de confiance n'existe.
Les opérations échouées sont auditées lorsqu'une identité locale de signature autorisée et utilisable est déverrouillée. Les tentatives lorsque tout est verrouillé sont soumises à une limitation de débit mais ne créent pas d'enregistrement d'audit signé persistant. Les plantages brutaux laissent les intentions de livraison/exécution précédemment validées au lieu d'inventer des résultats.
Un processus du même utilisateur se trouve à l'intérieur de la limite du compte local du système. L'IPC authentifie l'utilisateur du système ; l'élévation du terminal utilise en plus le PID parent. Cela n'isole pas d'un processus malveillant exécuté sous ce même utilisateur, et ne fournit pas une identité de session durable insensible à la réutilisation des PID. L'IPC accepte jusqu'à 16 clients simultanés. Le cadrage des tubes nommés Windows reste bloquant : des clients du même utilisateur bloqués peuvent occuper ces emplacements, mais un client bloqué ou un transfert cloud ne bloque pas toutes les autres connexions. Les E/S des trames Unix ont des délais bornés. Les opérations du service qui détiennent le verrou d'écriture, y compris l'exécution d'enfants de confiance, restent sérialisées. Les liaisons d'exécution font exception : le service autorise, déchiffre et audite sous verrou, puis le libère pendant l'exécution du programme lié.
Les liaisons d'exécution (credential bind) élargissent délibérément, avec autorisation sudo, la limite d'élévation pour un programme. Tant qu'une liaison n'a pas expiré (8 heures par défaut, au maximum 720) et que le stockage est déverrouillé, tout appelant cli: du même utilisateur peut exécuter ce programme avec son identifiant lié sans élévation. Ces appelants reçoivent la sortie du programme avec les occurrences exactes de l'identifiant remplacées, pas l'identifiant ; mais le programme, ses plugins/extensions et ses descendants reçoivent le texte en clair et peuvent le divulguer (sortie encodée, réseau, fichiers). Les liaisons sont un état chiffré local à l'appareil, jamais synchronisé, effacé lors d'une restauration de sauvegarde, et refusé aux appelants MCP, distants (ws:/relay:), sans surveillance et mobiles. Les règles de refus sont appliquées par le service aux arguments que le programme reçoit effectivement ; les règles de demande uniquement par le hook Claude Code, qui est un routeur de commodité, pas une limite : une commande qu'il manque s'exécute sans l'identifiant, et un processus du même utilisateur peut appeler directement run --binding (le hook vérifie aussi les appels directs qu'il peut voir). Placez dans une règle de refus tout ce qui ne doit jamais s'exécuter sans surveillance.
L'écoute HTTP/WebSocket et le RPC via relais facultatifs exposent le même protocole cadré service::Request après présentation d'un secret partagé (JSON binaire WebSocket : AuthFrame puis Wire). Le jeton d'écoute est fourni uniquement via --listen-token / MEMORIES_LISTEN_TOKEN (ou généré et affiché une seule fois) ; il n'est jamais stocké dans TOML. La comparaison est en temps constant. Le jeton est effacé lorsque le stockage se verrouille. Les appelants distants utilisent les espaces d'élévation stables ws:remote / relay:remote et ne peuvent pas hériter de l'élévation cli:{pid} d'un terminal local ; le déverrouillage/sudo sur ce transport élève l'espace distant pour les connexions ponctuelles suivantes. Les hôtes HTTP/relais sur ordinateur exposent l'ensemble ordinaire des opérations IPC locales après déverrouillage/sudo (y compris Run, CryptoJob, autorisations MCP, sessions distantes, proxys, copie d'identifiants et sauvegarde), soumis aux mêmes contrôles d'élévation. Les détenteurs du jeton sont donc aussi puissants qu'un client local élevé sur cet hôte — protégez le jeton en conséquence. La FFI mobile et Share conservent la liste de refus mobile (pas de Run/CryptoJob/autorisation MCP/distant/proxy sur téléphone ; Share refuse aussi la copie d'identifiants en clair et les vidages de sauvegarde). L'écoute HTTP utilise par défaut la boucle locale ; la liaison à une adresse hors boucle locale exige --allow-non-loopback et affiche un avertissement. HTTP/WS en clair n'exige pas de certificat ; --tls-cert / --tls-key activent HTTPS/WSS lorsque souhaité. Le RPC via relais exige WSS pour les relais hors boucle locale, un identifiant de salle à forte entropie de 43 caractères et le jeton d'écoute. La synchronisation du coffre continue d'utiliser /v1/channel ; le RPC direct utilise /v1/rpc et le RPC via relais utilise /v1/rpc/{room}/{slot}. L'interface WebUI restreinte est distincte et ne doit pas devenir un pont Request générique.
Les Centers d'autorisation facultatifs ([[centers]]) transforment un terminal en appareil géré par Center : l'initialisation autonome locale (init/restore) et l'émission locale d'autorisations MCP sont refusées. L'initialisation et les autorisations arrivent sous forme de tickets signés par Center, vérifiés avec les valeurs public_key configurées. Les tickets d'autorisation portent des portées délibérées (allow_all, read, write, read_write, read_write_delete) ; les anciens tickets avec booléen write correspondent à read / read_write. Plusieurs Centers peuvent être configurés ; un seul suffit à interdire l'initialisation autonome. Le déverrouillage par mot de passe du coffre reste local — les Centers distribuent la politique, pas les clés du coffre. Protégez les secrets de signature Center et les jetons administrateur comme des identifiants root. Voir docs/center.md.
Les empreintes des exécutables sont vérifiées immédiatement avant leur lancement. Il n'y a pas de bac à sable du système, d'exigence de code signé, d'exécution atomique par descripteur de fichier, ni de confinement des processus descendants. Un exécutable de confiance peut charger des plugins ou déléguer du travail.
Les copies dans le presse-papiers de mémoire ordinaire/privée, les identifiants copiés délibérément et les fichiers exportés quittent le stockage chiffré par action de l'utilisateur. credential_copy est une exception locale délibérée, autorisée par sudo, aux restrictions de sortie des identifiants : son client authentifié reçoit du texte en clair UTF-8 pour le presse-papiers du système. Le CLI n'affiche que l'état de la copie ; le mobile affiche la confirmation et le succès sans rendre le secret. MCP ne peut pas demander de copies. Le contenu du presse-papiers persiste après le verrouillage et peut être conservé par l'historique/la synchronisation du système ou d'autres applications ; aucun effacement du presse-papiers n'est garanti. credential generate crée le matériel de clé dans le coffre ; sa réponse de génération et credential public retournent des clés publiques ou certificats, jamais des clés privées. La copie délibérée d'identifiants peut livrer au presse-papiers du matériel de clé privée UTF-8 stocké, sous la même limite d'autorisation. Les clés RSA font 3072 ou 4096 bits.
file exec est une exportation de fichier autorisée côté CLI suivie d'une exécution locale, utilisant l'autorisation existante de lecture de fichier et l'audit de livraison. Il ne peut pas lire les identifiants ni élargir l'autorité MCP/mobile. Le programme choisi par l'utilisateur reçoit un instantané en clair dans un répertoire temporaire accessible uniquement au propriétaire, hérite de l'environnement et des flux du CLI, et peut divulguer le contenu sans masquage de sortie. Aucune empreinte d'exécutable n'est épinglée, comme lors de l'exécution manuelle d'un fichier exporté. Le verrouillage/la révocation ne peut pas rappeler cette copie. La sortie normale de l'enfant, l'échec de lancement et les interruptions traitées déclenchent la suppression ; un arrêt forcé, une coupure électrique ou la fermeture de la console Windows peut laisser du texte en clair. La suppression n'est pas un effacement sécurisé. Seul l'enfant direct au premier plan est supervisé, pas ses descendants détachés. L'exécution de fichier ne détient pas le verrou de service du démon.
L'adaptateur d'identifiants HTTPS prend en charge Bearer et Cookie GET/POST et ne retourne que l'état, pas des données de réponse arbitraires. Les sessions SSH, FTP, TCP, MySQL, Redis et PostgreSQL détenues par le démon exigent sudo et propose/approve/exec pour chaque instruction. Les tickets non approuvés ne peuvent pas s'exécuter. Les clés d'hôte SSH sont épinglées par SHA-256. L'authentification du client SSH utilise un mot de passe stocké ou une clé privée OpenSSH importée, et peut joindre un certificat OpenSSH stocké. Les clés privées chiffrées et la signature par agent SSH ne sont pas implémentées. Les identifiants ne sont pas affichés ; la sortie distante est bornée. MCP ne peut pas ouvrir ou approuver des sessions distantes. Les proxys SSH et de bases de données en boucle locale sont démarrés avec sudo, se lient uniquement à 127.0.0.1 et s'authentifient en amont avec des secrets stockés afin que les agents ne reçoivent jamais de clés. Tout processus capable de se connecter au port local peut utiliser le compte distant autorisé sans approbation par commande ; la boucle locale n'authentifie pas l'utilisateur du système. Le trafic local de base de données est en clair. Le verrouillage, l'expiration d'inactivité du coffre et l'arrêt ferment les écouteurs et les connexions actives. Les proxys expirent après 30 minutes, indépendamment de l'activité. MCP ne peut pas démarrer, lister ou arrêter les proxys. Chaque proxy accepte au maximum 16 connexions ; l'authentification a un délai de 30 secondes et des paquets de négociation bornés. Le TLS des bases de données par proxy utilise rustls, y compris la négociation des protocoles PostgreSQL/MySQL. PostgreSQL SCRAM vérifie la signature du serveur. L'authentification complète MySQL par mot de passe SHA-256 est refusée sans TLS vérifié ; l'échange RSA de mot de passe n'est pas implémenté. La transmission de l'annulation/des options de démarrage PostgreSQL et la compression MySQL ne sont pas prises en charge. Les sessions de base de données utilisent l'authentification par mot de passe avec TLS par défaut (vérification du nom d'hôte ; identifiant CA PEM supplémentaire facultatif). --no-tls est délibéré. L'épinglage de certificats et les certificats clients ne sont pas implémentés.
Les permissions s'appliquent à un coffre entier. Les lecteurs peuvent déchiffrer ses ressources ; l'interface client ne peut pas imposer une distinction cryptographique entre un membre qui lit et un membre qui copie du contenu déjà accordé à ce membre.

Autorité sans surveillance sur ordinateur

Le CLI/MCP sans surveillance est une autorité locale distincte à jeton porteur, activée volontairement, pas une autorisation MCP ordinaire ni une session sudo. L'activation exige un terminal interactif, le consentement saisi ENABLE, un déverrouillage par mot de passe et un sudo par mot de passe. Les lectures ultérieures exigent le fichier client délibérément sélectionné, pas des invites répétées de mot de passe. Sa portée de coffre comprend la mémoire/les cartes ordinaires et privées, les octets originaux des fichiers et l'historique du coffre actif, y compris le texte en clair UTF-8 des identifiants stockés délibérément demandés. Les lectures génériques refusent les identifiants ; les références de cartes protégées ne sont pas résolues automatiquement. Les révisions en quarantaine sont refusées. Aucune interface de mutation de ressources, d'exécution, d'administration, de synchronisation, de vidage de sauvegarde, d'exécution de recherche/modèle ou d'avancement du compteur OTP n'existe. L'appartenance actuelle de l'appareil et la portée de l'autorisation sont vérifiées à chaque lecture ; une intention de livraison signée est enregistrée avant la sortie, et un échec d'audit/stockage refuse la livraison.

L'enveloppe indépendante de clé maîtresse conserve le déverrouillage/la récupération par mot de passe. Sa clé d'enveloppement est détenue séparément via le backend délibérément sélectionné windows-dpapi (DPAPI de l'utilisateur actuel), macos-keychain (Keychain non synchronisé), ou linux-secret-service (Secret Service du bus de session). owner-file est une option délibérée de protection inférieure : du matériel d'enveloppement en clair protégé uniquement par les permissions du compte du système. Il n'y a aucun repli automatique. Les lectures au démarrage ne demandent pas de déverrouillage du trousseau ni d'interface d'authentification ; une garde indisponible, verrouillée ou nécessitant une approbation échoue en refusant l'accès. Un client de protocole ne peut pas contrôler le comportement arbitraire d'une interface propre au fournisseur. Ces backends ne garantissent pas le secret face aux processus du même compte ou aux administrateurs du système, ni une garde matérielle.

Un démarrage sans surveillance réussi charge les clés alors que l'autorisation ordinaire reste verrouillée. Il ne déverrouille pas les opérations ordinaires CLI/MCP, sudo, cloud ou RAG. Un lock manuel efface les clés et inhibe durablement le démarrage sans surveillance au-delà des redémarrages ; le déverrouillage par mot de passe seul ne le reprend pas. unattended resume exige une gestion locale du terminal autorisée par mot de passe. revoke supprime durablement une autorisation ; disable désactive l'autorité et révoque toutes les autorisations avant le nettoyage du backend. L'échec d'écriture d'un verrouillage durable retourne une erreur, donc la persistance ne peut pas être promise sur un appareil non inscriptible. Le texte en clair déjà livré ne peut pas être rappelé par verrouillage, révocation ou désactivation.

Le fichier client est une capacité secrète à jeton porteur, distincte des fichiers d'autorisation MCP ordinaires et liée au stockage sélectionné. La clé d'enveloppement est liée à l'identité canonique du stockage/de l'en-tête. L'autorité sans surveillance n'est pas incluse dans les sauvegardes logiques, l'appairage d'appareils ou la synchronisation de coffres. Copier toute la base de données brute copie néanmoins sa table auxiliaire d'enveloppe/d'autorité ; copier les fichiers clients ou le matériel de garde peut aussi préserver l'autorité. Le retour en arrière de tout l'appareil et l'effacement sécurisé restent hors des garanties. Gardez ces fichiers hors du contrôle de version, des journaux et des sauvegardes partagées.

Les stockages gérés par Center refusent l'autorité sans surveillance. HTTP/WebSocket, le RPC via relais, la FFI mobile/Share et WebUI ne peuvent pas utiliser cette voie, même avec une élévation ordinaire. Les permissions ordinaires de mcp serve --grant-file et les restrictions sur les identifiants sont inchangées. La commande distincte mcp serve-unattended --client-file expose délibérément les secrets au client récepteur. Base64url est un encodage, pas un chiffrement : les fournisseurs d'IA, transcriptions, journaux d'outils et caches peuvent conserver ou transmettre les secrets décodés ou les valeurs encodées. Un accès en lecture seule ne rend pas la divulgation de secrets inoffensive.

La couverture de bout en bout Linux utilise la garde owner-file avec le vrai démon et le CLI/MCP. Le dispositif de test isolé du protocole Linux Secret Service n'est pas un test de trousseau d'un bureau réel. Windows DPAPI, macOS Keychain et la validation native/sans interface avec un trousseau réel restent des conditions préalables de publication ; l'examen indépendant est en attente. Voir les détails d'utilisation et de validation.

Recherche et services de modèles

Les index BM25 et les vecteurs normalisés sont des caches en mémoire bornés de mémoire/cartes ordinaires autorisées. Ils sont invalidés par les changements de politique/contenu et effacés au verrouillage. Les index ne contiennent jamais les corps des identifiants ni le contenu délibérément privé ; les ressources fichiers et les révisions non résolues/en conflit restent exclues. L'ingestion délibérée d'un document texte/Markdown crée une carte de connaissances ordinaire ; l'opérateur ne doit donc pas importer du texte confidentiel comme donnée ordinaire publique pour le coffre. Le stockage temporaire SQLite pour la recherche est forcé en mémoire ; le contenu en cache n'est pas inclus dans les sauvegardes ou exportations cloud. Les limites de mémoire du processus s'appliquent toujours.

EmbeddingGemma local s'exécute dans le processus avec une bibliothèque d'inférence native ; ses fichiers publics de modèle ne sont téléchargés que par une commande d'installation délibérée ou fournis localement. La télémétrie ONNX est délibérément désactivée avant la création des sessions d'inférence. Les téléchargements intégrés épinglent une révision du dépôt et vérifient chaque fichier par SHA-256 avant publication. Les fichiers de modèle ont leur propre licence Gemma. Ils ne sont pas du matériel secret et ne constituent pas une limite de sécurité auditée indépendamment.

Configurer une URL distante d'embedding permet aux opérations RAG autorisées d'envoyer tous les fragments admissibles de documents à ce terminal. La génération envoie la question et les fragments sources sélectionnés ; le reclassement appris envoie ses candidats. Le client doit faire confiance aux fournisseurs de modèles et aux proxys configurés. Les étapes de modèle ciblant des fournisseurs hors boucle locale sont refusées pour les coffres réservés à l'appareil avant l'inférence. L'inférence locale et les services de boucle locale délibérément configurés restent disponibles. Les clients MCP ordinaires ne peuvent pas choisir les URL de fournisseurs, identifiants ou paramètres de proxy dans les arguments des outils, et restent limités au coffre et aux permissions de contenu ordinaire de leur autorisation. Les clés d'API sont référencées par nom de variable d'environnement, jamais par des valeurs littérales de configuration ou du CLI. Les corps de réponses HTTP en échec sont supprimés, et les échos directs de matériel d'authentification dans les réponses générées sont refusés ; un fournisseur configuré malveillant reste hors de la limite locale de confidentialité.

Les URL de modèles distants exigent HTTPS ; HTTP n'est autorisé qu'en boucle locale. Les redirections des API de modèles sont refusées. Les requêtes de boucle locale contournent les proxys ; les autres peuvent utiliser des proxys HTTP(S)/SOCKS ou l'environnement de proxy. Les nouvelles tentatives sont bornées et limitées aux échecs transitoires de connexion/lecture, à HTTP 429 et à certaines réponses 5xx. Elles peuvent répéter le calcul/la facturation du modèle. La validation TLS n'est pas désactivée.

Le travail de modèle ne détient pas le mutex d'écriture du service. Le verrouillage, les autorisations expirées/révoquées ou un changement d'état des sources suppriment les résultats tardifs et empêchent les étapes suivantes. Une requête/inférence en cours peut se terminer, et le texte déjà divulgué à distance ne peut pas être rappelé. Les sources de recherche sont des données, pas des instructions ; la génération ne dispose d'aucun outil applicatif. Des identifiants de citation valides ne prouvent pas qu'une réponse est fondée factuellement et n'éliminent pas le risque d'injection de prompt provenant de textes sources non fiables.

Tableau de bord d'état sur ordinateur

La configuration TOML locale ne contient que des paramètres non secrets de stockage, relais et bureau. Les fichiers explicitement sélectionnés mais absents, les clés inconnues et les valeurs mal formées sont refusés avant d'ouvrir un stockage. Les chemins relatifs de stockage sont résolus à côté du fichier sélectionné. Changer le chemin sélectionne un autre stockage et ne migre pas les données. La validation des URL de relais conserve les restrictions existantes de TLS distant et d'absence d'identifiants dans les URL.

La WebUI facultative écoute uniquement sur 127.0.0.1. GET /api/status et l'éditeur restreint POST /api/cards sont protégés par un jeton aléatoire de 256 bits créé pour chaque processus. Le lanceur place le jeton dans le fragment d'URL ; la page le retire de la barre d'adresse, le conserve dans le stockage de session de l'onglet et utilise un en-tête Authorization. L'URL complète de lancement est une capacité du tableau de bord et ne doit pas être partagée. Les requêtes avec un Host inattendu, une Origin étrangère ou des métadonnées de récupération intersites sont refusées. Aucun accès CORS, ressource tierce ou intégration dans un cadre n'est fourni. La projection d'état reste en lecture seule. L'édition de cartes utilise une liste d'autorisation délibérée distincte dans le CLI associé, avec au maximum quatre requêtes simultanées et une limite de requête de 1 MiB. Elle permet les opérations ordinaires de cartes/types, pas le déverrouillage, sudo, les lectures de fichiers, les lectures d'identifiants, la révélation de secrets, les autorisations ou l'exécution de processus. Les ressources privées sont vérifiées avant de retourner le contenu d'une carte. Les champs sensibles sont masqués et leur corps structuré interne n'est jamais retourné. L'enregistrement biométrique/PIN dans le navigateur n'est pas implémenté : les voies natives mobiles/CLI vérifiées traitent les valeurs sensibles. Le jeton de lancement autorise désormais les écritures de cartes ordinaires et le CRUD des modèles ; protégez-le en conséquence. Ce n'est pas un pont IPC générique.

Le moniteur local interroge le démon via son IPC authentifié normal dans un sous-processus de courte durée, avec un délai de trois secondes pour borner les lectures bloquées des tubes Windows. Il efface les détails lorsque les sondes échouent ; le verrouillage masque les détails au sondage suivant. Le sondage ne rafraîchit pas le délai d'inactivité du déverrouillage et n'accorde pas d'élévation. L'état du bureau reste inaccessible aux capacités MCP. Un programme malveillant dans le même compte du système reste à l'intérieur de la limite locale de confiance existante.

La zone de notification peut lancer le démon local par une action délibérée du menu. Fermer la zone de notification/le tableau de bord arrête son écouteur HTTP et sa surveillance ; cela n'arrête pas et ne déverrouille pas un démon exécuté indépendamment. L'authentification reste dans le CLI.

Travaux cryptographiques sur ordinateur

crypto_job exige une élévation locale du terminal et un condensat liant le plan public exact, les empreintes des entrées/outils et les références d'identifiants. MCP et la FFI mobile ne peuvent pas l'invoquer. Les identifiants doivent appartenir au coffre autorisé. Une intention signée est validée avant l'exécution externe, et le succès/l'échec est audité. La chaîne d'outils reste dans la limite du compte de confiance du système ; le hachage de l'exécutable ne contraint pas les bibliothèques, auxiliaires, processus enfants ou accès réseau.

Les clés privées/mots de passe sont matérialisés sous forme de fichiers temporaires dans un espace de travail accessible uniquement au propriétaire (permissions Unix ou DACL Windows protégée). Les arguments contiennent des chemins de fichiers, jamais des valeurs d'identifiants injectées. La sortie des outils est supprimée. Le nettoyage normal supprime l'espace de travail et invoque le nettoyage de GPG-agent/du Keychain temporaire lorsque pertinent. Un arrêt brutal peut laisser du texte en clair ou des processus auxiliaires ; aucune garantie d'effacement sécurisé ou de confinement de l'arbre des processus n'existe. Le Keychain temporaire d'iOS a un mot de passe vide et dépend des permissions de l'espace de travail. Ce n'est pas une garde matérielle des clés. La sortie délibérément déchiffrée est un fichier en clair.

Le premier adaptateur iOS prend en charge une seule .app provisionnée avec frameworks/dylibs, sans applications/extensions imbriquées ni liens. La vérification de signature de code ne vérifie pas l'admissibilité au provisionnement Apple. La sortie OpenPGP est constituée de signatures détachées ou de données chiffrées, pas de PGP/MIME assemblé automatiquement. Voir les travaux cryptographiques pour les formats et limites des plateformes.

Capture d'identifiants par le CLI

catch exige la session sudo existante du terminal avant de demander une saisie, de lire stdin ou de lancer sa commande source délibérée. Le service vérifie à nouveau l'autorisation lors du stockage de l'identifiant. La capture importe uniquement dans le stockage protégé des identifiants ; elle n'expose pas elle-même la lecture/l'exportation d'identifiants via CLI ou MCP.

La capture de commande lit uniquement stdout, ferme stdin de l'enfant et rejette stderr de l'enfant. Le texte capturé et les erreurs d'analyse ne sont jamais affichés. Les commandes échouées, délais dépassés, entrées trop volumineuses, résultats regex ambigus et clés dupliquées d'objets JSON n'enregistrent aucun identifiant. Les chaînes JSON analysées sont effacées en cas de succès et d'échec d'analyse ; les tampons de travail détenus par les dépendances restent soumis aux limites de mémoire ci-dessus. L'appelant doit faire confiance au programme choisi : il conserve les permissions ordinaires du système et peut écrire ses propres fichiers, journaux ou trafic réseau. Le nettoyage après dépassement de délai tue l'enfant direct, pas ses descendants. La capture est un traitement délibéré d'entrée/de commande, pas une surveillance d'autres terminaux ou des frappes au clavier. Les fichiers sources existants et l'historique du shell sont inchangés. Utilisez des données synthétiques pour les tests et gardez les secrets hors des arguments de commande.

Autorisation cloud

La connexion cloud utilise un code d'autorisation du navigateur avec PKCE et validation de state. Le mobile utilise AppAuth et une redirection native enregistrée ; le passage en arrière-plan verrouille le coffre, et le retour du navigateur exige une nouvelle autorisation locale avant l'échange de jetons. Les jetons mobiles d'accès/de rafraîchissement restent dans Rust. La synchronisation au premier plan s'exécute hors du registre FFI et des verrous du service ; le verrouillage en arrière-plan invalide les importations, rafraîchissements de jetons et réponses tardifs. Le CLI échange les codes avec des terminaux HTTPS fixes hors du mutex du service, puis soumet les jetons via l'IPC local authentifié. Le service exige un ticket à usage unique et à durée limitée lié à l'appelant/au fournisseur/à l'ID client ainsi que le sudo actuel. Le verrouillage et la déconnexion invalident les tickets, y compris les réponses de requêtes réseau en cours. Le CLI local reste dans la limite du compte de confiance du système.

Les jetons OAuth/secrets clients sont chiffrés dans l'état local à l'appareil et exclus des sauvegardes exportées, de l'appairage d'appareils, de la synchronisation du coffre, de la recherche et de MCP. L'état n'expose que les métadonnées du compte et l'expiration. La déconnexion supprime les jetons locaux, pas le consentement côté fournisseur ni les copies historiques de la base chiffrée locale. La révocation distante utilise les paramètres d'applications connectées du fournisseur. L'autorisation du compte n'accorde pas l'accès au coffre. Un exécuteur d'objets immuables met en file et applique les enveloppes de coffre chiffrées pour le destinataire via les dossiers d'application OneDrive et Google Drive. Les adaptateurs de fournisseurs et le rafraîchissement des jetons sont testés avec des dispositifs locaux ; les comptes réels des fournisseurs n'ont pas été validés. Les reçus d'envoi/de réception restent dans l'état chiffré local à l'appareil et sont exclus des sauvegardes, paquets d'appairage et MCP. Le verrouillage et la déconnexion invalident les accusés de transfert en cours ; les travaux incomplets restent reprenables après déverrouillage. Les noms d'objets cloud sont des hachages de texte chiffré, pas des titres de coffres ou identifiants de comptes.

Limites des cartes protégées

La création/le remplacement de cartes protégées exige sudo et stocke atomiquement une carte de métadonnées publiques ainsi qu'un identifiant. Les mots de passe de comptes, valeurs dotenv, jetons HTTP et graines OTP n'entrent jamais dans l'index plein texte ordinaire. Les aperçus dotenv masquent chaque valeur avec un *** fixe ; les lectures et exportations génériques ne retournent jamais le secret. L'opération locale délibérée de copie d'identifiants prend aussi en charge les cartes protégées, y compris leurs graines/jetons/mots de passe, sous la limite du presse-papiers ci-dessus. MCP ordinaire peut rechercher les résumés ordinaires mais ne peut pas créer de secrets protégés, générer des codes OTP ou envoyer des requêtes authentifiées. Les métadonnées et le contenu complet des révisions restent chiffrés au repos et pendant la synchronisation.

Importation et exportation d'identifiants de sites Web

Les identifiants de sites Web sont une carte protégée login (URL publiques du site et nom d'utilisateur ; le mot de passe est l'identifiant stocké). login_import exige sudo et un rôle avec droit d'écriture ; il normalise un CSV de navigateur (analysé dans crates/core), un profil Firefox en lecture seule, le Gestionnaire d'identification Windows ou une exportation déchiffrée vers le même parcours d'importation. La déduplication compare le mot de passe déchiffré d'un identifiant existant en temps constant à l'intérieur de la limite du service ; les identifiants identiques sont ignorés, un identifiant différent pour le même site et nom d'utilisateur devient une carte distincte sauf si --update est fourni, et une importation est plafonnée (2000 lignes). La colonne note du navigateur est abandonnée sauf demande délibérée, car les notes entrent dans l'index ordinaire. La lecture directe Firefox prend uniquement en charge l'enveloppement moderne PBES2 (PBKDF2-HMAC-SHA256 + AES-256-CBC) de key4.db avec des valeurs d'identifiants 3DES-CBC et un mot de passe principal connu ou vide ; l'ancien enveloppement 3DES-PKCS#12 est signalé, pas déchiffré. Lire le propre stockage d'un navigateur n'affaiblit pas sa protection et est soumis à la limite du compte du système ci-dessus.

login_export exige sudo et refuse les coffres réservés à l'appareil. Le format chiffré (memories/logins/v1) scelle les entrées sous un mot de passe indépendant avec Argon2id et XChaCha20-Poly1305 et peut être importé dans n'importe quel coffre. Le format CSV compatible Chromium est du texte en clair qui quitte le stockage chiffré : c'est une exception locale délibérée comme credential_copy, autorisée uniquement pour un appelant local cli: (jamais MCP, les clients distants HTTP/relais ou la FFI mobile/Share, imposé à la fois par une liste d'autorisation des appelants et la liste de refus mobile), qui valide une intention de livraison signée avant de retourner le texte en clair et écrit un fichier accessible uniquement au propriétaire avec neutralisation de l'injection de formules de tableur. L'opérateur doit protéger et supprimer ce fichier.

La génération TOTP et HOTP est une sortie délibérément autorisée d'un code de courte durée, pas une exportation de graine. La génération est auditée sans le code ni la graine. HOTP persiste le compteur incrémenté avec la révision de la carte à chaque génération. La prise en charge OTP SHA-1 standard existe pour l'interopérabilité ; l'application utilise sinon ses algorithmes modernes existants de chiffrement authentifié et de signature. TOTP exige une horloge locale correcte. Ce client ne peut pas empêcher un vérificateur de réutiliser un code accepté. L'importation d'URI otpauth:// n'accepte que les types totp/hotp ; l'importation otpauth-migration:// décode les exportations Google Authenticator MigrationPayload uniquement en cartes totp/hotp et n'expose jamais la graine via la recherche ou MCP ordinaire. Les lectures délibérées d'identifiants sans surveillance peuvent divulguer la graine stockée.

Les ID de coffres réservés à l'appareil contrôlés par le client sont persistés dans l'état chiffré. Leur contenu est exclu de l'appairage d'appareils et des sauvegardes exportées, et l'exportation de synchronisation/de membres est refusée. Une compromission de la machine ou un client de confiance modifié peut contourner ces contrôles applicatifs. Aucune confidentialité n'est revendiquée face à un membre autorisé qui détient déjà les clés cryptographiques d'un coffre partagé.

Le modèle protège les champs secrets dédiés. Les utilisateurs doivent garder les secrets hors des titres, notes, tags et champs sources ordinaires. L'importation n'efface pas de manière sécurisée un fichier dotenv existant, le contenu du presse-papiers ou l'historique antérieur du shell.

Références de secrets du wiki

protect_secret exige sudo local et l'accès en écriture. Il crée atomiquement un identifiant et remplace toutes les correspondances exactes du secret non vide fourni dans le corps actuel d'une mémoire/carte par {{secret:LABEL}}. Une correspondance typée dans le même coffre résout le libellé vers son identifiant ; le marqueur seul n'accorde aucun accès. Les libellés comportent 1-64 lettres ASCII, chiffres, traits de soulignement ou traits d'union. Un secret également présent dans les métadonnées est refusé, tout comme les documents en conflit et les libellés réutilisés. Les modifications ordinaires préservent la correspondance ; les écritures génériques ne peuvent pas joindre ou modifier des références. La lecture, la recherche, les listes, le graphe et MCP ne résolvent pas ces références. La copie résout l'identifiant actuel après autorisation et valide une intention de livraison d'audit sans le secret avant de retourner le texte en clair au client local. Cette intention ne prouve pas que l'écriture ultérieure dans le presse-papiers du système a réussi. Les copies dans le presse-papiers exigent UTF-8 sans octets NUL ; copier une carte OTP livre sa graine, pas un code à usage unique généré.

Le remplacement n'affecte que le corps actuel, pas l'historique des révisions signées, les archives de récupération, les autres documents, les sauvegardes ou les copies précédemment partagées. Ce n'est pas une découverte automatique de secrets ou une rotation de clés côté fournisseur. Les clés déjà exposées doivent être révoquées/renouvelées auprès de leur émetteur. Les nouvelles références protégées exigent des clients à jour ; les anciens clients ne peuvent pas décoder le champ de contenu ajouté. Voir le guide d'utilisation pour les règles de remplacement et le comportement des clients.

Limites de ressources et d'exploitation

Argon2id : 64 MiB, trois itérations, une voie, sortie de 32 octets ; paramètres fixes versionnés, sel aléatoire de 16 octets. Aucune restriction de longueur du mot de passe au niveau applicatif.
XChaCha20-Poly1305 avec nonces aléatoires de 24 octets ; contextes authentifiés distincts pour les clés maîtresses, l'état, les points de contrôle, les sauvegardes, le transport et les fragments de contenu de 256 KiB.
Au maximum 16 MiB de corps de ressource encodé par révision (les importations binaires ont un surcoût base64). Tout l'état chiffré est réécrit de manière transactionnelle dans SQLite ; cela vise les petites bibliothèques, pas le stockage de fichiers de plusieurs gigaoctets.
Enveloppe de synchronisation complète : limite du relais de 32 MiB. Quatre salles simultanées, deux pairs chacune, files bornées, 16 trames entrantes/seconde, limite d'inactivité de réception de 60 secondes et durée maximale de connexion de dix minutes. Aucune livraison hors ligne.
Un processus enfant de confiance occupé peut monopoliser le service local jusqu'à cinq minutes ; un enfant de liaison d'exécution n'occupe que sa propre connexion IPC pendant cette durée. Les opérations HTTPS ont un délai de 30 secondes. La rétention est uniquement additive ; l'élagage des audits/versions et la synchronisation incrémentale sont reportés.
La résolution des conflits de permissions exige que le même propriétaire reste autorisé sur les deux branches. Les litiges de propriété plus complexes échouent en refusant l'accès et exigent une future procédure de récupération délibérée.

Déploiement

Liez le relais à la boucle locale derrière TLS. Désactivez la journalisation des corps de requêtes/réponses du proxy inverse, la mise en tampon sur disque, les vidages mémoire et les volumes persistants des conteneurs. TLS protège les métadonnées de transport des réseaux intermédiaires ; le chiffrement de bout en bout protège les ressources même du terminateur TLS. Le conteneur d'exemple utilise un utilisateur non root.

Sauvegardez depuis le client. Le relais n'est pas un système de sauvegarde. Conservez le mot de passe indépendant de sauvegarde séparément et testez la récupération avant de vous fier à une sauvegarde.

Signalez les défauts de sécurité en privé au propriétaire du dépôt. N'incluez pas de vrais mots de passe, valeurs d'identifiants, contenu déchiffré ou paquets de production complets dans les tickets publics.