git-remote-gcrypt

Dépôt git chiffré avec GNU Privacy Guard

:Section du manuel : 1

Description

git-remote-gcrypt est un auxiliaire de dépôt git permettant d'envoyer et de recevoir depuis des dépôts chiffrés avec GnuPG, en utilisant un format personnalisé. Cet auxiliaire gère les URI préfixées par gcrypt::.

Les backends pris en charge sont local, rsync:// et sftp://, où le dépôt est stocké sous forme d'un ensemble de fichiers, ou bien tout <giturl> où gcrypt stockera la même représentation dans un dépôt git, en utilisant un transport git arbitraire. Préférez local ou rsync:// si vous pouvez en utiliser un ; voir « Performances » ci-dessous pour une discussion.

Il existe aussi un backend rclone:// expérimental réservé aux premiers adoptants (vous êtes prévenus).

L'objectif est de fournir un stockage et une collaboration git confidentiels et authentifiés en utilisant des hébergeurs ou services de fichiers généralement non fiables.

Installation ............

• utilisez le gestionnaire de paquets de votre distribution GNU/Linux — Debian, Ubuntu, Fedora, Arch et quelques distributions plus petites ont des paquets

• exécutez le script install.sh fourni sur d'autres systèmes

Prise en main rapide ..........

Créez un dépôt distant chiffré en poussant dessus ::

git remote add cryptremote gcrypt::rsync://example.com/repo
git push cryptremote master
> gcrypt: Setting up new repository
> gcrypt: Remote ID is :id:7VigUnLVYVtZx8oir34R
> [ more lines .. ]
> To gcrypt::[...]
> * [new branch]      master -> master

Configuration

Les variables git-config(1) suivantes sont prises en charge :

remote.<name>.gcrypt-participants .. gcrypt.participants Liste séparée par des espaces d'identifiants de clés GPG. Le dépôt distant est chiffré pour ces participants et seules les signatures de ceux-ci sont acceptées. gpg -k liste toutes les clés publiques que vous connaissez.

Si cette option n'est pas définie, nous chiffrons avec votre clé par défaut et acceptons toute signature valide. Ce comportement peut aussi être demandé explicitement en réglant les participants à ``simple``.

Le paramètre ``gcrypt-participants`` sur le dépôt distant a la priorité sur la variable de dépôt ``gcrypt.participants``.

remote.<name>.gcrypt-publish-participants .. gcrypt.publish-participants Par défaut, les identifiants de clés GPG des participants sont masqués en chiffrant avec gpg -R. Définir cette option à true désactive cette mesure de sécurité.

Le problème avec l'utilisation de ``gpg -R`` est que pour déchiffrer, gpg essaie chaque clé secrète disponible à tour de rôle jusqu'à trouver une clé utilisable. Cela peut entraîner des demandes de phrase de passe superflues.

gcrypt.gpg-args Le contenu de ce paramètre est passé comme arguments à gpg. Par ex. --use-agent.

remote.<name>.gcrypt-signingkey .. user.signingkey (Ce dernier provient de la configuration git standard) La clé à utiliser pour signer. Vous devriez définir user.signingkey si votre clé de signature par défaut ne fait pas partie de la liste des participants. Vous pouvez utiliser la version par dépôt distant pour signer différents dépôts distants avec différentes clés.

remote.<name>.gcrypt-rsync-put-flags .. gcrypt.rsync-put-flags Options à passer à rsync lors du téléversement vers un dépôt distant avec le backend rsync://. Si les options sont définies pour un dépôt distant spécifique, les options globales, si également définies, ne seront pas appliquées pour ce dépôt.

remote.<name>.gcrypt-require-explicit-force-push .. gcrypt.require-explicit-force-push Un bogue de longue date est que chaque git push a effectivement un --force.

Si ce drapeau est défini à ``true``, git-remote-gcrypt refusera de pousser, sauf si ``--force`` est passé, ou si les refspecs sont préfixées par ``+``.

Il existe une solution potentielle ici : https://bugs.debian.org/877464#32

Variables d'environnement

GCRYPT_FULL_REPACK Lorsque définie (à n'importe quelle valeur autre que la chaîne vide), cette variable d'environnement force un réempaquetage complet lors de la poussée.

Exemples

Comment configurer un dépôt distant pour deux participants ::

git remote add cryptremote gcrypt::rsync://example.com/repo
git config remote.cryptremote.gcrypt-participants "KEY1 KEY2"
git push cryptremote master

Comment utiliser un backend git ::

# remarquez que le dépôt git cible doit déjà exister et que
# sa branche `next` sera écrasée !
git remote add gitcrypt gcrypt::[email protected]:repo#next
git push gitcrypt master

Le fragment d'URL (#next ici) indique quelle branche du backend est utilisée.

Notes

Collaboration Le chiffrement du manifeste est mis à jour pour chaque poussée afin de correspondre à la configuration des participants. Chaque utilisateur poussant doit posséder les clés publiques de tous les collaborateurs et une configuration participant correcte.

Dépendances rsync, curl et rclone pour les dépôts distants rsync:, sftp: et rclone: respectivement. L'exécutable principal nécessite un shell compatible POSIX supportant local.

GNU Privacy Guard GPG 1.4 et 2 sont tous deux pris en charge. Vous avez besoin d'une clé GPG personnelle. La configuration de GPG s'applique aux choix d'algorithmes pour le chiffrement à clé publique, le chiffrement symétrique et la signature. Voir man gpg pour plus d'informations.

Identifiant de dépôt distant L'identifiant de dépôt distant n'est pas secret ; il garantit seulement que deux dépôts signés par le même utilisateur peuvent être distingués. Vous verrez un avertissement si l'identifiant change, ce qui ne devrait se produire que si le dépôt distant a été recréé.

Performances Utiliser un <giturl> quelconque ou une URI sftp:// nécessite de téléverser l'intégralité de l'historique du dépôt à chaque poussée. Cela signifie que les poussées de votre dépôt deviennent plus lentes avec le temps, à mesure que votre historique git s'allonge, et il peut facilement arriver un point où l'utilisation continue de git-remote-gcrypt devient impraticable.

Par conséquent, vous ne devriez utiliser ces backends que lorsque vous savez que votre dépôt ne deviendra jamais très volumineux, pas seulement qu'il ne l'est pas maintenant. Cela signifie que ces backends sont inappropriés pour la plupart des dépôts, et probablement adaptés uniquement à des cas inhabituels, comme de petits dépôts d'identifiants. Même dans ce cas, utilisez `rsync://` si vous le pouvez. Notez cependant que `rsync://` ne fonctionnera pas avec un service d'hébergement de dépôts comme Gitolite, GitHub ou GitLab.

URI rsync Le format d'URI pour le backend rsync est rsync://user@host/path, qui se traduit par l'emplacement rsync user@host:/path, accessible via SSH. Notez que le chemin est absolu, pas relatif au répertoire personnel. Un format d'URI non standard plus ancien est également pris en charge : rsync://user@host:path, qui se traduit par l'emplacement rsync user@host:path.

Backend rclone En plus d'ajouter le backend rclone comme dépôt distant avec une URI comme gcrypt::rclone://remote:subdir, vous devez également ajouter le dépôt distant à la configuration de rclone. Cela se fait généralement en exécutant rclone config. Voir rclone(1).

Le backend rclone est considéré comme expérimental et est réservé aux premiers adoptants. Vous êtes prévenus.

Format du dépôt .................

| EncSign(X) : Signer et Chiffrer pour le détenteur de la clé GPG | Encrypt(K,X) : Chiffrer en utilisant un algorithme à clé symétrique | Hash(X) : SHA-2/256 | | B : liste des branches | L : liste du hachage (Hi) et de la clé (Ki) pour chaque fichier de paquet | R : Identifiant du dépôt distant | | Pour écrire le dépôt : | | Stocker chaque fichier de paquet P comme Encrypt(Ki, P) → P' dans le fichier nommé Hi | où Ki est une nouvelle chaîne aléatoire et Hash(P') → | Stocker dans le manifeste | | Pour lire le dépôt : | | Obtenir le manifeste, le déchiffrer et le vérifier avec le trousseau GPG → | Avertir si ne correspond pas à l'identifiant de dépôt distant précédemment vu | pour chaque dans : | Obtenir le fichier du serveur → | Vérifier que correspond à | Déchiffrer avec → puis ouvrir avec git

Fichier manifeste .............

Exemple de fichier manifeste (avec des points de suspension par souci de concision) ::

$ gpg -d 91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a
542051c7cd152644e4995bda63cc3ddffd635958 refs/heads/next
3c9e76484c7596eff70b21cbe58408b2774bedad refs/heads/master
pack :SHA256:f2ad50316...cd4ba67092dc4 z8YoAnFpMlW...3PkI2mND49P1qm
pack :SHA256:a6e17bb4c...426492f379584 82+k2cbiUn7...dgXfyX6wXGpvVa
keep :SHA256:f2ad50316...cd4ba67092dc4 1
repo :id:OYiSleGirtLubEVqJpFF

Chaque élément s'étend jusqu'à la nouvelle ligne et correspond à l'un des suivants :

<sha-1> <gitref> Identifiant d'objet Git et sa référence

pack :<hashtype>:<hash> <key> Hachage du fichier de paquet (Hi) et clé symétrique correspondante (Ki).

keep :<hashtype>:<hash> <generation> Hachage du fichier de paquet et sa génération de réempaquetage

repo <id> L'identifiant du dépôt distant

extn <name> ... Champ d'extension, conservé mais inutilisé.

Détection des dépôts gcrypt

Pour détecter si une URL git est un dépôt gcrypt, utilisez : git-remote-gcrypt --check url Le code de sortie est 0 si le dépôt existe et peut être déchiffré, 1 si le dépôt utilise gcrypt mais n'a pas pu être déchiffré, et 100 si le dépôt n'est pas chiffré avec gcrypt (ou n'a pas pu être accédé).

Notez que cela nécessite de récupérer le contenu du dépôt dans le dépôt git local, comme c'est le cas lors de l'utilisation d'un dépôt gcrypt.

Problèmes connus

Chaque git push a effectivement un --force. Assurez-vous de récupérer (pull) avant de pousser.

git-remote-gcrypt peut décider de réempaqueter le dépôt distant sans avertissement, ce qui signifie que votre poussée peut soudainement prendre beaucoup plus de temps que prévu, car tout votre historique doit être retéléversé. Cette poussée pourrait échouer sur une liaison de mauvaise qualité.

git-remote-gcrypt peut signaler un dépôt comme « introuvable » alors que le dépôt existe bien, mais que git-remote-gcrypt rencontre des problèmes d'authentification, de port ou de connectivité réseau.

Voir aussi

git-remote-helpers(1), gpg(1)

Crédits

L'auteur original de git-remote-gcrypt est l'utilisateur GitHub bluss.

Le mainteneur de facto en 2013 et 2014 était Joey Hess.

Le mainteneur actuel, depuis 2016, est Sean Whitton [email protected].

Licence

Ce document et git-remote-gcrypt sont distribués sous les mêmes conditions, GPL-3 (ou 2+) ; voir le fichier git-remote-gcrypt.

.. ce document génère une page de manuel avec rst2man .. vim: ft=rst tw=72 sts=4