================= 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).

Das rclone-Backend gilt als experimentell und ist nur für Early Adopters gedacht.
Sie wurden gewarnt.

Repository-Format .................

| EncSign(X): Signieren und Verschlüsseln für GPG-Schlüsselinhaber | Encrypt(K,X): Verschlüsseln mit symmetrischem Schlüsselalgorithmus | Hash(X): SHA-2/256 | | B: Branch-Liste | L: Liste des Hashs (Hi) und Schlüssels (Ki) für jede Packdatei | R: Remote-ID | | Schreiben des Repositorys: | | Speichere jede Packdatei P als Encrypt(Ki, P) → P' in Dateiname Hi | wobei Ki ein neuer Zufallsstring und Hash(P') → Hi | Speichere im Manifest | | Lesen des Repositorys: | | Manifest holen, mit GPG-Schlüsselbund entschlüsseln und verifizieren → | Warnen, wenn nicht mit zuvor gesehener Remote-ID übereinstimmt | für jedes in : | Datei vom Server holen → | Verifiziere, dass mit übereinstimmt | Entschlüssele mit → und öffne dann mit git

Manifest-Datei .............

Beispielmanifestdatei (mit Auslassungspunkten der Kürze halber)::

$ 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

Jeder Eintrag erstreckt sich bis zur neuen Zeile und entspricht einem der folgenden:

<sha-1> <gitref> Git-Objekt-ID und ihr Ref

pack :<hashtyp>:<hash> <key> Packdatei-Hash (Hi) und entsprechender symmetrischer Schlüssel (Ki).

keep :<hashtyp>:<hash> <generation> Packdatei-Hash und ihre Neupack-Generation

repo <id> Die Remote-ID

extn <name> ... Erweiterungsfeld, beibehalten aber ungenutzt.

Erkennen von gcrypt-Repos

Um zu erkennen, ob eine git-URL ein gcrypt-Repo ist, verwenden Sie: git-remote-gcrypt --check url Exit-Status ist 0, wenn das Repo existiert und entschlüsselt werden kann, 1, wenn das Repo gcrypt verwendet, aber nicht entschlüsselt werden konnte, und 100, wenn das Repo nicht mit gcrypt verschlüsselt ist (oder nicht darauf zugegriffen werden konnte).

Beachten Sie, dass dies den Repo-Inhalt in das lokale git-Repository holen muss, genau wie bei der Verwendung eines gcrypt-Repos.

Bekannte Probleme

Jeder git-Push hat effektiv --force. Stellen Sie sicher, dass Sie vor dem Pushen pullen.

git-remote-gcrypt kann sich entscheiden, das Remote ohne Vorwarnung neu zu packen, was bedeutet, dass Ihr Push plötzlich deutlich länger dauern kann als erwartet, da Ihre gesamte Historie erneut hochgeladen werden muss. Dieser Push könnte über eine schlechte Verbindung fehlschlagen.

git-remote-gcrypt könnte ein Repository als „nicht gefunden“ melden, obwohl das Repository tatsächlich existiert, aber git-remote-gcrypt Probleme mit Authentifizierung, Port oder Netzwerkkonnektivität hat.

Siehe auch

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

Danksagungen

Der ursprüngliche Autor von git-remote-gcrypt war der GitHub-Benutzer bluss.

Der faktische Betreuer in den Jahren 2013 und 2014 war Joey Hess.

Der derzeitige Betreuer seit 2016 ist Sean Whitton [email protected].

Lizenz

Dieses Dokument und git-remote-gcrypt sind unter identischen Bedingungen lizenziert, GPL-3 (oder 2+); siehe die Datei git-remote-gcrypt.

.. dieses Dokument generiert eine Manpage mit rst2man .. vim: ft=rst tw=72 sts=4