Vous avez parfaitement raison de vouloir crypter votre fichier de paramètres sensibles tout en conservant le fichier dans le contrôle de version. Comme vous le mentionnez, la meilleure solution serait celle dans laquelle Git cryptera de manière transparente certains fichiers sensibles lorsque vous les poussez afin que localement (c'est-à-dire sur toute machine possédant votre certificat) vous puissiez utiliser le fichier de paramètres, mais Git ou Dropbox ou qui que ce soit le stockage de vos fichiers sous VC ne permet pas de lire les informations en texte brut.
Tutoriel sur le cryptage / décryptage transparent pendant Push / Pull
Cet essentiel https://gist.github.com/873637 montre un tutoriel sur la façon d'utiliser le pilote de filtre smudge / clean de Git avec openssl pour crypter de manière transparente les fichiers poussés. Il vous suffit de faire une configuration initiale.
Résumé de son fonctionnement
Vous allez essentiellement créer un .gitencrypt
dossier contenant 3 scripts bash,
clean_filter_openssl
smudge_filter_openssl
diff_filter_openssl
qui sont utilisés par Git pour le déchiffrement, le chiffrement et la prise en charge de Git diff. Une phrase de passe principale et un salt (corrigé!) Sont définis dans ces scripts et vous DEVEZ vous assurer que .gitencrypt n'est jamais réellement poussé. Exemple de clean_filter_openssl
script:
#!/bin/bash
SALT_FIXED=<your-salt> # 24 or less hex characters
PASS_FIXED=<your-passphrase>
openssl enc -base64 -aes-256-ecb -S $SALT_FIXED -k $PASS_FIXED
Similaire pour smudge_filter_open_ssl
et diff_filter_oepnssl
. Voir Gist.
Votre dépôt contenant des informations sensibles doit avoir un fichier .gitattribute (non chiffré et inclus dans le dépôt) qui fait référence au répertoire .gitencrypt (qui contient tout ce dont Git a besoin pour chiffrer / déchiffrer le projet de manière transparente) et qui est présent sur votre machine locale.
.gitattribute
Contenu:
* filter=openssl diff=openssl
[merge]
renormalize = true
Enfin, vous devrez également ajouter le contenu suivant à votre .git/config
fichier
[filter "openssl"]
smudge = ~/.gitencrypt/smudge_filter_openssl
clean = ~/.gitencrypt/clean_filter_openssl
[diff "openssl"]
textconv = ~/.gitencrypt/diff_filter_openssl
Désormais, lorsque vous transférez le référentiel contenant vos informations sensibles vers un référentiel distant, les fichiers seront chiffrés de manière transparente. Lorsque vous effectuez une extraction à partir d'une machine locale qui a le répertoire .gitencrypt (contenant votre phrase de passe), les fichiers seront déchiffrés de manière transparente.
Remarques
Je dois noter que ce tutoriel ne décrit pas un moyen de chiffrer uniquement votre fichier de paramètres sensibles. Cela cryptera de manière transparente l'ensemble du référentiel qui est poussé vers l'hôte VC distant et décryptera l'intégralité du référentiel afin qu'il soit entièrement décrypté localement. Pour obtenir le comportement souhaité, vous pouvez placer des fichiers sensibles pour un ou plusieurs projets dans un sensitive_settings_repo. Vous pouvez étudier comment cette technique de chiffrement transparent fonctionne avec les sous-modules Git http://git-scm.com/book/en/Git-Tools-Submodules si vous avez vraiment besoin que les fichiers sensibles se trouvent dans le même référentiel.
L'utilisation d'une phrase secrète fixe pourrait théoriquement conduire à des vulnérabilités de force brute si les attaquants avaient accès à de nombreux dépôts / fichiers cryptés. OMI, la probabilité de cela est très faible. Comme une note au bas de ce tutoriel le mentionne, le fait de ne pas utiliser de phrase secrète fixe entraînera des versions locales d'un dépôt sur différentes machines montrant toujours que des modifications ont eu lieu avec 'git status'.