Le répertoire chiffré des identifiants

Où vivent les mots de passe, comment ils atteignent un formulaire sans jamais passer par votre shell, et l’erreur qui, sans bruit, les écrit en clair.

Vos identifiants vivent dans un répertoire chiffré que vous montez — un volume gocryptfs. Ils tiennent dans un simple fichier JSON à l’intérieur, et ce fichier n’est lisible que tant que le volume est monté. Diwall le lit dans le processus qui pilote le navigateur, au moment où un champ est rempli. La valeur ne passe jamais par votre shell, votre historique de commandes, ni les journaux de Diwall.

Les mots comptent ici : un fichier JSON n’est pas un coffre-fort, et l’appeler ainsi promet une garantie que le fichier ne porte pas. Ce qui protège les identifiants, c’est le chiffrement du répertoire qui les entoure, et le fait que Diwall ne sorte jamais la valeur du processus qui en a besoin.

C’est tout le mécanisme. Le reste de cette page explique comment le mettre en place, et une façon de se tromper.

Le créer une fois

diwall-monter-secrets              # monter un répertoire chiffré existant

Pour en créer un, le script de configuration du dépôt gère les deux modes — chiffré par gocryptfs par défaut, ou répertoire en clair avec --sans-chiffrement. Le paquet ne le livre pas : lancez-le depuis un clone du dépôt, en lui indiquant la configuration du paquet si c’est ainsi que vous avez installé Diwall.

git clone https://github.com/RonanDavalan/diwall.git
bash diwall/scripts/configurer-repertoire-chiffre.sh --config /etc/diwall/diwall.conf   # canal du paquet
bash diwall/scripts/configurer-repertoire-chiffre.sh                                     # canal du clone Git

Le mode chiffré crée le stockage chiffré et un point de montage vide. Rien n’est lisible sur le disque tant que vous ne l’avez pas monté.

Y mettre les identifiants

Un simple fichier JSON dans le répertoire monté :

{
  "username": "operator",
  "password": "…",
  "totp_cle": "BASE32SEED",
  "ntfy_topic": "…",
  "origines_autorisees": ["target.local"]
}

Seules les clés que votre scénario utilise réellement doivent exister, sauf origines_autorisees — obligatoire depuis le 05/08/2026, sans exception. Elle liste les noms d’hôte pour lesquels ce fichier peut servir ; une lecture pour tout autre domaine est refusée avant même l’ouverture du fichier. totp_cle est la graine base32 des codes à deux facteurs ; ntfy_topic sert aux codes qui vous sont envoyés.

S’en servir dans un scénario

{"type": "remplir_som", "id": 2,
 "valeur": "depuis_secrets", "secret_cle": "username"},
{"type": "remplir_som", "id": 3,
 "valeur": "depuis_secrets", "secret_cle": "password"}

secret_cle est la clé dans le fichier déchiffré. Le scénario peut être versionné — il nomme une clé, jamais un secret. C’est pourquoi un scénario peut vivre dans un dépôt public sans que rien n’y soit caviardé.

Ne faites jamais ceci PASS=$(jq -r ‘.password’ ~/Vaults/…/creds.json) — un identifiant dans une variable de shell se retrouve dans l’environnement du processus, dans /proc, et peut-être dans votre historique. Le répertoire chiffré existe précisément pour l’éviter.

Un répertoire par projet

Deux façons de faire, selon qu’il s’agit d’un cas ponctuel ou d’une habitude.

# Ponctuel
DIWALL_SECRETS_DIR=~/Vaults/MonProjet diwall-shot --url … --guide-version 1.3

# Récurrent — un fichier de configuration à la racine du projet
echo '{"secrets_dir": "../MonProjet-secrets"}' > ~/git/MonProjet/.diwall.conf
export DIWALL_CONF=~/git/MonProjet/.diwall.conf

Un secrets_dir relatif se résout par rapport à l’emplacement du fichier de configuration : l’ensemble voyage avec le projet.

--secrets <fichier> désigne un fichier d’identifiants précis pour une exécution, sans toucher à la configuration — utile quand un même scénario sert plusieurs clients.

Quand le répertoire est fermé

Diwall s’arrête sur un échec explicite plutôt que de faire semblant :

SecretsFermesError — exit code 42

Si vous êtes un agent : n’essayez pas de le monter vous-même. Demandez à l’opérateur.

Diwall protège aussi ses propres écritures. Son journal des opérations détecte un répertoire fermé et bascule vers un repli local au lieu d’écrire en clair là où devrait se trouver le stockage chiffré ; l’archivage des preuves est sauté plutôt que de dupliquer des captures authentifiées hors de lui.

L’erreur qui coûte le plus cher

Un répertoire non monté existe toujours. Il est simplement vide — et non chiffré.

La garde interne de Diwall couvre les écritures de Diwall. Elle ne couvre pas un fichier d’identifiants que vous créez vous-même, par une commande shell ou dans un éditeur, pendant que le répertoire se trouve démonté. Vous n’écrivez pas alors dedans : vous écrivez à côté, en clair, dans un répertoire qui a exactement l’air d’être le bon.

Avant de créer ou de modifier un fichier d’identifiants, vérifiez que le répertoire est monté — il doit être non vide. Dans le doute, arrêtez-vous et vérifiez. Cette erreur-là ne se rattrape pas.

En bref

Le fichier est lu dans le processus du navigateur, jamais par votre shell.
Les scénarios nomment une clé, jamais un secret — ils restent donc versionnables.
DIWALL_CONF ou --secrets pour un répertoire par projet ou par client.
Code de sortie 42 : répertoire fermé ; demandez à l’opérateur, ne le montez pas vous-même.
Un répertoire non monté est un répertoire vide et non chiffré. Vérifiez avant d’écrire.