{"thread":{"id":"35577","subject":"git:// protocol over SSL/TLS","startedAt":"2013-12-27T12:59:00Z","lastAt":"2013-12-28T20:52:48Z","messageCount":21,"participants":["Sergey Sharybin","Andreas Schwab","Konstantin Khomoutov","Pyeron, Jason J CTR (US)","Matthieu Moy","Bernhard R. Link","Junio C Hamano","brian m. carlson","Jeff King","Ilari Liusvaara"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"232428","messageId":"CAErtv27qUMo9LsGAZtk5Zv9qnZRB_YAXhtskvrrNbWGqadQh7Q@mail.gmail.com","threadId":"35577","inReplyTo":null,"subject":"git:// protocol over SSL/TLS","fromName":"Sergey Sharybin","fromEmail":"sergey.vfx@gmail.com","sentAt":"2013-12-27T12:59:00Z","receivedAt":"2013-12-27T12:59:00Z","isPatch":false,"sender":{"key":"sergey.vfx@gmail.com","avatar":"https://gravatar.com/avatar/26027c72ccaf17049ce0f691381f780c049736d0ed89bd45bd812dec74b78bb8?d=mp&s=160"},"body":"Hello everyone!\n\nQuick question is, is it possible to use git:// protocol over\nSSL/TLS/other secure transport?\n\nOr the recommended way to do secure anonymous checkout is to simply\nuse https:// ?\n\nThanks in advance!\n\n-- \nWith best regards, Sergey Sharybin\n"},{"id":"232429","messageId":"87r48y4e28.fsf@igel.home","threadId":"35577","inReplyTo":"CAErtv27qUMo9LsGAZtk5Zv9qnZRB_YAXhtskvrrNbWGqadQh7Q@mail.gmail.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2013-12-27T13:29:51Z","receivedAt":"2013-12-27T13:29:51Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Sergey Sharybin <sergey.vfx@gmail.com> writes:\n\n> Quick question is, is it possible to use git:// protocol over\n> SSL/TLS/other secure transport?\n\nThe git protocol itself performs no encryption or authentication by\ndesign.  This is the job of the transport protocol.\n\n> Or the recommended way to do secure anonymous checkout is to simply\n> use https:// ?\n\nYes.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"232431","messageId":"20131227173655.3f3109e7ba848c90b302e2f9@domain007.com","threadId":"35577","inReplyTo":"CAErtv27qUMo9LsGAZtk5Zv9qnZRB_YAXhtskvrrNbWGqadQh7Q@mail.gmail.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Konstantin Khomoutov","fromEmail":"flatworm@users.sourceforge.net","sentAt":"2013-12-27T13:36:55Z","receivedAt":"2013-12-27T13:36:55Z","isPatch":false,"sender":{"key":"flatworm@users.sourceforge.net","avatar":null},"body":"On Fri, 27 Dec 2013 18:59:00 +0600\nSergey Sharybin <sergey.vfx@gmail.com> wrote:\n\n> Quick question is, is it possible to use git:// protocol over\n> SSL/TLS/other secure transport?\n\nThe Git protocol does not implement it itself but you can channel it\nover a TLS tunnel (via stunnel for instance).  Unfortunately, this\nmeans a specialized software and setup on both ends so if the question\nwas about a general client using stock Git then the answer is no, it's\nimpossible.\n\n> Or the recommended way to do secure anonymous checkout is to simply\n> use https:// ?\n\nYes, but it will only be secure if you've managed to verify the\nserver's certificate and do trust its issuer (or a CA higher up the\ncert's trust chain) -- people tend to confuse \"encrypted\" with\n\"secure\" which is not at all the same thing.\n"},{"id":"232433","messageId":"CAErtv25JGxEs3ytAB019yajQooNs4k=bzukSE9kuHWAbir9-BQ@mail.gmail.com","threadId":"35577","inReplyTo":"20131227173655.3f3109e7ba848c90b302e2f9@domain007.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Sergey Sharybin","fromEmail":"sergey.vfx@gmail.com","sentAt":"2013-12-27T13:58:19Z","receivedAt":"2013-12-27T13:58:19Z","isPatch":false,"sender":{"key":"sergey.vfx@gmail.com","avatar":"https://gravatar.com/avatar/26027c72ccaf17049ce0f691381f780c049736d0ed89bd45bd812dec74b78bb8?d=mp&s=160"},"body":"Hi,\n\nOn Fri, Dec 27, 2013 at 7:36 PM, Konstantin Khomoutov\n<flatworm@users.sourceforge.net> wrote:\n>\n> The Git protocol does not implement it itself but you can channel it\n> over a TLS tunnel (via stunnel for instance).  Unfortunately, this\n> means a specialized software and setup on both ends so if the question\n> was about a general client using stock Git then the answer is no, it's\n> impossible.\n\nOk, got it.\n\n> Yes, but it will only be secure if you've managed to verify the\n> server's certificate and do trust its issuer (or a CA higher up the\n> cert's trust chain) -- people tend to confuse \"encrypted\" with\n> \"secure\" which is not at all the same thing.\n\nWe've got CA-signed certificate atm and it's about to be also\nEV-signed for our server (git.blender.org). So this is not gonna to be\nan issue. Cloning over https:// works fine, but we wanted to be sure\nall the bits are secure.\n\nSo guess we just need to recommend using https:// protocol instead of\ngit:// for our users?\n\n-- \nWith best regards, Sergey Sharybin\n"},{"id":"232435","messageId":"87mwjm4c3s.fsf@igel.home","threadId":"35577","inReplyTo":"CAErtv25JGxEs3ytAB019yajQooNs4k=bzukSE9kuHWAbir9-BQ@mail.gmail.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2013-12-27T14:12:07Z","receivedAt":"2013-12-27T14:12:07Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Sergey Sharybin <sergey.vfx@gmail.com> writes:\n\n> So guess we just need to recommend using https:// protocol instead of\n> git:// for our users?\n\nGiven how easy it is to verify the integrity of a git repository out of\nband there isn't really much of added security by using TLS for\ntransport.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"232436","messageId":"20131227181406.aa6c3427b3e52c978205b8b2@domain007.com","threadId":"35577","inReplyTo":"CAErtv25JGxEs3ytAB019yajQooNs4k=bzukSE9kuHWAbir9-BQ@mail.gmail.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Konstantin Khomoutov","fromEmail":"flatworm@users.sourceforge.net","sentAt":"2013-12-27T14:14:06Z","receivedAt":"2013-12-27T14:14:06Z","isPatch":false,"sender":{"key":"flatworm@users.sourceforge.net","avatar":null},"body":"On Fri, 27 Dec 2013 19:58:19 +0600\nSergey Sharybin <sergey.vfx@gmail.com> wrote:\n\n[...]\n> > Yes, but it will only be secure if you've managed to verify the\n> > server's certificate and do trust its issuer (or a CA higher up the\n> > cert's trust chain) -- people tend to confuse \"encrypted\" with\n> > \"secure\" which is not at all the same thing.\n> \n> We've got CA-signed certificate atm and it's about to be also\n> EV-signed for our server (git.blender.org). So this is not gonna to be\n> an issue. Cloning over https:// works fine, but we wanted to be sure\n> all the bits are secure.\n\nThis setup sounds to be just the right thing.\n\n> So guess we just need to recommend using https:// protocol instead of\n> git:// for our users?\n\nI think yes.  HTTP[S] once was dumb and slow but now it should be\ncomparable in speed to git:// as essentially using this protocol (which\nbecame \"smart\" [1]) means spawning a git server process once per fetch/push\nsession and making the client and server Git processes communicate all by\nthemselves, so HTTP is there for request routing, authentication and\nsession setup while data transfer is carried out by Git processes\nthemselves [2].\n\n1. http://git-scm.com/blog/2010/03/04/smart-http.html\n2. https://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html\n"},{"id":"232438","messageId":"20131227181640.314629cc762cab446ae5352e@domain007.com","threadId":"35577","inReplyTo":"87mwjm4c3s.fsf@igel.home","subject":"Re: git:// protocol over SSL/TLS","fromName":"Konstantin Khomoutov","fromEmail":"flatworm@users.sourceforge.net","sentAt":"2013-12-27T14:16:40Z","receivedAt":"2013-12-27T14:16:40Z","isPatch":false,"sender":{"key":"flatworm@users.sourceforge.net","avatar":null},"body":"On Fri, 27 Dec 2013 15:12:07 +0100\nAndreas Schwab <schwab@linux-m68k.org> wrote:\n\n> > So guess we just need to recommend using https:// protocol instead\n> > of git:// for our users?\n> \n> Given how easy it is to verify the integrity of a git repository out\n> of band there isn't really much of added security by using TLS for\n> transport.\n\nIf the devs employ signed tags then yes but otherwise you'd have to\nhave some reference repository to compare with.  Sure they target for a\nmore no-brainer setup. ;-)\n"},{"id":"232439","messageId":"CAErtv26WEYXPpi2D=54NfxfYKBFMKhExHKkWL0EWP_ZCUPEiXA@mail.gmail.com","threadId":"35577","inReplyTo":"87mwjm4c3s.fsf@igel.home","subject":"Re: git:// protocol over SSL/TLS","fromName":"Sergey Sharybin","fromEmail":"sergey.vfx@gmail.com","sentAt":"2013-12-27T14:18:47Z","receivedAt":"2013-12-27T14:18:47Z","isPatch":false,"sender":{"key":"sergey.vfx@gmail.com","avatar":"https://gravatar.com/avatar/26027c72ccaf17049ce0f691381f780c049736d0ed89bd45bd812dec74b78bb8?d=mp&s=160"},"body":"Our sysadmns are mainly worried about possible MITM which might give\nusers completely wrong repo.\n\nFor sure users might simply compare hash of HEAD from https'ed site\nwith repo browser with what they've got in the checkout. But that's an\nextra step which we'd like to avoid without security harm :)\n\nOn Fri, Dec 27, 2013 at 8:12 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:\n> Sergey Sharybin <sergey.vfx@gmail.com> writes:\n>\n>> So guess we just need to recommend using https:// protocol instead of\n>> git:// for our users?\n>\n> Given how easy it is to verify the integrity of a git repository out of\n> band there isn't really much of added security by using TLS for\n> transport.\n>\n> Andreas.\n>\n> --\n> Andreas Schwab, schwab@linux-m68k.org\n> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n> \"And now for something completely different.\"\n\n\n\n-- \nWith best regards, Sergey Sharybin\n"},{"id":"232441","messageId":"vpqwqiqpe80.fsf@anie.imag.fr","threadId":"35577","inReplyTo":"87mwjm4c3s.fsf@igel.home","subject":"Re: git:// protocol over SSL/TLS","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-12-27T14:20:47Z","receivedAt":"2013-12-27T14:20:47Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Andreas Schwab <schwab@linux-m68k.org> writes:\n\n> Sergey Sharybin <sergey.vfx@gmail.com> writes:\n>\n>> So guess we just need to recommend using https:// protocol instead of\n>> git:// for our users?\n>\n> Given how easy it is to verify the integrity of a git repository out of\n> band there isn't really much of added security by using TLS for\n> transport.\n\nYou can verify integrity after the fact, but not guarantee\nconfidentiality ... so it again depends on the definition of \"security\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"232440","messageId":"871B6C10EBEFE342A772D1159D13208557790479@umechphj.easf.csd.disa.mil","threadId":"35577","inReplyTo":"87mwjm4c3s.fsf@igel.home","subject":"RE: git:// protocol over SSL/TLS","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2013-12-27T14:21:01Z","receivedAt":"2013-12-27T14:21:01Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"> -----Original Message-----\n> From: Andreas Schwab\n> Sent: Friday, December 27, 2013 9:12 AM\n> \n> Sergey Sharybin <sergey.vfx@gmail.com> writes:\n> \n> > So guess we just need to recommend using https:// protocol instead of\n> > git:// for our users?\n> \n> Given how easy it is to verify the integrity of a git repository out of\n> band there isn't really much of added security by using TLS for\n> transport.\n\nI have to say, using encryption (TLS, etc) is not just for assurance of the communicating parties, but also to prevent a compromise of confidentiality.\n\nJason Pyeron\n(please do not add me to the cc)\n"},{"id":"232442","messageId":"CAErtv25URyB3znN1CMd87374NUjaSFvg=cee_-c=s8bB2j052A@mail.gmail.com","threadId":"35577","inReplyTo":"vpqwqiqpe80.fsf@anie.imag.fr","subject":"Re: git:// protocol over SSL/TLS","fromName":"Sergey Sharybin","fromEmail":"sergey.vfx@gmail.com","sentAt":"2013-12-27T14:25:16Z","receivedAt":"2013-12-27T14:25:16Z","isPatch":false,"sender":{"key":"sergey.vfx@gmail.com","avatar":"https://gravatar.com/avatar/26027c72ccaf17049ce0f691381f780c049736d0ed89bd45bd812dec74b78bb8?d=mp&s=160"},"body":"Security in this case is about being sure everyone gets exactly the\nsame repository as stored on the server, without any modifications to\nthe sources cased by MITM.\n\nAs for \"smart\" http, this seems pretty much cool.However, we're\ncurrently using lighthttpd, so it might be an issue. We'll check on\nwhether \"smart\" http is used there, and if not guess it wouldn't be a\nbig deal to switch to apache.\n\nOn Fri, Dec 27, 2013 at 8:20 PM, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n> Andreas Schwab <schwab@linux-m68k.org> writes:\n>\n>> Sergey Sharybin <sergey.vfx@gmail.com> writes:\n>>\n>>> So guess we just need to recommend using https:// protocol instead of\n>>> git:// for our users?\n>>\n>> Given how easy it is to verify the integrity of a git repository out of\n>> band there isn't really much of added security by using TLS for\n>> transport.\n>\n> You can verify integrity after the fact, but not guarantee\n> confidentiality ... so it again depends on the definition of \"security\".\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n\n\n\n-- \nWith best regards, Sergey Sharybin\n"},{"id":"232443","messageId":"87ioua4ba0.fsf@igel.home","threadId":"35577","inReplyTo":"vpqwqiqpe80.fsf@anie.imag.fr","subject":"Re: git:// protocol over SSL/TLS","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2013-12-27T14:29:59Z","receivedAt":"2013-12-27T14:29:59Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> You can verify integrity after the fact, but not guarantee\n> confidentiality ... so it again depends on the definition of \"security\".\n\nSince the OP is talking about anonymous access there is no need for\nconfidentiality in this case.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"232444","messageId":"20131227183958.b8e55d7e3c8c38b46137ea9c@domain007.com","threadId":"35577","inReplyTo":"CAErtv25URyB3znN1CMd87374NUjaSFvg=cee_-c=s8bB2j052A@mail.gmail.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Konstantin Khomoutov","fromEmail":"flatworm@users.sourceforge.net","sentAt":"2013-12-27T14:39:58Z","receivedAt":"2013-12-27T14:39:58Z","isPatch":false,"sender":{"key":"flatworm@users.sourceforge.net","avatar":null},"body":"On Fri, 27 Dec 2013 20:25:16 +0600\nSergey Sharybin <sergey.vfx@gmail.com> wrote:\n\n> Security in this case is about being sure everyone gets exactly the\n> same repository as stored on the server, without any modifications to\n> the sources cased by MITM.\n> \n> As for \"smart\" http, this seems pretty much cool.However, we're\n> currently using lighthttpd, so it might be an issue. We'll check on\n> whether \"smart\" http is used there, and if not guess it wouldn't be a\n> big deal to switch to apache.\n\nThe web server software has nothing to do with HTTP[S] used by Git being\n\"smart\", I think, it just has to be set up properly.\n\nAs discussed in an earlier thread here, a good indication of the\ndumb version of the protocol being in use is no display of the\nfetching progress on the client while doing `git clone` because this\ninformation (like \"compressing objects ...\" etc) is sent by the\nserver-side Git process which is only there if HTTP[S] \"was smart\".\nOtherwise the client just GETs packs of objects, traverses them, GETs\nmore and so on, so batches of HTTP GET requests correlating to clone\nsessions in the web server logs should also be indicative of the\nproblem.\n"},{"id":"232445","messageId":"CAErtv25uWbsH15yohh+6Jun3eD51dZzvj7udoBf14_EwXzSUPg@mail.gmail.com","threadId":"35577","inReplyTo":"20131227183958.b8e55d7e3c8c38b46137ea9c@domain007.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Sergey Sharybin","fromEmail":"sergey.vfx@gmail.com","sentAt":"2013-12-27T14:47:54Z","receivedAt":"2013-12-27T14:47:54Z","isPatch":false,"sender":{"key":"sergey.vfx@gmail.com","avatar":"https://gravatar.com/avatar/26027c72ccaf17049ce0f691381f780c049736d0ed89bd45bd812dec74b78bb8?d=mp&s=160"},"body":">> As for \"smart\" http, this seems pretty much cool.However, we're\n>> currently using lighthttpd, so it might be an issue. We'll check on\n>> whether \"smart\" http is used there, and if not guess it wouldn't be a\n>> big deal to switch to apache.\n>\n> The web server software has nothing to do with HTTP[S] used by Git being\n> \"smart\", I think, it just has to be set up properly.\n\nMisunderstood git doc then which says \"it has to be Apache, currently\n- other CGI servers don't work, last I checked\".\n\n> As discussed in an earlier thread here, a good indication of the\n> dumb version of the protocol being in use is no display of the\n> fetching progress on the client while doing `git clone` because this\n> information (like \"compressing objects ...\" etc) is sent by the\n> server-side Git process which is only there if HTTP[S] \"was smart\".\n> Otherwise the client just GETs packs of objects, traverses them, GETs\n> more and so on, so batches of HTTP GET requests correlating to clone\n> sessions in the web server logs should also be indicative of the\n> problem.\n\nJust to verify, if i see messages like \"Receiving objects:   1%\n(7289/705777), 1.72 MiB | 340.00 KiB/s\" it means server is \"smart\" ?\n\n\n\n-- \nWith best regards, Sergey Sharybin\n"},{"id":"232446","messageId":"20131227185657.0dee9b2062fe6c632cd7d3a4@domain007.com","threadId":"35577","inReplyTo":"CAErtv25uWbsH15yohh+6Jun3eD51dZzvj7udoBf14_EwXzSUPg@mail.gmail.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Konstantin Khomoutov","fromEmail":"flatworm@users.sourceforge.net","sentAt":"2013-12-27T14:56:57Z","receivedAt":"2013-12-27T14:56:57Z","isPatch":false,"sender":{"key":"flatworm@users.sourceforge.net","avatar":null},"body":"On Fri, 27 Dec 2013 20:47:54 +0600\nSergey Sharybin <sergey.vfx@gmail.com> wrote:\n\n[...]\n> > As discussed in an earlier thread here, a good indication of the\n> > dumb version of the protocol being in use is no display of the\n> > fetching progress on the client while doing `git clone` because this\n> > information (like \"compressing objects ...\" etc) is sent by the\n> > server-side Git process which is only there if HTTP[S] \"was smart\".\n> > Otherwise the client just GETs packs of objects, traverses them,\n> > GETs more and so on, so batches of HTTP GET requests correlating to\n> > clone sessions in the web server logs should also be indicative of\n> > the problem.\n> \n> Just to verify, if i see messages like \"Receiving objects:   1%\n> (7289/705777), 1.72 MiB | 340.00 KiB/s\" it means server is \"smart\" ?\n\nI would say yes, because your Git knows the precise number of objects to\nreceive.  Unfortunately, I won't swear by this as this was a long time\nago I have seen cloning using the dumb protocol.\n\nBy the way, here [1] is that discussion.\n\n1. http://thread.gmane.org/gmane.comp.version-control.git/238933/focus=238946\n"},{"id":"232447","messageId":"20131227162606.GA6973@client.brlink.eu","threadId":"35577","inReplyTo":"CAErtv25URyB3znN1CMd87374NUjaSFvg=cee_-c=s8bB2j052A@mail.gmail.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Bernhard R. Link","fromEmail":"brl+git@mail.brlink.eu","sentAt":"2013-12-27T16:26:07Z","receivedAt":"2013-12-27T16:26:07Z","isPatch":false,"sender":{"key":"brl+git@mail.brlink.eu","avatar":null},"body":"* Sergey Sharybin <sergey.vfx@gmail.com> [131227 15:25]:\n> Security in this case is about being sure everyone gets exactly the\n> same repository as stored on the server, without any modifications to\n> the sources cased by MITM.\n\nNote that ssl (and thus https) only helps here against a resource-less\nman-in-the-middle. Getting catch-all CA-signed certificates is said to\nno longer available to everyone as easily as it was some years ago, but\nunless you allow only one private CA (and even there clients often fail)\nyou still should assume everyone resourceful enough to still be able to\ndo MITM.\n\n        Bernhard R. Link\n"},{"id":"232457","messageId":"7viouaj5p0.fsf@alter.siamese.dyndns.org","threadId":"35577","inReplyTo":"20131227173655.3f3109e7ba848c90b302e2f9@domain007.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-27T22:21:31Z","receivedAt":"2013-12-27T22:21:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:\n\n> On Fri, 27 Dec 2013 18:59:00 +0600\n> Sergey Sharybin <sergey.vfx@gmail.com> wrote:\n>\n>> Quick question is, is it possible to use git:// protocol over\n>> SSL/TLS/other secure transport?\n>\n> The Git protocol does not implement it itself but you can channel it\n> over a TLS tunnel (via stunnel for instance).  Unfortunately, this\n> means a specialized software and setup on both ends so if the question\n> was about a general client using stock Git then the answer is no, it's\n> impossible.\n\nHmph, I somehow had an impression that you wouldn't need anything\nmore complex than a simple helper that uses git-remote-ext on the\nclient side. On the remote end, you'd need to have something that\nterminates the incoming SSL/TLS and plugs it to your git daemon.\n\n>\n>> Or the recommended way to do secure anonymous checkout is to simply\n>> use https:// ?\n>\n> Yes, but it will only be secure if you've managed to verify the\n> server's certificate and do trust its issuer (or a CA higher up the\n> cert's trust chain) -- people tend to confuse \"encrypted\" with\n> \"secure\" which is not at all the same thing.\n"},{"id":"232462","messageId":"20131228001100.GF451338@vauxhall.crustytoothpaste.net","threadId":"35577","inReplyTo":"CAErtv25URyB3znN1CMd87374NUjaSFvg=cee_-c=s8bB2j052A@mail.gmail.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2013-12-28T00:11:00Z","receivedAt":"2013-12-28T00:11:00Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Fri, Dec 27, 2013 at 08:25:16PM +0600, Sergey Sharybin wrote:\n> Security in this case is about being sure everyone gets exactly the\n> same repository as stored on the server, without any modifications to\n> the sources cased by MITM.\n\nBesides security, HTTPS is more likely to work across different\nfirewalls and proxies, since \"odd\" ports like 9418 are often blocked and\nHTTPS usually isn't subject to the weirdness of proxies (since they\ncan't inspect it or modify it).\n\n> As for \"smart\" http, this seems pretty much cool.However, we're\n> currently using lighthttpd, so it might be an issue. We'll check on\n> whether \"smart\" http is used there, and if not guess it wouldn't be a\n> big deal to switch to apache.\n\nYou can use Lighttpd if you like.  See\nDocumentation/git-http-backend.txt (or git http-backend --help).\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"232469","messageId":"20131228093751.GD21109@sigill.intra.peff.net","threadId":"35577","inReplyTo":"CAErtv25uWbsH15yohh+6Jun3eD51dZzvj7udoBf14_EwXzSUPg@mail.gmail.com","subject":"Re: git:// protocol over SSL/TLS","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-12-28T09:37:51Z","receivedAt":"2013-12-28T09:37:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 27, 2013 at 08:47:54PM +0600, Sergey Sharybin wrote:\n\n> > The web server software has nothing to do with HTTP[S] used by Git being\n> > \"smart\", I think, it just has to be set up properly.\n> \n> Misunderstood git doc then which says \"it has to be Apache, currently\n> - other CGI servers don't work, last I checked\".\n\nDo you happen to remember where you saw that claim? If the manual in\ngit's Documentation/ directory says that, I'd like to fix it.\n\nI added sample lighttpd config to \"git help http-backend\" a while back.\nI tested it at the time, but I do not currently run a lighttpd git\nserver at all.\n\n-Peff\n"},{"id":"232491","messageId":"20131228200007.GA13655@LK-Perkele-VII","threadId":"35577","inReplyTo":"7viouaj5p0.fsf@alter.siamese.dyndns.org","subject":"Re: git:// protocol over SSL/TLS","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2013-12-28T20:00:07Z","receivedAt":"2013-12-28T20:00:07Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Fri, Dec 27, 2013 at 02:21:31PM -0800, Junio C Hamano wrote:\n> Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:\n> >\n> > The Git protocol does not implement it itself but you can channel it\n> > over a TLS tunnel (via stunnel for instance).  Unfortunately, this\n> > means a specialized software and setup on both ends so if the question\n> > was about a general client using stock Git then the answer is no, it's\n> > impossible.\n> \n> Hmph, I somehow had an impression that you wouldn't need anything\n> more complex than a simple helper that uses git-remote-ext on the\n> client side. On the remote end, you'd need to have something that\n> terminates the incoming SSL/TLS and plugs it to your git daemon.\n\nIf you have some tool that can do cleartext I/O from stdin/stdout\nand establishes ciphertext connection itself, you can use it with\ngit-remote-ext. It was written for cases exactly like that.\n\nTo do git:// inside, use the %G pseudo-argument.\n\n-Ilari\n"},{"id":"232493","messageId":"CAErtv24VXqq3HenbygvUG8qhsMTxKfC8-U0Udrgobia0u4vGsw@mail.gmail.com","threadId":"35577","inReplyTo":"20131227162606.GA6973@client.brlink.eu","subject":"Re: git:// protocol over SSL/TLS","fromName":"Sergey Sharybin","fromEmail":"sergey.vfx@gmail.com","sentAt":"2013-12-28T20:52:48Z","receivedAt":"2013-12-28T20:52:48Z","isPatch":false,"sender":{"key":"sergey.vfx@gmail.com","avatar":"https://gravatar.com/avatar/26027c72ccaf17049ce0f691381f780c049736d0ed89bd45bd812dec74b78bb8?d=mp&s=160"},"body":"Yeah, i understand this. We can not protect self from every single\npossible attack..\n\nOn Fri, Dec 27, 2013 at 10:26 PM, Bernhard R. Link\n<brl+git@mail.brlink.eu> wrote:\n> * Sergey Sharybin <sergey.vfx@gmail.com> [131227 15:25]:\n>> Security in this case is about being sure everyone gets exactly the\n>> same repository as stored on the server, without any modifications to\n>> the sources cased by MITM.\n>\n> Note that ssl (and thus https) only helps here against a resource-less\n> man-in-the-middle. Getting catch-all CA-signed certificates is said to\n> no longer available to everyone as easily as it was some years ago, but\n> unless you allow only one private CA (and even there clients often fail)\n> you still should assume everyone resourceful enough to still be able to\n> do MITM.\n>\n>         Bernhard R. Link\n\n\n\n-- \nWith best regards, Sergey Sharybin\n"}]}