[PATCH] documentation: add git transport security notice

[PATCH] documentation: add git transport security notice

[Fraser Tweedale]

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.
+
 The following syntaxes may be used with them:
 
 - ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/
-- 
1.8.3.1

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

[Junio C Hamano]

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

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

[Fraser Tweedale]

On Mon, Jun 24, 2013 at 09:24:29AM -0700, Junio C Hamano wrote:
> 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.
> 
Certainly in this part of the documentation there is no mention of
(lack of) authentication or security concerns.  git-daemon(1) does
mention the lack of authentication in the SERVICES/receive-pack
section.

Once you are aware that the git transport is insecure it seems
obvious in hindsight, but even as a security-minded person I simply
overlooked this until recently.  A brief note in the GIT URLS
section (which is included in the man pages for a number of
essential commands) would have brought this to my attention much
sooner.

Junio, do you prefer the following more generic wording?  If so I
will re-roll the patch (also note s/protocol/transport/ which is
more appropriate, I think).

 The git transport is insecure and should be used with caution on
 unsecured networks.

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

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

[Fredrik Gustafsson]

On Tue, Jun 25, 2013 at 07:57:35AM +1000, Fraser Tweedale wrote:
>  The git transport is insecure and should be used with caution on
>  unsecured networks.

I don't understand this. How is git:// insecure?

It's protocol with no authentication, because it's a protocol used for
public sharing.

The only point of encrypt git:// would be to verify that the recieved
data has not been altered along the way. However you can always trust
that the end result is an valid copy of the remote.

To me that means that it's as secure as a non-authentication protocoll
needs to be.

How would an "evil network" be able to do any harm to a git transport
over git://?

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

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

[Junio C Hamano]

Fredrik Gustafsson <iveqy@iveqy.com> writes:

> On Tue, Jun 25, 2013 at 07:57:35AM +1000, Fraser Tweedale wrote:
>>  The git transport is insecure and should be used with caution on
>>  unsecured networks.
>
> I don't understand this. How is git:// insecure?
>
> It's protocol with no authentication, because it's a protocol used for
> public sharing.
>
> The only point of encrypt git:// would be to verify that the recieved
> data has not been altered along the way. However you can always trust
> that the end result is an valid copy of the remote.
>
> To me that means that it's as secure as a non-authentication protocoll
> needs to be.

If your DNS is poisoned, or your router is compromised to allow your
traffic diverted, you may be fetching from somewhere you did not
intend to.  As I explained in a separate message, that does not
necessarily result in your repository corrupting, but the result,
even though it may be "git fsck" clean at the bit level, needs
additional validation measure, such as signed tags, to be safely
used to base your further work on top.

> How would an "evil network" be able to do any harm to a git transport
> over git://?

Yes, strictly speaking, it may not be "transport being insecure",
but the effect on the aggregated whole is the same.

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

[Fredrik Gustafsson]

On Mon, Jun 24, 2013 at 03:35:19PM -0700, Junio C Hamano wrote:
> > I don't understand this. How is git:// insecure?
> 
> If your DNS is poisoned, or your router is compromised to allow your
> traffic diverted, you may be fetching from somewhere you did not
> intend to.  As I explained in a separate message, that does not
> necessarily result in your repository corrupting, but the result,
> even though it may be "git fsck" clean at the bit level, needs
> additional validation measure, such as signed tags, to be safely
> used to base your further work on top.

Thanks for the explanation. Of course you need to verify your latest
commit sha1 against a trustworthy source. That would be enough to
prevent this scenario, yes?

If we add warnings for git:// should we also add warnings for
http://? Or do we consider that common knowledge?

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

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

[Junio C Hamano]

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

> Junio, do you prefer the following more generic wording?  If so I
> will re-roll the patch (also note s/protocol/transport/ which is
> more appropriate, I think).
>
>  The git transport is insecure and should be used with caution on
>  unsecured networks.

Generic but I somehow find it overly vague (it is unclear what kind
of "insecure-ness" it is talking about).

  Because the git transport does not do any authentication, it
  should be used with caution on unsecured networks.

Perhaps?

[PATCH] documentation: add git transport security notice

[Fraser Tweedale]

The fact that the git transport does not do any authentication is
easily overlooked.  For example, DNS poisoning may result in
fetching from somewhere that was not intended.

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..b58a647 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 transport does not do any authentication and should be used
+with caution on unsecured networks.
+
 The following syntaxes may be used with them:
 
 - ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/
-- 
1.8.3.1

[PATCH] documentation: add git transport security notice

[Fraser Tweedale]

The fact that the git transport does not do any authentication is
easily overlooked.  For example, DNS poisoning may result in
fetching from somewhere that was not intended.

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 60ba300..9c8f524 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 transport does not do any authentication and should be used
+with caution on unsecured networks.
+
 The following syntaxes may be used with them:
 
 - ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/
-- 
1.8.3.1

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

[Jonathan Nieder]

Hi,

Fraser Tweedale wrote:

> --- 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 transport does not do any authentication and should be used
> +with caution on unsecured networks.

How about the something like the following?  I'm starting to think it
would make more sense to add a SECURITY section to git-clone(1),
though.

-- >8 --
Subject: doc: clarify git:// transport security notice

The recently added warning about the git protocol's lack of
authentication does not make it clear that the protocol lacks both
client and server authentication.  The lack of non IP-based client
auth is obvious (when does user enter her credentials?), while the
lack of authentication of the server is less so, so emphasize it.

Put the warning in context by making an analogy to HTTP's security
properties as compared to HTTPS.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Thanks,
Jonathan

diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 9ccb246..bd0058f 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -11,8 +11,8 @@ 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 native transport (i.e. git:// URL) does no authentication and
-should be used with caution on unsecured networks.
+Like HTTP, the native protocol (used for git:// URLs) does no server
+authentication and should be used with caution on unsecured networks.
 
 The following syntaxes may be used with them: