El directorio cifrado de credenciales

Dónde viven las contraseñas, cómo llegan a un formulario sin pasar nunca por su shell, y el error que, sin avisar, las escribe en claro.

Sus credenciales viven en un directorio cifrado que usted monta — un volumen gocryptfs. Están en un simple archivo JSON dentro de él, y ese archivo solo es legible mientras el volumen está montado. Diwall lo lee dentro del proceso que pilota el navegador, en el momento de rellenar un campo. El valor nunca pasa por su shell, su historial de comandos ni los propios registros de Diwall.

Las palabras importan aquí: un archivo JSON no es una caja fuerte, y llamarlo así promete una garantía que el archivo no ofrece. Lo que protege las credenciales es el cifrado del directorio que las rodea, y el hecho de que Diwall nunca saque el valor del proceso que lo necesita.

Ese es todo el mecanismo. El resto de esta página explica cómo ponerlo en marcha, y una manera de equivocarse.

Crearlo una vez

diwall-monter-secrets              # montar un directorio cifrado existente

Para crear uno, el script de configuración del repositorio admite los dos modos — cifrado con gocryptfs por defecto, o un directorio en claro con --sans-chiffrement. El paquete no lo incluye: ejecútelo desde un clon del repositorio, indicándole la configuración del paquete si instaló Diwall de esa forma.

git clone https://github.com/RonanDavalan/diwall.git
bash diwall/scripts/configurer-repertoire-chiffre.sh --config /etc/diwall/diwall.conf   # canal del paquete
bash diwall/scripts/configurer-repertoire-chiffre.sh                                     # canal del clon de Git

El modo cifrado crea el almacén cifrado y un punto de montaje vacío. Nada es legible en el disco hasta que lo monte.

Poner las credenciales

Un simple archivo JSON dentro del directorio montado:

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

Solo tienen que existir las claves que su escenario utiliza realmente, salvo origines_autorisees — obligatoria desde el 05/08/2026, sin excepción. Enumera los nombres de host para los que se puede usar este archivo; una lectura para cualquier otro dominio se rechaza antes incluso de abrir el archivo. totp_cle es la semilla base32 de los códigos de doble factor; ntfy_topic sirve para los códigos que se le envían.

Usarlo en un escenario

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

secret_cle es la clave dentro del archivo descifrado. El escenario se puede versionar — nombra una clave, nunca un secreto. Por eso un escenario puede estar en un repositorio público sin tener que ocultar nada.

Nunca haga esto PASS=$(jq -r ‘.password’ ~/Vaults/…/creds.json) — una credencial en una variable de shell está en el entorno del proceso, en /proc y quizá en su historial. El directorio cifrado existe precisamente para evitarlo.

Un directorio por proyecto

Dos maneras, según se trate de algo puntual o de un hábito.

# Puntual
DIWALL_SECRETS_DIR=~/Vaults/MiProyecto diwall-shot --url … --guide-version 1.3

# Recurrente — un archivo de configuración en la raíz del proyecto
echo '{"secrets_dir": "../MiProyecto-secrets"}' > ~/git/MiProyecto/.diwall.conf
export DIWALL_CONF=~/git/MiProyecto/.diwall.conf

Un secrets_dir relativo se resuelve respecto a la ubicación del archivo de configuración, así que todo viaja con el proyecto.

--secrets <archivo> designa un archivo de credenciales concreto para una ejecución sin tocar ninguna configuración — útil cuando el mismo escenario sirve a varios clientes.

Cuando el directorio está cerrado

Diwall se detiene con un fallo explícito en lugar de fingir:

SecretsFermesError — exit code 42

Si usted es un agente: no intente montarlo usted mismo. Pregunte al operador.

Diwall protege también sus propias escrituras. Su registro de operaciones detecta un directorio cerrado y recurre a una ubicación local de reserva en lugar de escribir en claro donde debería estar el almacén cifrado; el archivado de evidencias se omite en lugar de duplicar capturas autenticadas fuera de él.

El error que más cuesta

Un directorio sin montar sigue existiendo. Simplemente está vacío — y sin cifrar.

La protección interna de Diwall cubre las escrituras del propio Diwall. No cubre un archivo de credenciales que usted cree por su cuenta, con un comando de shell o un editor, mientras el directorio está desmontado. En ese caso no escribe dentro: escribe al lado, en claro, en un directorio que parece exactamente el correcto.

Antes de crear o modificar un archivo de credenciales, confirme que el directorio está montado — no debe estar vacío. En caso de duda, deténgase y compruébelo. Este error no tiene vuelta atrás.

En resumen

El archivo se lee dentro del proceso del navegador, nunca a través de su shell.
Los escenarios nombran una clave, nunca un secreto — por eso se pueden versionar.
DIWALL_CONF o --secrets para directorios por proyecto y por cliente.
El código de salida 42 significa cerrado: pregunte al operador, no lo monte usted mismo.
Un directorio sin montar es un directorio vacío y sin cifrar. Compruébelo antes de escribir.