git-remote-pqcrypt

DIES IST EIN EXPERIMENTELLES PROJEKT, es gab noch kein formelles Sicherheitsaudit. Verlassen Sie sich NICHT darauf für irgendwelche kritischen Repositorys.

git-remote-pqcrypt ist ein verschlüsselter Git-Remote-Helper ähnlich wie gcrypt. Es speichert Git-Packfiles und Repository-Metadaten verschlüsselt ab. Der Zugriff erfolgt mit Post-Quantum-XWing-Wrapping.

Aktuelle Crate-Version: 0.2.0.

Funktionsweise

1. git-remote-pqcrypt init erstellt einen Repository-Masterschlüssel.
2. Der Masterschlüssel wird für jeden Benutzer mit dessen öffentlichem Schlüssel verpackt.
3. Git-Packfiles und Manifest werden mit dem Masterschlüssel verschlüsselt.
4. Git verwendet pqcrypt über den git-remote-pqcrypt-Remote-Helper.
5. Der Masterschlüssel wird lokal vom Helper entschlüsselt und dann werden Packfiles in das lokale Repository entschlüsselt.

Beispieldateien des entfernten Speichers:

keys.json
manifest.enc
objects/
    pack-.....pack.enc

keys.json enthält Metadaten und verschlüsselte Masterschlüssel-Wrappings.

Installation

Schnelle Installation mit Cargo

Installieren Sie den Standard-Build aus Git:

cargo install --git https://github.com/Torm0r/git-remote-pqcrypt --locked

Dies installiert git-remote-pqcrypt in das Cargo-Binärverzeichnis, normalerweise ~/.cargo/bin.

Stellen Sie sicher, dass das Cargo-Binärverzeichnis in Ihrem PATH ist, und überprüfen Sie dann, dass es funktioniert:

git-remote-pqcrypt --help

Der Standard-Build enthält Unterstützung für lokales Dateisystem und Git-gestützten Speicher.

Um mit SFTP-Unterstützung auf Unix-ähnlichen Systemen zu installieren:

cargo install --git https://github.com/Torm0r/git-remote-pqcrypt --locked --features sftp

Die sftp-Funktion wird derzeit unter Windows nicht unterstützt.

Aus dem Quellcode bauen

Bauen Sie mit standardmäßiger Backend-Unterstützung:

cargo build --release

Dies enthält Unterstützung für lokales Dateisystem und Git-gestützten Speicher.

Um mit SFTP-Unterstützung auf Unix-ähnlichen Systemen zu bauen:

cargo build --release --features sftp

Installieren Sie die Binärdatei in Ihren PATH:

sudo cp target/release/git-remote-pqcrypt /usr/local/bin/

Der Binärname muss git-remote-pqcrypt bleiben, da Git Remote-Helper findet, indem es nach git-remote-[name] sucht.

Überprüfen Sie, dass es funktioniert:

git-remote-pqcrypt --help

Anforderungen

• Rust-Toolchain zum Bauen aus dem Quellcode
• git muss installiert sein
• Für Git-gestützten Speicher werden funktionierende Git-Anmeldeinformationen und eine konfigurierte Git-Identität benötigt
• Für SSH/SFTP-Zugriff muss eine vorhandene SSH-Authentifizierung konfiguriert sein
• SFTP-Unterstützung erfordert das Bauen mit --features sftp und ist derzeit nur auf Unix-ähnlichen Systemen verfügbar

Schnellstart

1. Gehen Sie zu einem vorhandenen Git-Repository oder erstellen Sie eines.

2. Initialisieren Sie den pqcrypt-Speicher.

Lokaler Pfad:

git-remote-pqcrypt init pqcrypt:///path/to/encrypted-store

SFTP erfordert das Bauen mit der sftp-Funktion und wird derzeit nur auf Unix-ähnlichen Systemen unterstützt:

git-remote-pqcrypt init pqcrypt::sftp://[email protected]/path/to/store

Git-gestützt:

