On Fri, 27 Dec 2013 19:58:19 +0600 Sergey Sharybin <sergey.vfx@xxxxxxxxx> wrote: [...] > > Yes, but it will only be secure if you've managed to verify the > > server's certificate and do trust its issuer (or a CA higher up the > > cert's trust chain) -- people tend to confuse "encrypted" with > > "secure" which is not at all the same thing. > > We've got CA-signed certificate atm and it's about to be also > EV-signed for our server (git.blender.org). So this is not gonna to be > an issue. Cloning over https:// works fine, but we wanted to be sure > all the bits are secure. This setup sounds to be just the right thing. > So guess we just need to recommend using https:// protocol instead of > git:// for our users? I think yes. HTTP[S] once was dumb and slow but now it should be comparable in speed to git:// as essentially using this protocol (which became "smart" [1]) means spawning a git server process once per fetch/push session and making the client and server Git processes communicate all by themselves, so HTTP is there for request routing, authentication and session setup while data transfer is carried out by Git processes themselves [2]. 1. http://git-scm.com/blog/2010/03/04/smart-http.html 2. https://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html