Re: [PATCH] documentation: add git transport security notice
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 --- 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: -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] documentation: add git transport security notice
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: iv...@iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] documentation: add git transport security notice
Fredrik Gustafsson 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] documentation: add git transport security notice
Fraser Tweedale 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] documentation: add git transport security notice
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: iv...@iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] documentation: add git transport security notice
On Mon, Jun 24, 2013 at 09:24:29AM -0700, Junio C Hamano wrote: > Fraser Tweedale 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 > > --- > > 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] documentation: add git transport security notice
Fraser Tweedale 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 > --- > 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
