48 votes

Mise en place d'un référentiel git crypté

Situation

Bonjour, je voudrais enregistrer des données avec git, chiffrées (sur une plateforme comme bitbucket ou github). Par conséquent, la question :

Question

Je recherche différentes façons simples de :
Comment mettre en place un dépôt chiffré sur bitbucket (ou github) ? Actuellement, je suis novice en git, donc des instructions avec toutes les étapes nécessaires ou étape par étape seraient grandement appréciées !

"Recherche"

git-crypt
J'ai trouvé git-crypt, mais le site mentionne qu'il est conçu pour le chiffrement de fichiers individuels. S'il est nécessaire de chiffrer l'ensemble du dépôt, ils renvoient vers git-remote-gcrypt.

git-remote-gcrypt
Dans leur README.rst, ils le présentent de manière simple

Démarrage rapide

git remote add cryptremote gcrypt::rsync://example.com:repo
git push cryptremote master
> gcrypt: Configuration du nouveau dépôt
> gcrypt: L'identifiant distant est :id:7VigUnLVYVtZx8oir34R
> [ plus de lignes .. ]
> Vers gcrypt::[...]
> * [nouvelle branche]      master -> master

ou sous

Exemples

# veuillez noter que le dépôt git cible doit déjà exister et sa
# branche `next` sera écrasée !
git remote add gitcrypt gcrypt::git@example.com:repo#next
git push gitcrypt master

Essais

Je préfère le chiffrement complet du dépôt, donc j'ai essayé git-remote-gcrypt avec des variantes du Démarrage rapide et de l'Exemple. Jusqu'à présent, j'ai essayé de pousser un dépôt existant en suivant leurs instructions. Ce qui donne ceci : (note : j'ai volontairement changé le nom d'utilisateur en user)

-> avec ssh comme dans l'exemple fourni

[...]/git_test$ git remote add origin gcrypt::git@bitbucket.org:user/test.git
[...]/git_test$ git push -u origin --allgcrypt: Version de développement -- Le format du dépôt PEUT CHANGER
gcrypt: Dépôt non trouvé : git@bitbucket.org:user/test.git
gcrypt: Configuration du nouveau dépôt
gcrypt: L'identifiant distant est :id: ...
Zähle Objekte: 10, Terminé.
Komprimiere Objekte: 100% (6/6), Terminé.
Total 10 (delta 0), réutilisé 0 (delta 0)
gcrypt: Chiffrement vers : --throw-keyids --default-recipient-self
gcrypt: Demande de signature du manifeste
Permission refusée (clé publique).
fatal: Impossible de lire depuis le dépôt distant.

Assurez-vous d'avoir les droits d'accès corrects
et que le dépôt existe.
error: Erreur lors de l'envoi de certaines références vers 'gcrypt::git@bitbucket.org:user/test.git'

ou avec https (qui a fonctionné)

[...]/git_test$ git remote add gitcrypt gcrypt::https://user@bitbucket.org/user/test.git
[...]/git_test$ git push -u gitcrypt --allgcrypt: Version de développement -- Le format du dépôt PEUT CHANGER
Mot de passe pour 'https://user@bitbucket.org': 
gcrypt: Dépôt non trouvé : https://user@bitbucket.org/user/test.git
gcrypt: Configuration du nouveau dépôt
Mot de passe pour 'https://user@bitbucket.org': 
gcrypt: L'identifiant distant est :id: ...
Zähle Objekte: 10, Terminé.
Komprimiere Objekte: 100% (6/6), Terminé.
Total 10 (delta 0), réutilisé 0 (delta 0)
gcrypt: Chiffrement vers : --throw-keyids --default-recipient-self
gcrypt: Demande de signature du manifeste
Mot de passe pour 'https://user@bitbucket.org': 
Vers gcrypt::https://user@bitbucket.org/user/test.git
 * [nouvelle branche]      master -> master
La branche master est configurée pour suivre la branche distante master de gitcrypt.

Cependant, je ne comprends pas comment ajouter des utilisateurs ou même simplement récupérer ma sauvegarde sur une autre machine (puisque ma clé gpg a été générée localement) !? N'hésitez pas à répondre seulement sur l'utilisation de git-remote-gcrypt.

24voto

harrymc Points 394411

Un outil gratuit et partiellement open-source est Keybase :

Git prend en charge les assistants distants. Et nous en avons créé un open source.

L'assistant distant de Keybase effectue toute la crypto tout en permettant à git de faire son travail. Cela peut sembler impressionnant, mais Keybase n'a pas réimplémenté git de zéro. Nous fournissons un assistant distant, alimenté par l'excellent projet go-git, auquel nous avons commencé à contribuer.

Nous apportons : (1) de la crypto, (2) la gestion des clés d'équipe + multi-appareils, (3) un concept plus sûr d'identité.

C'est chiffré de bout en bout. C'est hébergé, comme, disons, GitHub, mais vous (et vos coéquipiers) seuls pouvez le décrypter. Pour Keybase, tout n'est qu'un désordre crypté. Pour vous, c'est un checkout normal sans étapes supplémentaires.

Même les noms de vos dépôts et de vos branches sont chiffrés, et donc illisibles par le personnel de Keybase ou des infiltrés.

La collaboration est prise en charge via Keybase Teams :

