{"thread":{"id":"34261","subject":"[PATCH] documentation: add git transport security notice","startedAt":"2013-06-24T10:23:34Z","lastAt":"2013-06-24T22:47:08Z","messageCount":7,"participants":["Fraser Tweedale","Junio C Hamano","Fredrik Gustafsson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"221782","messageId":"1372069414-12601-1-git-send-email-frase@frase.id.au","threadId":"34261","inReplyTo":null,"subject":"[PATCH] documentation: add git transport security notice","fromName":"Fraser Tweedale","fromEmail":"frase@frase.id.au","sentAt":"2013-06-24T10:23:34Z","receivedAt":"2013-06-24T10:23:34Z","isPatch":true,"sender":{"key":"frase@frase.id.au","avatar":"https://avatars.githubusercontent.com/u/2331938?v=4"},"body":"The fact that the git transport has no end-to-end security is easily\noverlooked. Add a brief security notice to the \"GIT URLS\" section\nof the documentation stating that the git transport should be used\nwith caution on unsecured networks.\n\nSigned-off-by: Fraser Tweedale \n---\n Documentation/urls.txt | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/Documentation/urls.txt b/Documentation/urls.txt\nindex 3ca122f..c218af5 100644\n--- a/Documentation/urls.txt\n+++ b/Documentation/urls.txt\n@@ -11,6 +11,9 @@ and ftps can be used for fetching and rsync can be used for fetching\n and pushing, but these are inefficient and deprecated; do not use\n them).\n \n+The git protocol provides no end-to-end security and should be used\n+with caution on unsecured networks.\n+\n The following syntaxes may be used with them:\n \n - ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/\n-- \n1.8.3.1\n"},{"id":"221826","messageId":"7vppvbbhoi.fsf@alter.siamese.dyndns.org","threadId":"34261","inReplyTo":"1372069414-12601-1-git-send-email-frase@frase.id.au","subject":"Re: [PATCH] documentation: add git transport security notice","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-24T16:24:29Z","receivedAt":"2013-06-24T16:24:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fraser Tweedale writes:\n\n> The fact that the git transport has no end-to-end security is easily\n> overlooked. Add a brief security notice to the \"GIT URLS\" section\n> of the documentation stating that the git transport should be used\n> with caution on unsecured networks.\n>\n> Signed-off-by: Fraser Tweedale \n> ---\n> Documentation/urls.txt | 3 +++\n> 1 file changed, 3 insertions(+)\n>\n> diff --git a/Documentation/urls.txt b/Documentation/urls.txt\n> index 3ca122f..c218af5 100644\n> --- a/Documentation/urls.txt\n> +++ b/Documentation/urls.txt\n> @@ -11,6 +11,9 @@ and ftps can be used for fetching and rsync can be used for fetching\n> and pushing, but these are inefficient and deprecated; do not use\n> them).\n> \n> +The git protocol provides no end-to-end security and should be used\n> +with caution on unsecured networks.\n\nIs this necessary?\n\nI thought we already say the git protocol does not even authenticate\nelsewhere in the document, and if not, I think it is a sensible\nthing to say here. And once it is done, I doubt it is necessary to\nbring up a narrower concept such as \"end-to-end security\" which\nrequires a lot more than authentication.\n\nThe only thing git protocol ensures is that the receiving end\nvalidates that what is fetched from an unknown server, and what is\npushed by an unknown pusher, is internally consistent.\n\nIf you allowed a push over the git protocol by enabling the\nreceive-pack service in \"git daemon\" (not recommended), you may\nallow anonymous users to delete branches and to do other funky\nthings unless you protect your repository with pre-receive hook, but\nthat won't corrupt the repository (of course, deleting all the refs\nmay make the repository an empty but not corrupt one, which is just\nas unusable as a corrupt one, so there may not be a huge practical\ndifference). If you fetched from an unauthenticated server,\npossibly with MITM, over the git protocol, you may end up getting\nsomething you did not ask for, but the resulting history in your\nrepository would still be internally consistent (the commits may be\nmalicious ones, of course, but that is what signed tags are there to\nprotect you against).\n"},{"id":"221891","messageId":"20130624215733.GU2457@bacardi.hollandpark.frase.id.au","threadId":"34261","inReplyTo":"7vppvbbhoi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] documentation: add git transport security notice","fromName":"Fraser Tweedale","fromEmail":"frase@frase.id.au","sentAt":"2013-06-24T21:57:35Z","receivedAt":"2013-06-24T21:57:35Z","isPatch":true,"sender":{"key":"frase@frase.id.au","avatar":"https://avatars.githubusercontent.com/u/2331938?v=4"},"body":"On Mon, Jun 24, 2013 at 09:24:29AM -0700, Junio C Hamano wrote:\n> Fraser Tweedale writes:\n> \n> > The fact that the git transport has no end-to-end security is easily\n> > overlooked. Add a brief security notice to the \"GIT URLS\" section\n> > of the documentation stating that the git transport should be used\n> > with caution on unsecured networks.\n> >\n> > Signed-off-by: Fraser Tweedale \n> > ---\n> > Documentation/urls.txt | 3 +++\n> > 1 file changed, 3 insertions(+)\n> >\n> > diff --git a/Documentation/urls.txt b/Documentation/urls.txt\n> > index 3ca122f..c218af5 100644\n> > --- a/Documentation/urls.txt\n> > +++ b/Documentation/urls.txt\n> > @@ -11,6 +11,9 @@ and ftps can be used for fetching and rsync can be used for fetching\n> > and pushing, but these are inefficient and deprecated; do not use\n> > them).\n> > \n> > +The git protocol provides no end-to-end security and should be used\n> > +with caution on unsecured networks.\n> \n> Is this necessary?\n> \n> I thought we already say the git protocol does not even authenticate\n> elsewhere in the document, and if not, I think it is a sensible\n> thing to say here. And once it is done, I doubt it is necessary to\n> bring up a narrower concept such as \"end-to-end security\" which\n> requires a lot more than authentication.\n> \nCertainly in this part of the documentation there is no mention of\n(lack of) authentication or security concerns. git-daemon(1) does\nmention the lack of authentication in the SERVICES/receive-pack\nsection.\n\nOnce you are aware that the git transport is insecure it seems\nobvious in hindsight, but even as a security-minded person I simply\noverlooked this until recently. A brief note in the GIT URLS\nsection (which is included in the man pages for a number of\nessential commands) would have brought this to my attention much\nsooner.\n\nJunio, do you prefer the following more generic wording? If so I\nwill re-roll the patch (also note s/protocol/transport/ which is\nmore appropriate, I think).\n\n The git transport is insecure and should be used with caution on\n unsecured networks.\n\n> The only thing git protocol ensures is that the receiving end\n> validates that what is fetched from an unknown server, and what is\n> pushed by an unknown pusher, is internally consistent.\n> \n> If you allowed a push over the git protocol by enabling the\n> receive-pack service in \"git daemon\" (not recommended), you may\n> allow anonymous users to delete branches and to do other funky\n> things unless you protect your repository with pre-receive hook, but\n> that won't corrupt the repository (of course, deleting all the refs\n> may make the repository an empty but not corrupt one, which is just\n> as unusable as a corrupt one, so there may not be a huge practical\n> difference). If you fetched from an unauthenticated server,\n> possibly with MITM, over the git protocol, you may end up getting\n> something you did not ask for, but the resulting history in your\n> repository would still be internally consistent (the commits may be\n> malicious ones, of course, but that is what signed tags are there to\n> protect you against).\n"},{"id":"221893","messageId":"20130624222703.GA32270@paksenarrion.iveqy.com","threadId":"34261","inReplyTo":"20130624215733.GU2457@bacardi.hollandpark.frase.id.au","subject":"Re: [PATCH] documentation: add git transport security notice","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-06-24T22:27:03Z","receivedAt":"2013-06-24T22:27:03Z","isPatch":true,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Tue, Jun 25, 2013 at 07:57:35AM +1000, Fraser Tweedale wrote:\n> The git transport is insecure and should be used with caution on\n> unsecured networks.\n\nI don't understand this. How is git:// insecure?\n\nIt's protocol with no authentication, because it's a protocol used for\npublic sharing.\n\nThe only point of encrypt git:// would be to verify that the recieved\ndata has not been altered along the way. However you can always trust\nthat the end result is an valid copy of the remote.\n\nTo me that means that it's as secure as a non-authentication protocoll\nneeds to be.\n\nHow would an \"evil network\" be able to do any harm to a git transport\nover git://?\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"221894","messageId":"7vy59z5ej9.fsf@alter.siamese.dyndns.org","threadId":"34261","inReplyTo":"20130624215733.GU2457@bacardi.hollandpark.frase.id.au","subject":"Re: [PATCH] documentation: add git transport security notice","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-24T22:28:58Z","receivedAt":"2013-06-24T22:28:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fraser Tweedale writes:\n\n> Junio, do you prefer the following more generic wording? If so I\n> will re-roll the patch (also note s/protocol/transport/ which is\n> more appropriate, I think).\n>\n> The git transport is insecure and should be used with caution on\n> unsecured networks.\n\nGeneric but I somehow find it overly vague (it is unclear what kind\nof \"insecure-ness\" it is talking about).\n\n Because the git transport does not do any authentication, it\n should be used with caution on unsecured networks.\n\nPerhaps?\n"},{"id":"221895","messageId":"7vtxkn5e8o.fsf@alter.siamese.dyndns.org","threadId":"34261","inReplyTo":"20130624222703.GA32270@paksenarrion.iveqy.com","subject":"Re: [PATCH] documentation: add git transport security notice","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-24T22:35:19Z","receivedAt":"2013-06-24T22:35:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Gustafsson writes:\n\n> On Tue, Jun 25, 2013 at 07:57:35AM +1000, Fraser Tweedale wrote:\n>> The git transport is insecure and should be used with caution on\n>> unsecured networks.\n>\n> I don't understand this. How is git:// insecure?\n>\n> It's protocol with no authentication, because it's a protocol used for\n> public sharing.\n>\n> The only point of encrypt git:// would be to verify that the recieved\n> data has not been altered along the way. However you can always trust\n> that the end result is an valid copy of the remote.\n>\n> To me that means that it's as secure as a non-authentication protocoll\n> needs to be.\n\nIf your DNS is poisoned, or your router is compromised to allow your\ntraffic diverted, you may be fetching from somewhere you did not\nintend to. As I explained in a separate message, that does not\nnecessarily result in your repository corrupting, but the result,\neven though it may be \"git fsck\" clean at the bit level, needs\nadditional validation measure, such as signed tags, to be safely\nused to base your further work on top.\n\n> How would an \"evil network\" be able to do any harm to a git transport\n> over git://?\n\nYes, strictly speaking, it may not be \"transport being insecure\",\nbut the effect on the aggregated whole is the same.\n"},{"id":"221896","messageId":"20130624224708.GB32270@paksenarrion.iveqy.com","threadId":"34261","inReplyTo":"7vtxkn5e8o.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] documentation: add git transport security notice","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-06-24T22:47:08Z","receivedAt":"2013-06-24T22:47:08Z","isPatch":true,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Mon, Jun 24, 2013 at 03:35:19PM -0700, Junio C Hamano wrote:\n> > I don't understand this. How is git:// insecure?\n> \n> If your DNS is poisoned, or your router is compromised to allow your\n> traffic diverted, you may be fetching from somewhere you did not\n> intend to. As I explained in a separate message, that does not\n> necessarily result in your repository corrupting, but the result,\n> even though it may be \"git fsck\" clean at the bit level, needs\n> additional validation measure, such as signed tags, to be safely\n> used to base your further work on top.\n\nThanks for the explanation. Of course you need to verify your latest\ncommit sha1 against a trustworthy source. That would be enough to\nprevent this scenario, yes?\n\nIf we add warnings for git:// should we also add warnings for\nhttp://? Or do we consider that common knowledge?\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"}]}