Re: [PATCH] documentation: add git transport security notice

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2013, 16:24 UTC
Message-ID: <7vppvbbhoi.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1372069414-12601-1-git-send-email-frase@frase.id.au>

Fraser Tweedale <frase@frase.id.au> writes:

Show 20 quoted lines

> The fact that the git transport has no end-to-end security is easily
> overlooked.  Add a brief security notice to the "GIT URLS" section
> of the documentation stating that the git transport should be used
> with caution on unsecured networks.
>
> Signed-off-by: Fraser Tweedale <frase@frase.id.au>
> ---
>  Documentation/urls.txt | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/urls.txt b/Documentation/urls.txt
> index 3ca122f..c218af5 100644
> --- a/Documentation/urls.txt
> +++ b/Documentation/urls.txt
> @@ -11,6 +11,9 @@ and ftps can be used for fetching and rsync can be used for fetching
>  and pushing, but these are inefficient and deprecated; do not use
>  them).
>  
> +The git protocol provides no end-to-end security and should be used
> +with caution on unsecured networks.

Is this necessary?

I thought we already say the git protocol does not even authenticate elsewhere in the document, and if not, I think it is a sensible thing to say here. And once it is done, I doubt it is necessary to bring up a narrower concept such as "end-to-end security" which requires a lot more than authentication.

The only thing git protocol ensures is that the receiving end validates that what is fetched from an unknown server, and what is pushed by an unknown pusher, is internally consistent.

If you allowed a push over the git protocol by enabling the receive-pack service in "git daemon" (not recommended), you may allow anonymous users to delete branches and to do other funky things unless you protect your repository with pre-receive hook, but that won't corrupt the repository (of course, deleting all the refs may make the repository an empty but not corrupt one, which is just as unusable as a corrupt one, so there may not be a huge practical difference). If you fetched from an unauthenticated server, possibly with MITM, over the git protocol, you may end up getting something you did not ask for, but the resulting history in your repository would still be internally consistent (the commits may be malicious ones, of course, but that is what signed tags are there to protect you against).