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.