English ▾ Themen ▾ Neueste Version ▾ gitnamespaces zuletzt aktualisiert in 2.32.0

NAME

gitnamespaces - Git-Namensräume

SYNOPSIS

GIT_NAMESPACE=<namespace> git upload-pack
GIT_NAMESPACE=<namespace> git receive-pack

BESCHREIBUNG

Git unterstützt die Aufteilung der Referenzen eines einzelnen Repositorys in mehrere Namensräume, von denen jeder seine eigenen Branches, Tags und HEAD hat. Git kann jeden Namensraum als unabhängiges Repository zum Pullen und Pushen bereitstellen, während der Objekt-Store gemeinsam genutzt wird und alle Referenzen für Operationen wie git-gc[1] verfügbar sind.

Das Speichern mehrerer Repositories als Namensräume eines einzelnen Repositorys vermeidet das Speichern von doppelten Kopien derselben Objekte, wie z. B. beim Speichern mehrerer Branches desselben Quellcodes. Der "alternates"-Mechanismus bietet ähnliche Unterstützung zur Vermeidung von Duplikaten, aber "alternates" verhindern keine Duplizierung neuer Objekte, die den Repositories ohne laufende Wartung hinzugefügt werden, während Namensräume dies tun.

Um einen Namensraum anzugeben, setzen Sie die Umgebungsvariable GIT_NAMESPACE auf den Namensraum. Für jeden Ref-Namensraum speichert Git die entsprechenden Refs in einem Verzeichnis unter refs/namespaces/. Zum Beispiel speichert GIT_NAMESPACE=foo Refs unter refs/namespaces/foo/. Sie können Namensräume auch über die Option --namespace für git[1] angeben.

Beachten Sie, dass Namensräume, die ein / enthalten, zu einer Hierarchie von Namensräumen erweitert werden. Zum Beispiel speichert GIT_NAMESPACE=foo/bar Refs unter refs/namespaces/foo/refs/namespaces/bar/. Dies bewirkt, dass sich Pfade in GIT_NAMESPACE hierarchisch verhalten, sodass das Klonen mit GIT_NAMESPACE=foo/bar das gleiche Ergebnis liefert wie das Klonen mit GIT_NAMESPACE=foo und das Klonen aus diesem Repo mit GIT_NAMESPACE=bar. Es vermeidet auch Mehrdeutigkeiten mit seltsamen Namensraum-Pfaden wie foo/refs/heads/, die andernfalls Verzeichnis-/Dateikonflikte innerhalb des refs-Verzeichnisses erzeugen könnten.

git-upload-pack[1] und git-receive-pack[1] überschreiben die Namen der Refs, wie sie von GIT_NAMESPACE angegeben werden. git-upload-pack und git-receive-pack ignorieren alle Referenzen außerhalb des angegebenen Namensraums.

Der Smart-HTTP-Server, git-http-backend[1], übergibt GIT_NAMESPACE an die Backend-Programme. Siehe git-http-backend[1] für Beispielkonfigurationen, um Repository-Namensräume als Repositories bereitzustellen.

Für einen einfachen lokalen Test können Sie git-remote-ext[1] verwenden.

git clone ext::'git --namespace=foo %s /tmp/prefixed.git'

SICHERHEIT

Die Fetch- und Push-Protokolle sind nicht darauf ausgelegt, zu verhindern, dass eine Seite Daten von einem anderen Repository stiehlt, die nicht zum Teilen bestimmt waren. Wenn Sie private Daten haben, die Sie vor einem böswilligen Peer schützen müssen, ist Ihre beste Option, sie in einem anderen Repository zu speichern. Dies gilt sowohl für Clients als auch für Server. Insbesondere Namensräume auf einem Server sind für die Lesezugriffskontrolle nicht effektiv; Sie sollten einem Namensraum nur Lesezugriff gewähren, wenn Sie einem Client vertrauen würden, der Lesezugriff auf das gesamte Repository hat.

Die bekannten Angriffsvektoren sind wie folgt:

  1. Das Opfer sendet "have"-Zeilen, die die IDs von Objekten ankündigen, die es besitzt und die nicht explizit zum Teilen bestimmt sind, aber zur Optimierung der Übertragung verwendet werden können, wenn der Peer sie ebenfalls hat. Der Angreifer wählt ein Objekt-ID X zum Stehlen aus und sendet eine Ref auf X, muss aber nicht den Inhalt von X senden, da das Opfer es bereits hat. Nun glaubt das Opfer, dass der Angreifer X hat, und es sendet den Inhalt von X später zurück an den Angreifer. (Dieser Angriff ist für einen Client am einfachsten auf einen Server durchzuführen, indem eine Ref auf X in dem Namensraum erstellt wird, auf den der Client Zugriff hat, und diese dann geholt wird. Der wahrscheinlichste Weg für einen Server, dies auf einem Client durchzuführen, ist, X in einen öffentlichen Branch zu "mergen" und zu hoffen, dass der Benutzer zusätzliche Arbeit an diesem Branch leistet und ihn an den Server zurückpusht, ohne den Merge zu bemerken.)

  2. Wie in #1 wählt der Angreifer eine Objekt-ID X zum Stehlen aus. Das Opfer sendet ein Objekt Y, das der Angreifer bereits hat, und der Angreifer behauptet fälschlicherweise, X und nicht Y zu haben, so dass das Opfer Y als Delta gegen X sendet. Das Delta enthüllt dem Angreifer Regionen von X, die Y ähnlich sind.

GIT

Teil der git[1] Suite