git-remote-pqcrypt init pqcrypt::[email protected]:org/store.git

Falls kein privater Schlüssel existiert, wird einer unter ~/.config/pqcrypt/key erstellt und der öffentliche Schlüssel wird ausgegeben.

Sie werden nach einem optionalen Schlüsselkommentar gefragt, z. B. persönlich oder arbeits-laptop.

Nach der Initialisierung wird ein Git-Remote namens pqcrypt hinzugefügt:

git remote -v

Beispiel:

pqcrypt  pqcrypt::/path/to/encrypted-store (fetch)
pqcrypt  pqcrypt::/path/to/encrypted-store (push)

3. Pushen:

git push pqcrypt main

4. Klonen oder fetchen:

git clone pqcrypt::[email protected]:Torm0r/pqcrypt-test.git my-clone

5. Einen weiteren Benutzer hinzufügen.

Dieser muss ein Schlüsselpaar mit folgendem Befehl generieren:

git-remote-pqcrypt keygen

Er kann seinen öffentlichen Schlüssel mit folgendem Befehl erhalten:

git-remote-pqcrypt pubgen ~/.config/pqcrypt/key

Oder er kann den von keygen ausgegebenen öffentlichen Schlüssel kopieren.

Dann fügt ein vorhandener autorisierter Benutzer ihn zum Repository hinzu:

git-remote-pqcrypt add-user <base64-public-key>

Führen Sie dies für weitere Optionen aus:

git-remote-pqcrypt add-user -h

Standardmäßig sucht add-user nach einem lokalen Git-Remote, dessen URL mit pqcrypt beginnt, und fügt dort den öffentlichen Schlüssel hinzu.

Push-Verhalten

pqcrypt unterscheidet normale Pushes von Force-Pushes anhand der Git-Refspec.

Normale Pushes werden auf Fast-Forward überprüft und abgelehnt, wenn sie die entfernte Historie überschreiben würden.

Remote-Helper-Verhalten

Git ruft pqcrypt als Remote-Helper über die Binärdatei git-remote-pqcrypt auf.

Wenn es von Git aufgerufen wird, erwartet der Helper die von Git verwendete Remote-Helper-Argumentform, zum Beispiel:

git-remote-pqcrypt origin pqcrypt::/path/to/store

Direkte CLI-Unterbefehle wie init, add-user, keygen, pubgen und help werden als normale Benutzerbefehle behandelt, nicht als Remote-Helper-Aufrufe.

Der Binäreinstiegspunkt delegiert an die Laufzeitbibliothek, sodass die Anwendungslogik sowohl über die Crate-Bibliothek als auch über die installierte Binärdatei testbar ist.

Git-gestützter Speichercache

Für Git-gestützte Speicher-URLs verwaltet pqcrypt einen lokalen Cache im System-Cache-Verzeichnis, zum Beispiel:

~/.cache/pqcrypt/

pqcrypt ruft vor Operationen den verschlüsselten Zustand aus dem zugrunde liegenden Git-Repository ab und schiebt nach Aktualisierungen den verschlüsselten Zustand dorthin.

Wenn eine Cache-Beschädigung oder ein Cache-Verlust festgestellt wird, versucht pqcrypt, den Cache automatisch neu zu erstellen, indem es erneut aus dem zugrunde liegenden Git-Repository abruft.

URL-Formate

pqcrypt::, pqcrypt:// und pqcrypt: werden alle akzeptiert und intern auf pqcrypt:: normalisiert.

Diese sind gleichwertig:

git-remote-pqcrypt init pqcrypt:///path/to/store
git-remote-pqcrypt init pqcrypt::/path/to/store
git-remote-pqcrypt init pqcrypt:/path/to/store

Das Backend wird durch den Speicherpfad bestimmt:

Beispiele:

pqcrypt::/tmp/store
pqcrypt:///tmp/store
pqcrypt:/tmp/store
pqcrypt::[email protected]:org/store.git
pqcrypt::https://github.com/org/store.git
pqcrypt::sftp://[email protected]/path/to/store