Une équipe Keybase est un groupe de personnes nommé, avec une adhésion flexible. Disons que vous travaillez sur un projet appelé Treehouse. Vous pourriez enregistrer treehouse sur Keybase. Ce nom d'équipe est universel ; il ne peut y avoir qu'une seule équipe Keybase avec un nom donné.

Les équipes ont des discussions et des chaînes. La discussion ressemble un peu à Slack ou Discord :

Mais la collaboration Keybase est chiffrée de bout en bout, ce qui signifie que vous n'avez pas à vous soucier des piratages de serveurs.

Keybase

4voto

Jon Doe Points 57

Instructions étape par étape, en utilisant git-remote-gcrypt et Bitbucket :

Prérequis

  • GnuPG (brew install gpg sur macOS)
  • git-remote-gcrypt (brew install git-remote-gcrypt sur macOS)

Vue d'ensemble

Ce guide vous guidera à travers le processus de création et d'utilisation d'un dépôt git appelé "gcrypt-sample" avec Bitbucket, en profitant de git-remote-crypt avec une paire de clés PGP dédiée pour fournir un cryptage de bout en bout.

Chaque push sera un push forcé !

Étapes

Mise en place

  1. Configurez vos dépôts locaux et distants :
    • Configurez le dépôt local avec git init gcrypt-sample
    • Sur bitbucket.org, créez un dépôt gcrpyt-sample
  2. Configurez votre clé ssh si ce n'est pas déjà fait : ssh-keygen
  3. Ajoutez un remote gcrypt : git remote add cryptremote gcrypt::git@bitbucket.org:user/gcrypt-sample.git
  4. Générez votre paire de clés GPG. Nous recommandons ce guide; pour cet exemple, simplement exécuter gpg --gen-key fonctionnera.
  5. Configurez gcrypt pour accepter la clé gpg que vous venez de créer :
    1. git config remote.cryptremote.gcrypt-participants
    2. git config remote.cryptremote.gcrypt-signingkey
  6. Modifiez votre dépôt git :
    1. echo 'Bonjour, monde !' > hello.txt
    2. git add hello.txt
    3. git commit
  7. git push -u cryptremote master
    • Si vous avez plusieurs paires de clés PGP, vous devrez les parcourir jusqu'à obtenir celle que vous voulez, car vous tirez avant de pousser, à chaque fois ; voir la note ci-dessous.

Un mot sur la récupération du dépôt

Chaque fois que vous récupérez (inclus lorsque vous poussez), vous devrez parcourir vos clés PGP jusqu'à obtenir la bonne. La raison en est que par défaut, git-remote-gcrypt utilise une garde de confidentialité qui masque l'identité de la clé de signature. Par conséquent, lorsque vous tirez du dépôt, vous devez vérifier toutes vos clés disponibles pour voir laquelle est la clé de signature. La clé de signature utilisée peut être publiée (et donc l'anonymat révoqué) en définissant la propriété remote.cryptremote.gcrypt-publish-participants (à n'importe quoi).

Si vous définissez une clé PGP explicite et unique pour le dépôt, cela devrait fonctionner. Cependant, cela a des implications pour les dépôts partagés (différents commits peuvent être liés de manière indéniable à différents utilisateurs).

Qu'est-ce qui est crypté ?

À mes yeux nus, presque tout.

Ce qui est crypté

  • Noms de fichiers (y compris les chemins)
  • Contenu des fichiers
  • Branches (je ne sais pas si la première branche poussée est consignée sous master, mais toutes les suivantes l'étaient)
  • Historique des commits : Il y a un seul commit ("Commit initial") et une seule date (bien que les dates de vos pushes puissent être suivies par votre distant séparément, bien sûr - "Dernière mise à jour" de BitBucket affiche l'heure exacte. Bien sûr, Bitbucket ne prête probablement pas attention aux commits eux-mêmes - on suppose probablement que vous le faites.)

Ce qui n'est PAS crypté

  • Nom du dépôt (bien que cela soit assez évident) ; utilisez simplement un nom de code
  • Le nombre ou la taille des fichiers (ils ne sont pas distribués de quelque manière que ce soit) ; je ne suis pas sûr des implications pour les différentes branches

0voto

Asclepius Points 911

Cela peut être accompli de manière découplée en utilisant un outil de système de fichiers chiffré dans l'espace utilisateur activement développé tel que gocryptfs ou cryptomator. Les chemins des fichiers sont également chiffrés.

Utilisation de gocryptfs

Personnellement, je préfère gocryptfs à cryptomator car le premier est un binaire unique et peut également être plus facilement automatisé. Cela même si cryptomator semble être un projet plus mûr.

gec est un utilitaire bash qui tente de rendre plus pratique l'utilisation d'un système de fichiers gocryptfs chiffré dans un dépôt git. À noter au minimum l'option -sharedstorage qu'il utilise avec gocryptfs.

Utilisation de Cryptomator

  1. Créez un coffre-fort chiffré dans par exemple ~/cryptomator/encrypted/myvault1. Supprimez éventuellement le fichier inutile IMPORTANT.rtf de ce répertoire.
  2. Exécutez git init dans le répertoire ci-dessus contenant le coffre-fort chiffré. Ajoutez une ou plusieurs URL distantes git.
  3. Déchiffrez le coffre-fort dans par exemple ~/cryptomator/decrypted/myvault1. Ajoutez ou changez un ou plusieurs fichiers dans le coffre-fort déverrouillé.
  4. Validez et poussez tous les changements dans le dépôt git.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X