2009-11-22 19 views
1

J'ai des projets sur lesquels travaillent plusieurs développeurs. Nous travaillons tous sur le même dépôt git.Comment stockez-vous des informations cryptées dans un référentiel DVCS public?

Actuellement, je ne stocke pas la configuration du serveur de production dans le référentiel, car les fichiers de configuration contiennent des informations d'identification de base de données. Je voudrais commencer à stocker ces configurations dans le référentiel, donc je pense à crypter les fichiers de configuration avant de les enregistrer dans le DVCS.

  1. Que pensez-vous de cette idée?
  2. Comment cela se ferait-il? Pourquoi ces secrets doivent-ils être stockés dans le référentiel public?
+0

Pas exactement sûr du processus, mais il impliquerait sûrement un gestionnaire de fusion à un moment donné pour gérer ces fichiers cryptés (non fusionnables). Voir http://stackoverflow.com/questions/1288480 – VonC

+0

Pourquoi voulez-vous les chiffrer? Vous ne faites pas confiance à vos développeurs? – liori

+0

Je travaille avec des développeurs du monde entier. Je leur fais personnellement confiance, mais je détesterais avoir tort. Si je me trompe, cela se produira au moindre moment et risque d'avoir les conséquences les plus graves. Je préfère gérer mon incertitude plutôt que l'espoir et la confiance que rien n'arrivera jamais. –

Répondre

5

Pourquoi ces secrets doivent-ils être stockés dans le référentiel public?

Je voudrais utiliser un mécanisme complètement différent pour distribuer ces secrets, qui est seulement accessible aux admins qui ont besoin d'y accéder.

+0

Comme quoi? ..... –

+1

Comme un dépôt séparé avec juste les fichiers de configuration secrets avec un accès admin uniquement à l'ensemble du repo. Ou tout ce que les administrateurs système utilisent pour ce genre de choses. Marionnette et ses confrères de la configuration logicielle viennent à l'esprit. Cela devient plus dans le territoire de sysadmin que dans le territoire de programmation, cependant. – ndim

+0

Cela pourrait être une solution en fait, car alors je pourrais contrôler la version des paramètres, mais ils seraient versionnés séparément du code source, ce qui est un problème. –

2

Nous chiffrons les mots de passe dans les fichiers de configuration, et l'application utilise une clé saisie de manière interactive au moment de l'exécution pour les déchiffrer. En raison du système de configuration que nous utilisons, seul l'analyseur de configuration a dû être modifié. le code de l'application lui-même ne nécessitait aucun changement. Le principal inconvénient est que nous utilisons un algorithme à clé publique, de sorte que n'importe qui peut chiffrer une valeur pour le fichier de configuration, mais seuls les utilisateurs autorisés peuvent les déchiffrer. Cela rend les valeurs cryptées beaucoup plus grandes (nous utilisons une clé RSA de 2048 bits, et encodons avec Base-64) et un peu moche dans les fichiers de configuration.

Nous prenons toujours soin de coder les métadonnées avec la valeur chiffrée. Ceci identifie la clé de chiffrement, les algorithmes utilisés et les paramètres nécessaires pour les algorithmes. De cette façon, nous pouvons modifier les clés ou les algorithmes avec élégance, en migrant sur une certaine période de temps.