================= git-remote-gcrypt

---

GNU Privacy Guard-verschlüsseltes git-Remote

:Handbuchabschnitt: 1

Beschreibung

git-remote-gcrypt ist ein git-Remote-Helfer, um aus und in mit GnuPG verschlüsselte Repositories zu pushen und zu pullen, unter Verwendung eines benutzerdefinierten Formats. Dieser Remote-Helfer behandelt URIs mit dem Präfix gcrypt::.

Unterstützte Backends sind local, rsync:// und sftp://, bei denen das Repository als Dateisatz gespeichert wird, oder alternativ jede <giturl>, bei der gcrypt die gleiche Darstellung in einem git-Repository speichert, überbrückt über einen beliebigen git-Transport. Bevorzugen Sie local oder rsync://, falls eines davon verwendet werden kann; siehe „Leistung“ weiter unten für eine Diskussion.

Es gibt auch ein experimentelles rclone://-Backend nur für Early Adopters (Sie wurden gewarnt).

Ziel ist die Bereitstellung von vertraulichem, authentifiziertem git-Speicher und Zusammenarbeit unter Verwendung typischer unsicherer Datei-Hosts oder -Dienste.

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

• Verwenden Sie den Paketmanager Ihrer GNU/Linux-Distribution – Debian, Ubuntu, Fedora, Arch und einige kleinere Distributionen sind bekanntermaßen mit Paketen versehen.

• Führen Sie das mitgelieferte Skript install.sh auf anderen Systemen aus.

Schnellstart ..........

Erstellen Sie ein verschlüsseltes Remote, indem Sie darauf pushen::

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

Konfiguration

Die folgenden git-config(1)-Variablen werden unterstützt:

remote.<name>.gcrypt-participants .. gcrypt.participants Leerzeichen-getrennte Liste von GPG-Schlüsselbezeichnern. Das Remote wird an diese Teilnehmer verschlüsselt und nur Signaturen von diesen werden akzeptiert. gpg -k listet alle öffentlichen Schlüssel auf, die Sie kennen.

Wenn diese Option nicht gesetzt ist, wird mit Ihrem Standardschlüssel verschlüsselt und
jede gültige Signatur akzeptiert. Dieses Verhalten kann auch explizit angefordert werden,
indem die Teilnehmer auf ``simple`` gesetzt werden.

Die Einstellung ``gcrypt-participants`` auf dem Remote hat Vorrang
vor der Repository-Variable ``gcrypt.participants``.

remote.<name>.gcrypt-publish-participants .. gcrypt.publish-participants Standardmäßig werden die GPG-Schlüssel-IDs der Teilnehmer dadurch verschleiert, dass mit gpg -R verschlüsselt wird. Wenn diese Option auf true gesetzt wird, wird diese Sicherheitsmaßnahme deaktiviert.

Das Problem mit ``gpg -R`` ist, dass gpg zum Entschlüsseln jeden verfügbaren
geheimen Schlüssel nacheinander ausprobiert, bis ein brauchbarer gefunden wird.
Dies kann zu unnötigen Passphrasen-Abfragen führen.

gcrypt.gpg-args Der Inhalt dieser Einstellung wird als Argumente an gpg übergeben. Z.B. --use-agent.

remote.<name>.gcrypt-signingkey .. user.signingkey (Letzteres aus der regulären git-Konfiguration) Der Schlüssel, der zum Signieren verwendet werden soll. Sie sollten user.signingkey setzen, wenn Ihr Standardsignaturschlüssel nicht Teil der Teilnehmerliste ist. Sie können die pro-Remote-Version verwenden, um verschiedene Remotes mit unterschiedlichen Schlüsseln zu signieren.

remote.<name>.gcrypt-rsync-put-flags .. gcrypt.rsync-put-flags Flags, die beim Hochladen zu einem Remote mit dem rsync://-Backend an rsync übergeben werden. Wenn die Flags für ein bestimmtes Remote gesetzt sind, werden die globalen Flags, falls ebenfalls gesetzt, für dieses Remote nicht angewendet.

remote.<name>.gcrypt-require-explicit-force-push .. gcrypt.require-explicit-force-push Ein seit langem bestehender Fehler ist, dass jeder git-Push effektiv ein --force hat.

Wenn dieses Flag auf ``true`` gesetzt ist, wird git-remote-gcrypt sich weigern zu pushen,
es sei denn, ``--force`` wird übergeben oder die Refspecs sind mit ``+`` präfixiert.

Es gibt eine mögliche Lösung hier: https://bugs.debian.org/877464#32

Umgebungsvariablen

GCRYPT_FULL_REPACK Wenn gesetzt (auf einen anderen Wert als die leere Zeichenkette), erzwingt diese Umgebungsvariable ein vollständiges Neuverpacken beim Pushen.

Beispiele

So richten Sie ein Remote für zwei Teilnehmer ein::

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

So verwenden Sie ein git-Backend::

# beachten Sie, dass das Ziel-git-Repository bereits existieren muss und
# sein `next`-Branch wird überschrieben!
git remote add gitcrypt gcrypt::[email protected]:repo#next
git push gitcrypt master

Das URL-Fragment (hier #next) gibt an, welcher Backend-Branch verwendet wird.

Hinweise

Zusammenarbeit Die Verschlüsselung des Manifests wird bei jedem Push aktualisiert, um der Teilnehmerkonfiguration zu entsprechen. Jeder Push-Benutzer muss die öffentlichen Schlüssel aller Mitarbeiter und die korrekte Teilnehmerkonfiguration haben.

Abhängigkeiten rsync, curl und rclone für die Remotes rsync:, sftp: bzw. rclone:. Das Hauptprogramm benötigt eine POSIX-kompatible Shell, die local unterstützt.

GNU Privacy Guard Sowohl GPG 1.4 als auch 2 werden unterstützt. Sie benötigen einen persönlichen GPG-Schlüssel. GPG- Konfiguration gilt für Algorithmenauswahl für öffentliche Schlüsselverschlüsselung, symmetrische Verschlüsselung und Signierung. Siehe man gpg für weitere Informationen.

Remote-ID Die Remote-ID ist nicht geheim; sie stellt nur sicher, dass zwei Repositories, die vom selben Benutzer signiert wurden, unterschieden werden können. Sie sehen eine Warnung, wenn sich die Remote-ID ändert, was nur passieren sollte, wenn das Remote neu erstellt wurde.

Leistung Die Verwendung einer beliebigen <giturl> oder eines sftp://-URI erfordert das Hochladen der gesamten Repository-Historie bei jedem Push. Dies bedeutet, dass die Push-Vorgänge Ihres Repositorys im Laufe der Zeit langsamer werden, da Ihre git-Historie länger wird, und es kann leicht zu dem Punkt kommen, dass die weitere Nutzung von git-remote-gcrypt unpraktisch wird.

Daher sollten Sie diese Backends nur verwenden, wenn Sie wissen, dass Ihr
Repository niemals sehr groß wird, nicht nur, dass es jetzt nicht groß ist.
Das bedeutet, dass diese Backends für die meisten Repositories ungeeignet sind
und wahrscheinlich nur für ungewöhnliche Fälle geeignet sind, wie z.B. kleine
Anmeldeinformationsspeicher. Auch dann verwenden Sie `rsync://`, wenn möglich.
Beachten Sie jedoch, dass `rsync://` nicht mit einem Repository-Hosting-Dienst
wie Gitolite, GitHub oder GitLab funktioniert.

rsync-URIs Das URI-Format für das rsync-Backend ist rsync://user@host/pfad, was dem rsync-Standort user@host:/pfad entspricht, auf das über ssh zugegriffen wird. Beachten Sie, dass der Pfad absolut ist, nicht relativ zum Home-Verzeichnis. Ein früheres nicht standardmäßiges URI-Format wird ebenfalls unterstützt: rsync://user@host:Pfad, was dem rsync-Standort user@host:Pfad entspricht

rclone-Backend Zusätzlich zum Hinzufügen des rclone-Backends als Remote mit einem URI wie gcrypt::rclone://remote:subdir, müssen Sie das Remote auch zur rclone- Konfiguration hinzufügen. Dies erfolgt normalerweise durch Ausführen von rclone config. Siehe rclone(1).