235ec24352
The "SECURITY" section of the gitnamespaces(7) man page described two ways for a client to steal data from a server that wasn't intended to be shared. Similar attacks can be performed by a server on a client, so adapt the section to cover both directions and add it to the git-fetch(1), git-pull(1), and git-push(1) man pages. Also add references to this section from the documentation of server configuration options that attempt to control data leakage but may not be fully effective. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
65 lines
2.4 KiB
Plaintext
65 lines
2.4 KiB
Plaintext
gitnamespaces(7)
|
|
================
|
|
|
|
NAME
|
|
----
|
|
gitnamespaces - Git namespaces
|
|
|
|
SYNOPSIS
|
|
--------
|
|
[verse]
|
|
GIT_NAMESPACE=<namespace> 'git upload-pack'
|
|
GIT_NAMESPACE=<namespace> 'git receive-pack'
|
|
|
|
|
|
DESCRIPTION
|
|
-----------
|
|
|
|
Git supports dividing the refs of a single repository into multiple
|
|
namespaces, each of which has its own branches, tags, and HEAD. Git can
|
|
expose each namespace as an independent repository to pull from and push
|
|
to, while sharing the object store, and exposing all the refs to
|
|
operations such as linkgit:git-gc[1].
|
|
|
|
Storing multiple repositories as namespaces of a single repository
|
|
avoids storing duplicate copies of the same objects, such as when
|
|
storing multiple branches of the same source. The alternates mechanism
|
|
provides similar support for avoiding duplicates, but alternates do not
|
|
prevent duplication between new objects added to the repositories
|
|
without ongoing maintenance, while namespaces do.
|
|
|
|
To specify a namespace, set the `GIT_NAMESPACE` environment variable to
|
|
the namespace. For each ref namespace, Git stores the corresponding
|
|
refs in a directory under `refs/namespaces/`. For example,
|
|
`GIT_NAMESPACE=foo` will store refs under `refs/namespaces/foo/`. You
|
|
can also specify namespaces via the `--namespace` option to
|
|
linkgit:git[1].
|
|
|
|
Note that namespaces which include a `/` will expand to a hierarchy of
|
|
namespaces; for example, `GIT_NAMESPACE=foo/bar` will store refs under
|
|
`refs/namespaces/foo/refs/namespaces/bar/`. This makes paths in
|
|
`GIT_NAMESPACE` behave hierarchically, so that cloning with
|
|
`GIT_NAMESPACE=foo/bar` produces the same result as cloning with
|
|
`GIT_NAMESPACE=foo` and cloning from that repo with `GIT_NAMESPACE=bar`. It
|
|
also avoids ambiguity with strange namespace paths such as `foo/refs/heads/`,
|
|
which could otherwise generate directory/file conflicts within the `refs`
|
|
directory.
|
|
|
|
linkgit:git-upload-pack[1] and linkgit:git-receive-pack[1] rewrite the
|
|
names of refs as specified by `GIT_NAMESPACE`. git-upload-pack and
|
|
git-receive-pack will ignore all references outside the specified
|
|
namespace.
|
|
|
|
The smart HTTP server, linkgit:git-http-backend[1], will pass
|
|
GIT_NAMESPACE through to the backend programs; see
|
|
linkgit:git-http-backend[1] for sample configuration to expose
|
|
repository namespaces as repositories.
|
|
|
|
For a simple local test, you can use linkgit:git-remote-ext[1]:
|
|
|
|
----------
|
|
git clone ext::'git --namespace=foo %s /tmp/prefixed.git'
|
|
----------
|
|
|
|
include::transfer-data-leaks.txt[]
|