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

[Junio C Hamano <gitster@pobox.com>]

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

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