De dotenv à dotenvx - le gestionnaire de configuration nouvelle génération

• Après le tout premier commit de dotenv en juillet 2013, le projet est devenu en 11 ans l’un des packages les plus utilisés au monde
• Il a atteint un statut comparable à celui de logiciels essentiels comme TypeScript et ESLint

Les problèmes de dotenv

• Risque de fuite des fichiers .env
• Gestion difficile de plusieurs environnements
• Manque de cohérence entre les plateformes

La solution : dotenvx

• Fonctionne de la même manière sur toutes les plateformes
• Prise en charge de plusieurs environnements
• Chiffrement des fichiers de variables d’environnement

Exécutable partout

• Fonctionne de la même manière avec tous les langages, frameworks et plateformes
• Permet d’injecter des variables d’environnement à l’exécution avec dotenvx run -- your-cmd
• Le moteur de parsing .env, l’expansion de variables et la substitution de commandes se comportent de façon identique
• Installation possible de multiples façons : npm, brew, curl, docker, windows, etc.

  $ echo "HELLO=World" > .env  
  $ echo "console.log('Hello ' + process.env.HELLO)" > index.js  
  $ node index.js  # sans dotenvx  
  Hello undefined  
  $ dotenvx run -- node index.js  # avec dotenvx  
  Hello World  
  

Prise en charge de plusieurs environnements

• Créez un fichier .env.production, puis chargez-le avec l’option -f
• Il est possible de composer plusieurs environnements avec plusieurs flags -f

  $ echo "HELLO=production" > .env.production  
  $ dotenvx run -f .env.production -- node index.js  
  [dotenvx][info] loading env (1) from .env.production  
  Hello production  
  

Chiffrement

• Ajoute le chiffrement à un fichier .env avec la commande dotenvx encrypt
• Utilise un mécanisme de chiffrement à clé publique
• Même si un fichier .env fuit, il reste impossible à déchiffrer sans DOTENV_PRIVATE_KEY
• Dans un projet open source, il est possible d’ajouter une nouvelle configuration sans déchiffrer les secrets précédents

  $ dotenvx encrypt  
  ✔ encrypted (.env)  
  

Sortie de la version 1.0.0

• Annonce de la sortie de dotenvx 1.0.0
• De nombreux développeurs pourront s’en servir comme outil de gestion de configuration nouvelle génération

---

L’avis de GN⁺

• dotenvx offre à la fois sécurité et praticité
• Sa gestion simple de plusieurs environnements le rend utile pour les développeurs
• La fonction de chiffrement est particulièrement utile pour les projets sensibles à la sécurité
• Les fonctionnalités de dotenvx apportent de la cohérence entre différents langages et plateformes, ce qui améliore l’efficacité du développement

[yangeok]

On dirait qu’on peut le déclarer directement dans le script d’exécution, sans distinguer dans le programme le mode production du mode développement.

[GN⁺]

Commentaires Hacker News

• Il vaut mieux éviter de transmettre des informations secrètes via des variables d’environnement. Elles peuvent fuiter facilement. À la place, il est préférable que le processus lise les secrets depuis un vault ou le système de fichiers.

• Si les fichiers `.env`` sont utilisés, c’est parce que c’est simple et clair. Si l’on veut un mode de configuration plus sûr et plus puissant, il faut lire la documentation.

• J’ai commencé à utiliser Mise pour les tâches. Je ne l’ai pas encore beaucoup utilisé, mais cela semble prometteur. Il gère des tâches comme l’initialisation d’une base de données de test locale, l’exécution de scripts de linting, ainsi que les variables d’environnement et les environnements virtuels.

• Les fuites de secrets étant un problème majeur, il est judicieux de chiffrer les secrets lorsqu’on utilise dotenvx. Un outil qui ne prend pas en charge les secrets non chiffrés est plus sûr.

• C’est similaire à Sops, mais sans chiffrement activé par défaut. Sops s’intègre facilement à AWS et aux solutions existantes de gestion de clés, et après l’avoir utilisé dans deux entreprises pendant cinq ans, l’expérience a été très positive.

• Chiffrer les secrets puis les commit peut être pratique, mais si quelqu’un accède à la clé de chiffrement, tous les secrets peuvent être exposés. Il est plus sûr de les configurer dans un gestionnaire de secrets cloud et de ne plus y toucher.

• Les variables d’environnement sont trop largement partagées, tandis que les fichiers dépendent des permissions locales. Il faut une nouvelle manière de transmettre des secrets entre processus. Par exemple, les faire passer via un socket Unix de façon à ce qu’ils ne puissent être lus qu’une seule fois.

• Il faudrait une documentation sur la bonne manière de placer un fichier .env dans un vault. Si le vault est protégé par mot de passe, cela pose le problème d’écrire en clair un moyen pour l’application de lire ce mot de passe.

• J’aimerais gérer toutes les variables d’environnement dans un seul fichier au format TOML. Cela faciliterait les mises à jour, les comparaisons et le partage. Mais il est difficile de maintenir une cohérence dans les noms d’environnement. Cela résulte souvent de décisions rapides ou de nécessités, et on hésite à les corriger.