Diwall MCP

Français
Télécharger v0.0.1

Les identifiants du répertoire chiffré

Le serveur ne saisit un mot de passe que depuis un fichier du répertoire gocryptfs que vous ouvrez, que sur l'origine exacte que le fichier nomme, et la valeur n'apparaît jamais dans ce que le modèle reçoit.

Le répertoire chiffré, c’est à vous de l’ouvrir

Le serveur ne lit et n’écrit que dans un répertoire d’un volume gocryptfs : les identifiants, le profil du navigateur dédié, le journal, les captures et les téléchargements. Vous ouvrez et fermez le volume ; le serveur ne le monte ni ne le démonte jamais, ne lance jamais gocryptfs ni fusermount3, et ne connaît jamais son mot de passe. Tant qu’il est fermé, le serveur refuse d’écrire, et il n’a aucun repli vers un emplacement non chiffré. Il n’accepte le montage que comme un montage fuse.gocryptfs de son propre utilisateur, sans l’option allow_other.

mcp-server-diwall-browser-setup le fait pour vous, dans un terminal à vous, et create écrit le profil de l’opérateur une fois qu’il a vu le volume monté. create --temporary fait un volume en mémoire pour un essai, détruit par close, par l’arrêt de la machine ou par la fin de votre session (les sessions des sites, le journal et les captures sont perdus avec lui) ; create fait un volume durable ; open le rouvre ; close arrête le navigateur, puis démonte. Vous tapez le mot de passe à l’invite de gocryptfs ; l’assistant ne le lit pas. Un volume qui existe déjà, copié d’une autre machine ou fait par Plasma Vault, se prend avec create --crypt-dir et --mount-dir : il n’est pas initialisé, seulement ouvert avec votre mot de passe. Lancée sans argument, la commande dit ce que votre machine permet et la commande suivante.

À la main, le volume étant créé une fois (gocryptfs -init, dont la clé maîtresse va sur papier ou dans un gestionnaire de mots de passe, jamais dans un fichier de ce disque), ouvrez-le et, la première fois, créez les répertoires du serveur :

gocryptfs ~/Vaults/Main.enc ~/Vaults/Main
mkdir -m 700 ~/Vaults/Main/mcp-server-diwall-browser
mkdir -m 700 ~/Vaults/Main/mcp-server-diwall-browser/credentials
mkdir -m 700 ~/Vaults/Main/mcp-server-diwall-browser/browser-profile

Pour le fermer, fermez d’abord le navigateur dédié, qui garde des fichiers ouverts dans son profil, puis :

fusermount3 -u ~/Vaults/Main

Jamais fusermount3 -u -z : un démontage paresseux détache le répertoire pendant qu’un processus peut encore écrire par l’ancien chemin, qui mène alors au répertoire non chiffré dessous. Le répertoire ouvert ne doit entrer dans aucune sauvegarde : excluez-le par la frontière du système de fichiers (rsync --one-file-system) ou dans votre outil de sauvegarde ; les fichiers chiffrés peuvent être sauvegardés ailleurs.

Un fichier par site

Un fichier d’identifiants contient le nom d’utilisateur et le mot de passe d’un site, dans credentials/, en mode 600. Son nom est fait de lettres minuscules, de chiffres, de ., _ et -, 64 caractères au plus, puis .json. Ses clés sont allowed_origins (obligatoire), username et password (au moins l’une des deux), et rien d’autre :

{
  "allowed_origins": ["https://account.example.invalid"],
  "username": "alice",
  "password": "replace-with-the-real-password"
}

Écrivez-le avec votre éditeur, jamais avec echo ni une redirection du shell, qui laisseraient le mot de passe dans l’historique de votre shell :

vim ~/Vaults/Main/mcp-server-diwall-browser/credentials/account.json
chmod 600 ~/Vaults/Main/mcp-server-diwall-browser/credentials/account.json

L’origine est exacte. Avec ce fichier, une page de https://account.example.invalid reçoit l’identifiant ; http://account.example.invalid, https://account.example.invalid:8443 et https://www.account.example.invalid ne le reçoivent pas (credential_not_bound). Un fichier qui liste un joker est refusé.

Ce que fait le modèle, et ce qu’il voit

Le modèle remplit un champ avec une référence, jamais avec la valeur : {"key": "password"}, ou {"key": "password", "name": "account"} quand plusieurs fichiers sont liés à une même origine. Le serveur lit le fichier dans son propre processus au moment où il saisit, envoie la valeur au navigateur par la connexion locale de débogage, et le résultat dit <secret:password>. Un champ que le serveur juge sensible (mot de passe, carte, code) refuse le texte en clair avec sensitive_value_refused, si bien qu’un mot de passe ne peut pas passer par inadvertance dans le contexte du modèle.

Les identifiants gardés dans un format plus ancien, un fichier JSON par site avec des noms d’hôte et sans schéma, ne sont pas lus par le serveur. Une commande que vous lancez dans votre propre shell convertit un fichier, ou un répertoire de fichiers, dans son propre processus et n’affiche aucune valeur ; elle ne garde aucun second facteur et n’écrase rien :

cd ~/mcp-server-diwall-browser
.venv/bin/python -m mcp_server_diwall_browser.credential_import \
  --source-dir ~/Vaults/Main/old-credentials

Elle a été testée sur des fichiers de la suite de tests dans un volume simulé, pas sur un vrai volume gocryptfs. Chaque option, chaque refus et les six vérifications qu’elle fait sont dans la section 6 du guide de l’opérateur.