Le répertoire chiffré des identifiants

Vos identifiants vivent dans un répertoire chiffré que vous montez, un volume gocryptfs. Ils y sont rangés dans de simples fichiers JSON, lisibles seulement tant que le volume est monté. Dinoer les 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 Dinoer.

Le créer, puis le monter

Sur une installation par clone Git, le script de mise en place crée le stockage chiffré et un point de montage vide, aux chemins que fixent secrets_crypt_dir et secrets_dir dans dinoer.conf. --sans-chiffrement crée à la place un répertoire en clair (mode 700), pour une machine sans gocryptfs :

bash scripts/configurer-repertoire-chiffre.sh    # depuis le clone

Le paquet .deb ne fournit pas ce script : créez vous-même le volume gocryptfs et indiquez son point de montage dans secrets_dir. Ensuite, quelle que soit la voie, montez-le avant une exécution qui en a besoin :

dinoer-monter-secrets                                     # paquet .deb
bash /opt/dinoer/scripts/monter-repertoire-chiffre.sh     # clone Git

Rien n’est lisible sur le disque tant que le volume n’est pas monté.

Y ranger des identifiants

Un fichier JSON par site, nommé d’après son domaine (target.local.json, ou target.local_8443.json pour un port précis), n’importe où sous le répertoire monté :

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

Seules les clés utilisées par vos scénarios doivent exister. totp_cle est la graine en base32 des codes de double authentification ; ntfy_topic est le canal par lequel un code qui vous est envoyé peut être transmis. Sans --secrets, Dinoer choisit le fichier d’après le domaine de la page réellement chargée : une redirection vers un autre site ne trouve aucun identifiant. Avec --secrets, le fichier est désigné explicitement : il doit alors lister dans origines_autorisees les domaines sur lesquels il peut servir, et n’être lisible que par son propriétaire (chmod 600), faute de quoi Dinoer le refuse.

S’en servir dans un scénario

{"type": "remplir", "selecteur": "input[name=\"username\"]",
 "valeur": "depuis_secrets", "secret_cle": "username"},
{"type": "remplir", "selecteur": "input[name=\"password\"]",
 "valeur": "depuis_secrets", "secret_cle": "password"}

secret_cle est la clé dans le fichier. Le scénario nomme une clé, jamais un secret : il peut donc figurer dans un dépôt public sans rien à masquer.

Un répertoire par projet

Deux façons, pour une exécution ponctuelle ou pour une habitude.

# Ponctuel
DINOER_SECRETS_DIR=~/Vaults/MyProject /opt/dinoer/venv/bin/python3 /opt/dinoer/shot.py \
  --url … --guide-version 1.6

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

Un secrets_dir relatif se résout à partir de l’emplacement du fichier de configuration : le réglage suit le projet.

--secrets <fichier> désigne un fichier d’identifiants pour une seule exécution sans toucher à la configuration, par exemple quand un même scénario sert plusieurs comptes.

Quand le répertoire est fermé

Dinoer s’arrête avec une erreur explicite :

SecretsFermesError — exit code 42 (encrypted directory not mounted)
SecretsNonConfigureError — exit code 43 (no credential directory configured)

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

Dinoer protège aussi ses propres écritures : quand son journal des opérations est placé dans le répertoire chiffré et que celui-ci est fermé, il écrit dans un fichier de secours local plutôt qu’en clair à l’endroit du stockage chiffré.

L’erreur qui coûte le plus cher

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

La protection de Dinoer couvre ses propres écritures. Elle ne couvre pas un fichier d’identifiants que vous créez vous-même, par une commande ou un éditeur, pendant que le répertoire n’est pas monté. Vous écrivez alors à côté du stockage chiffré, en clair, dans un répertoire qui a exactement l’air du bon.

Avant de créer ou de modifier un fichier d’identifiants, vérifiez que le répertoire est monté : il ne doit pas être vide. 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 : on peut les committer.
• DINOER_CONF, DINOER_SECRETS_DIR ou --secrets pour des identifiants par projet et par compte.
• Code 42 : fermé ; code 43 : jamais configuré. 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.