Ermittlungslogik für den privaten Schlüssel

Während der Entschlüsselung sucht pqcrypt in dieser Reihenfolge nach einem privaten Schlüssel:

1. Umgebungsvariable PQCRYPT_KEY_PATH
2. git config pqcrypt.keypath
3. .pqcrypt/key im aktuellen Verzeichnis
4. Jede passende Schlüsseldatei in ~/.config/pqcrypt, wo alle getestet werden

Für Multi-Key-Setups, z. B. Arbeits- und private Schlüssel:

git config pqcrypt.keypath ~/.config/pqcrypt/work-key

Der Schlüssel muss einer sein, der während init verwendet oder über add-user hinzugefügt wurde.

Entwicklung

Führen Sie die vollständige Testsuite aus:

cargo test

Führen Sie mit aktiviertem SFTP auf Unix-ähnlichen Systemen aus:

cargo test --features sftp

Einige End-to-End-Tests, die von Unix-ähnlichem lokalen Pfadverhalten abhängen, werden unter Windows ignoriert.

CI-Builds

GitHub Actions baut das Projekt auf Linux, macOS und Windows. Workflow-Artefakte können Binärdateien aus CI-Läufen enthalten, aber dies sind keine offiziellen Veröffentlichungen.

Sicherheitsinformationen

• Repository-Inhalte werden mit XChaCha20Poly1305 verschlüsselt.
• Der Repository-Masterschlüssel wird für Benutzer mit HPKE unter Verwendung von XWing verpackt.
• Jeder autorisierte öffentliche Schlüssel erhält seine eigene verschlüsselte Kopie des Masterschlüssels.
• An Schlüsseln angehängte Kommentare werden als HPKE-assoziierte Daten authentifiziert. Das bedeutet, dass der Masterschlüssel für dieses Wrapping möglicherweise nicht mehr entschlüsselt werden kann, wenn Kommentarmetadaten beschädigt werden.
• Git-Refs und Packfile-Metadaten werden im verschlüsselten Manifest gespeichert.
• Private Schlüsseldateien werden auf Unix-ähnlichen Systemen mit Berechtigungen 0600 erstellt.

Einschränkungen

• Dieses Projekt ist experimentell und wurde keinem formellen Sicherheitsaudit unterzogen.
• Derzeit werden nur lokales Dateisystem, Git-gestützte und optionale SFTP-Speicher-Backends unterstützt.
• SFTP-Unterstützung befindet sich hinter dem optionalen sftp-Feature und wird derzeit nicht unter Windows unterstützt.
• SFTP-/Git-Backends fehlt robustes verteiltes Locking, sodass gleichzeitige Pushes zu Datenverlust führen können.
• Das Verhalten des Git-Remote-Helpers ist noch relativ minimal und unterstützt möglicherweise nicht jeden Git-Workflow oder CI/CD-Vorgang.
• Force-Pushes werden unterstützt, können aber, genau wie normale Git-Force-Pushes, die verschlüsselte Remote-Historie überschreiben.
• Die HPKE-Crate hängt von einer Git-Quelle ab, da XWing in veröffentlichten Crate-Veröffentlichungen noch nicht unterstützt wird. Dies wird geändert, sobald HPKE aktualisiert wird.
• Es gibt keine Möglichkeit, den Benutzerzugriff zu widerrufen oder zu entfernen. Da Benutzer den Masterschlüssel aus der Git-Historie wiederherstellen können, besteht die beste Vorgehensweise darin, das Repository mit einem neuen Masterschlüssel neu zu initialisieren und das Remote zu löschen.
• Das Speicherformat könnte sich in zukünftigen Versionen ändern.
• Git-gestützter Speicher erfordert funktionierende Git-Anmeldeinformationen und eine konfigurierte Git-Identität für Commits.
• Für Git-, SSH- oder SFTP-Authentifizierung verlässt sich pqcrypt auf vorhandene SSH-/Git-Anmeldeinformationen.
• ssh und git müssen installiert sein.