Le traitement des mots de passe dans les référentiels serait géré de différentes manières en fonction de votre problème exact.
1. Ne le faites pas.
Et les moyens d'éviter de le faire sont traités dans certaines réponses - .gitignore, config.example, etc.
ou 2. Rendre le référentiel accessible uniquement aux personnes autorisées
C'est-à-dire les personnes autorisées à connaître le mot de passe. chmodet les groupes d'utilisateurs me viennent à l'esprit; des problèmes tels que les employés de Github ou AWS devraient-ils être autorisés à voir les choses si vous hébergez vos référentiels ou vos serveurs en externe?
ou 3. Chiffrer les données sensibles (objet de cette réponse)
Si vous souhaitez stocker vos fichiers de configuration contenant des informations sensibles (comme les mots de passe) dans un endroit public, ils doivent être cryptés. Les fichiers peuvent être décryptés lorsqu'ils sont récupérés à partir du référentiel, ou même utilisés directement à partir de leur forme cryptée.
Un exemple de solution javascript pour utiliser les données de configuration cryptées est illustré ci-dessous.
const fs = require('fs');
const NodeRSA = require('node-rsa');
let privatekey = new NodeRSA();
privatekey.importKey(fs.readFileSync('private.key', 'utf8'));
const config = privatekey.decrypt(fs.readFileSync('config.RSA', 'utf8'), 'json');
console.log('decrypted: ', config);
Vous pouvez donc récupérer un fichier de configuration crypté en écrivant seulement quelques lignes de Javascript.
Notez que le fait de placer un fichier config.RSAdans un référentiel git en ferait effectivement un fichier binaire et qu'il perdrait ainsi de nombreux avantages de quelque chose comme Git, par exemple la possibilité de choisir les modifications.
La solution à cela pourrait être de chiffrer des paires de valeurs clés ou peut-être simplement des valeurs. Vous pouvez crypter toutes les valeurs, par exemple si vous avez un fichier séparé pour les informations sensibles, ou crypter uniquement les valeurs sensibles si vous avez toutes les valeurs dans un fichier. (voir ci-dessous)
Mon exemple ci-dessus est un peu inutile pour quiconque souhaite faire un test avec lui, ou comme exemple pour commencer car il suppose l'existence de certaines clés RSA et d'un fichier de configuration crypté config.RSA.
Voici donc quelques lignes de code supplémentaires ajoutées pour créer des clés RSA et un fichier de configuration avec lequel jouer.
const fs = require('fs');
const NodeRSA = require('node-rsa');
/////////////////////////////
// Generate some keys for testing
/////////////////////////////
const examplekey = new NodeRSA({b: 2048});
fs.writeFileSync('private.key', examplekey.exportKey('pkcs8-private'));
fs.writeFileSync('public.key', examplekey.exportKey('pkcs8-public'));
/////////////////////////////
// Do this on the Machine creating the config file
/////////////////////////////
const configToStore = {Goodbye: 'Cruel world'};
let publickey = new NodeRSA();
publickey.importKey(fs.readFileSync('public.key', 'utf8'));
fs.writeFileSync('config.RSA', publickey.encrypt(configToStore, 'base64'), 'utf8');
/////////////////////////////
// Do this on the Machine consuming the config file
/////////////////////////////
let privatekey = new NodeRSA();
privatekey.importKey(fs.readFileSync('private.key', 'utf8'));
const config = privatekey.decrypt(fs.readFileSync('config.RSA', 'utf8'), 'json');
console.log('decrypted: ', config);
Chiffrement des valeurs uniquement
fs.writeFileSync('config.RSA', JSON.stringify(config,null,2), 'utf8');
Vous pouvez déchiffrer un fichier de configuration avec des valeurs chiffrées en utilisant quelque chose comme ça.
const savedconfig = JSON.parse(fs.readFileSync('config.RSA', 'utf8'));
let config = {...savedconfig};
Object.keys(savedconfig).forEach(key => {
config[key] = privatekey.decrypt(savedconfig[key], 'utf8');
});
Avec chaque élément de configuration sur une ligne distincte (par exemple Helloet Goodbyeau - dessus), Git reconnaîtra mieux ce qui se passe dans un fichier et stockera les modifications des éléments d'information sous forme de différences plutôt que de fichiers complets. Git sera également en mesure de mieux gérer les fusions et les choix de cerises, etc.
Cependant, plus vous souhaitez contrôler les versions des informations sensibles, plus vous vous déplacez vers une solution SAFE REPOSITORY (2) et loin d'une solution ENCRYPTED INFO (3).