fnox et age: des secrets chiffrés dans mes repos, sans serveur

Les secrets des projets perso ont toujours eu le même problème: pas de Vault à la maison, des .env qui ne devraient jamais être commités mais qui le sont toujours et des variables d’environnement non secrètes déjà bien gérées par direnv . Fin 2025, j’ai découvert fnox , le gestionnaire de secrets de l’auteur de mise , qui colle exactement à ce vide: les secrets vivent chiffrés dans le repo, eux-mêmes, sans serveur.

age: la brique

Sous le capot, age , l’outil de chiffrement de FiloSottile (celui de Go). Le parti pris: un fichier à chiffrer, des clés explicites, zéro option de config. age-keygen produit une paire: une clé privée AGE-SECRET-KEY-... et un recipient public age1.... On chiffre un fichier vers une liste de recipients; les clés SSH font aussi l’affaire comme recipients. Pas de web de confiance, pas de keyserver, pas de trousseau: deux concepts et un format lisible. C’est ce que PGP aurait dû être, sans les trente ans d’archéologie.

fnox: la couche

fnox apporte la couche projet: un fnox.toml par repo, versionné avec le code, qui déclare les secrets et leur backend. Les valeurs sont chiffrées avec age vers les recipients déclarés, donc le repo contient les secrets, chiffrés et le clone neuf avec la bonne clé voit tout; sans la clé, le repo reste clonable et opaque. À l’exécution, fnox déchiffre et expose le tout comme variables d’environnement. Le détail qui intéresse mes usages multi-machines: les backends sont des providers, age en local mais aussi 1Password et ses cousins distants, mélangeables dans le même fichier. Le secret local voyage en age, le secret d’équipe pointe vers le coffre, le fnox.toml documente les deux.

Dans la pratique

Le flux tient en quatre gestes: age-keygen une fois, la clé privée dans le gestionnaire de clés et nulle part près d’un repo; les recipients dans le fnox.toml commité; fnox set pour ajouter un secret (le fichier se re-chiffre); fnox exec pour lancer la session avec les variables en place. Mes secrets de cluster et de gestionnaire de dotfiles passent ainsi par le même flux: fnox avec des clés age, dans un env dédié tenu hors de l’arbre tracké. Le repo se review comme le code: le diff d’un secret montre que quelque chose a changé, pas la valeur.

La part honnête

L’outil est très jeune: le repo date d’octobre 2025, l’API bouge encore et la documentation court après. La rotation est manuelle (re-chiffrer), le partage impose de distribuer la clé privée ou d’ajouter le recipient d’un collaborateur et la clé age est aussi sûre que sa copie offline. fnox ne remplace pas un KMS non plus: c’est du chiffrement de repo, pas de la gestion d’accès centralisée ni de l’audit d’usage. Pour des projets perso et des machines à moi, c’est exactement la taille du problème.

Le mot de la fin

Le secret chiffré dans le repo est la seule version qui ne diverge pas. Un .env hors repo est un .env qui mentira.
age fait une seule chose, chiffrer des fichiers et c’est pour ça qu’on lui fait confiance.
Le fnox.toml versionné est le contrat, les clés sont le carnet. Comme le .tool-versions de mise.
Un diff de secret montre le changement sans montrer la valeur. Les review d’infra gagnent un sens.

[edit: 2026] Depuis, fnox s’est stabilisé et le flux décrit tient toujours: un fichier, des recipients, fnox exec. L’outillage local continue de converger: machine avec Ansible, projets avec mise , secrets avec fnox et age.