agwa/git-cryptChiffrement transparent des fichiers dans git
git-crypt permet le chiffrement et le déchiffrement transparents des fichiers dans un dépôt git. Les fichiers que vous choisissez de protéger sont chiffrés lors du commit, et déchiffrés lors du checkout. git-crypt vous permet de partager librement un dépôt contenant un mélange de contenu public et privé. git-crypt se dégrade gracieusement, de sorte que les développeurs sans la clé secrète peuvent toujours cloner et commiter dans un dépôt avec des fichiers chiffrés. Cela vous permet de stocker vos données secrètes (telles que des clés ou mots de passe) dans le même dépôt que votre code, sans avoir à verrouiller l'intégralité du dépôt.
git-crypt a été écrit par Andrew Ayer ([email protected]). Pour plus d'informations, voir https://www.agwa.name/projects/git-crypt.
Voir le fichier INSTALL.md.
Configurez un dépôt pour utiliser git-crypt :
cd repo
git-crypt init
Spécifiez les fichiers à chiffrer en créant un fichier .gitattributes :
secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt
secretdir/** filter=git-crypt diff=git-crypt
Comme un fichier .gitignore, il peut correspondre à des motifs génériques et doit être commité dans le dépôt. Voir ci-dessous pour plus d'informations sur .gitattributes. Assurez-vous de ne pas chiffrer accidentellement le fichier .gitattributes lui-même (ou d'autres fichiers git comme .gitignore ou .gitmodules). Assurez-vous que vos règles .gitattributes sont en place avant d'ajouter des fichiers sensibles, sinon ces fichiers ne seront pas chiffrés !
Partagez le dépôt avec d'autres (ou avec vous-même) en utilisant GPG :
git-crypt add-gpg-user USER_ID
USER_ID peut être un ID de clé, une empreinte complète, une adresse email, ou
tout ce qui identifie de manière unique une clé publique pour GPG (voir « HOW TO
SPECIFY A USER ID » dans la page de manuel de gpg). Remarque : git-crypt add-gpg-user
ajoutera et commitera un fichier de clé chiffré par GPG dans le répertoire .git-crypt
à la racine de votre dépôt.
Alternativement, vous pouvez exporter une clé secrète symétrique, que vous devez transmettre de manière sécurisée aux collaborateurs (GPG n'est pas nécessaire, et aucun fichier n'est ajouté à votre dépôt) :
git-crypt export-key /path/to/key
Après avoir cloné un dépôt avec des fichiers chiffrés, déverrouillez avec GPG :
git-crypt unlock
Ou avec une clé symétrique :
git-crypt unlock /path/to/key
C'est tout ce que vous devez faire - après avoir configuré git-crypt (soit avec
git-crypt init ou git-crypt unlock), vous pouvez utiliser git normalement -
le chiffrement et le déchiffrement se produisent de manière transparente.
La dernière version de git-crypt est 0.8.0, publiée le 2025-09-23. git-crypt vise à être sans bug et fiable, ce qui signifie qu'il ne devrait pas planter, mal fonctionner, ou exposer vos données confidentielles. Cependant, il n'a pas encore atteint la maturité, ce qui signifie qu'il n'est pas aussi documenté, riche en fonctionnalités ou facile à utiliser qu'il le devrait. De plus, des changements incompatibles avec les versions antérieures peuvent être introduits avant la version 1.0.
git-crypt est plus sécurisé que les autres systèmes de chiffrement git transparents. git-crypt chiffre les fichiers en utilisant AES-256 en mode CTR avec un IV synthétique dérivé du HMAC SHA-1 du fichier. Ce mode de fonctionnement est prouvé sémantiquement sûr contre une attaque à texte clair choisi déterministe. Cela signifie que bien que le chiffrement soit déterministe (ce qui est nécessaire pour que git puisse distinguer quand un fichier a changé ou non), il ne divulgue aucune information au-delà de savoir si deux fichiers sont identiques ou non. D'autres propositions pour le chiffrement git transparent utilisent ECB ou CBC avec un IV fixe. Ces systèmes ne sont pas sémantiquement sûrs et divulguent des informations.
git-crypt repose sur les filtres git, qui n'ont pas été conçus pour le chiffrement. En tant que tel, git-crypt n'est pas le meilleur outil pour chiffrer la plupart ou la totalité des fichiers d'un dépôt. Là où git-crypt brille vraiment, c'est lorsque la majeure partie de votre dépôt est publique, mais que vous avez quelques fichiers (peut-être des clés privées nommées *.key, ou un fichier avec des identifiants API) que vous devez chiffrer. Pour chiffrer un dépôt entier, envisagez d'utiliser un système comme git-remote-gcrypt à la place. (Remarque : aucune approbation n'est faite de la sécurité de git-remote-gcrypt.)
git-crypt ne chiffre pas les noms de fichiers, les messages de commit, les cibles de liens symboliques, les gitlinks, ou d'autres métadonnées.
git-crypt ne cache pas quand un fichier change ou non, la longueur d'un fichier, ou le fait que deux fichiers sont identiques (voir la section « Sécurité » ci-dessus).
git-crypt ne prend pas en charge la révocation de l'accès à un dépôt chiffré qui a été précédemment accordé. Cela s'applique à la fois au mode multi-utilisateur GPG (il n'y a pas de commande del-gpg-user pour compléter add-gpg-user) et également au mode à clé symétrique (il n'y a pas de support pour la rotation de la clé). C'est parce que c'est un problème intrinsèquement complexe dans le contexte des données historiques. Par exemple, même si une clé a été tournée à un moment de l'historique, un utilisateur possédant la clé précédente peut toujours accéder à l'historique précédent du dépôt. Ce problème est discuté plus en détail dans https://github.com/AGWA/git-crypt/issues/47.
Les fichiers chiffrés avec git-crypt ne sont pas compressibles. Même le plus petit changement dans un fichier chiffré oblige git à stocker le fichier entier modifié, au lieu d'un simple delta.
Bien que git-crypt protège le contenu individuel des fichiers avec un HMAC SHA-1, git-crypt ne peut pas être utilisé de manière sécurisée à moins que l'ensemble du dépôt soit protégé contre la falsification (un attaquant qui peut modifier votre dépôt peut altérer votre fichier .gitattributes pour désactiver le chiffrement). Si nécessaire, utilisez des fonctionnalités git telles que les tags signés plutôt que de compter uniquement sur git-crypt pour l'intégrité.
Les fichiers chiffrés avec git-crypt ne peuvent pas être patchés avec
git-apply, à moins que le patch lui-même soit chiffré. Pour générer un
patch chiffré, utilisez git diff --no-textconv --binary.
Alternativement, vous pouvez appliquer un patch en texte clair en dehors
de git en utilisant la commande patch.
git-crypt ne fonctionne pas de manière fiable avec certaines interfaces graphiques git tierces, telles que Atlassian SourceTree et GitHub pour Mac. Les fichiers peuvent être laissés dans un état non chiffré.
Le fichier .gitattributes est documenté dans la page de manuel
gitattributes(5). Le format de motif de fichier est le même que celui
utilisé par .gitignore, comme documenté dans la page de manuel
gitignore(5), à l'exception que spécifier simplement un répertoire
(par exemple /dir/) n'est pas suffisant pour chiffrer tous les
fichiers en dessous.
Notez également que le motif dir/* ne correspond pas aux fichiers dans
les sous-répertoires de dir/. Pour chiffrer toute une sous-arborescence
dir/, utilisez dir/** :
dir/** filter=git-crypt diff=git-crypt
Le fichier .gitattributes ne doit pas être chiffré, alors assurez-vous que les motifs génériques ne correspondent pas accidentellement. Si nécessaire, vous pouvez exclure .gitattributes du chiffrement comme ceci :
.gitattributes !filter !diff