git crypte/décrypte les fichiers du dépôt distant pendant le push/pull

Question

Est-il possible de chiffrer automatiquement les fichiers via 'git push' avant de les transférer vers un dépôt distant ? Et de les décoder automatiquement lors du "git pull".

Par exemple, si j'ai un serveur distant avec un accès partagé avec le dépôt git, et que je ne veux pas que notre projet soit volé sans permission... Peut-être y a-t-il des git-hooks spéciaux avant le push et après le pull ?

Answer 1

Oui et non.

Vous pourriez essayer de dépendre des crochets, mais cela suppose qu'ils soient installés sur les sites distants, ce qui n'est pas toujours fiable.

Une autre manière d'obtenir presque le même effet serait d'utiliser un conducteur du filtre de l'attribut de salissure/nettoyage , mais pas pour un repo complet .

(Source : Livre Pro Git : Personnalisation de Git - Attributs Git )

De cette façon, le script est capable de décoder les fichiers, tandis que le script propre les coderait.
Encore une fois, cela pourrait fonctionner pour quelques fichiers sensibles, pas pour un repo complet .

Bien sûr, ces scripts ne seraient pas dans le référentiel lui-même, et seraient gérés/communiqués d'une autre manière.

Comme Alcaline souligne dans les commentaires cette idée n'est pas adaptée à un dépôt, car le responsable principal de git Junio C. Hamano commente en 2009 :

Comme la seule raison d'être de diff.textconv est de permettre une conversion potentiellement (par exemple msword-to-text) appliquée à la paire de contenus préimage et postimage (qui sont censés être "propres") avant de donner un résultat textuel. (qui sont supposés être "propres") avant de donner une différence textuelle à la consommation humaine. diff à la consommation humaine.

La configuration ci-dessus peut sembler fonctionner, mais si vous voulez vraiment un référentiel crypté, vous devriez utiliser un système de fichiers crypté.
Cela présenterait l'avantage supplémentaire que l'arbre de travail associé à votre référentiel serait également crypté. .

---

Même s'il ne s'agit pas d'un repo complet, l'idée a été mise en œuvre (3 ans plus tard en 2013) avec git-crypt comme indiqué dans Dominic Cerisano 's réponse .
git-crypt utilise un pilote du filtre de contenu (implémenté en cpp, avec commands.cpp la mise en place de votre .gitattributes avec les autorités compétentes smudge et clean commandes de filtrage).
Comme tout pilote de filtre de contenu, vous pouvez alors limiter l'application de git-crypt à l'ensemble des fichiers que vous voulez, dans la même .gitattributes fichier :

secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt

Comme mentionné dans le README :

git-crypt s'appuie sur les filtres git, qui n'ont pas été conçus avec le chiffrement dans l'esprit.

En tant que tel, git-crypt n'est pas le meilleur outil pour chiffrer la plupart ou la totalité tous les fichiers d'un référentiel.
Où git-crypt est vraiment utile lorsque la majeure partie de votre référentiel est publique, mais que vous avez quelques fichiers (peut-être des clés privées nommées *.key ou un fichier contenant les informations d'identification de l'API) que vous devez chiffrer.

Pour crypter un référentiel entier, envisagez d'utiliser un système tel que git-remote-gcrypt à la place.

(voir la suite à spwhitton/ tech/ code/ git-remote-gcrypt , de Sean Whitton )

Answer 2

Vous pouvez jeter un coup d'œil à ce projet : https://github.com/shadowhand/git-encrypt

UPDATE : Ce projet ci-dessus est déprécié et il est recommandé d'utiliser https://github.com/AGWA/git-crypt

Answer 3

Comment sécuriser les ressources distantes publiques et privées en utilisant git-crypt .

• Transparent pour tous les clients et services git (ex. GitHub, BitBucket, etc).
• Prise en charge de Linux, OSX et Windows.
• Niveau de l'actif le cryptage (voir La réponse de VonC réponse ).
• AES-256 chiffré.

Créer votre clé privée de 256 bits (CONSERVER ET PROTÉGER CETTE CLÉ)

sudo apt install git-crypt 
mkdir key; cd key;
git init; git-crypt init
git-crypt export-key ~/crypt.key

Pousser un fichier appelé .gitattributes dans le répertoire racine de chaque repo.
Il doit contenir un modèle de ressource par fichier, répertoire ou type que vous souhaitez crypter :

docs/doc.txt  filter=git-crypt diff=git-crypt
js/**         filter=git-crypt diff=git-crypt
*.java        filter=git-crypt diff=git-crypt
src/cpp/*.h   filter=git-crypt diff=git-crypt

Crypter actifs dans chaque pension :

cd repo-root-directory
git-crypt unlock ~/crypt.key
git-crypt status -f
Push (from command line or git client)

Continuer votre flux de travail git comme d'habitude.

• Exécuter git-crypt unlock ~/crypt.key une fois sur tout nouveau clone de ces dépôts sécurisés.
• Vous pouvez souhaiter purger les anciens historiques de commit non cryptés sur toutes les branches. et les tags.
• Si vous utilisez un client git, il doit supporter entièrement les filtres et les diffs git.

Answer 4

Il y a deux façons de procéder.

La première consiste à utiliser un projet comme git-crypt, http://www.agwa.name/projects/git-crypt/ qui ajoute des ajusteurs pour tirer et pousser le processus, ou configurer les filtres manuellement comme décrit ici https://gist.github.com/shadowhand/873637

Une autre solution, si vous travaillez dans un environnement linux, consiste à utiliser ecryptfs. Pour ce scénario, à la base du répertoire de votre projet, vous pouvez, par exemple, créer deux répertoires

project/encrypted_src

project/src

Ensuite, à partir de la racine du répertoire du projet, vous monterez en utilisant la commande

sudo mount -t ecryptfs encrypted_src src

en entrant une phrase de passe et en acceptant les valeurs par défaut lorsque vous y êtes invité. À ce stade, les fichiers placés dans src/ seront chiffrés dans encrypted_src/ à la volée. Lorsque vous avez terminé, il suffit de

sudo umount src

et seuls les fichiers cryptés restent. Essentiellement, les fichiers sont envoyés et poussés depuis encrypted_src/ et édités dans src. Tant que tout le monde utilise la même phrase de passe (ou monte avec la même clé), le repo peut être partagé entre les développeurs. Il est également possible d'aller plus loin. Vous pouvez crypter les noms de fichiers ainsi que leur contenu, ou crypter différents dossiers dans un repo avec différentes phrases de passe ou clés. Cette dernière fonctionnalité est intéressante si vous avez des fichiers de configuration contenant des informations d'accès sensibles que des groupes individuels (dev, test, production) voudront conserver en privé.

Cela dit, soyez conscient qu'une fois que vous commencez à crypter des trucs. Vous perdez beaucoup des avantages du contrôle de source comme la possibilité de voir les différences entre les différents commits. Si vous avez un projet d'une certaine taille, la possibilité de revoir les commits sera inestimable. Si vous vous attendez à des bogues, à un moment ou à un autre, la possibilité d'analyser et de trouver leur point d'introduction en remontant l'historique des commits sera également inestimable. Sécurisez donc d'abord votre serveur, puis n'utilisez le cryptage que lorsque cela est nécessaire pour protéger les informations sensibles dans le contrôle des sources. Ce ne sont que mes deux centimes.

Answer 5

Il existe des crochets Tahoe-LAFS fournis par git-annex qui, il faut bien l'admettre, est peut-être plus compliqué que nécessaire.