Hi Lars & Konst, On Mon, 7 Aug 2017, Konstantin Khomoutov wrote: > On Sun, Aug 06, 2017 at 01:16:46PM +0200, Lars Schneider wrote: > > [...] > > > * It is now possible to switch between Secure Channel and OpenSSL for > > > Git's HTTPS transport by setting the http.sslBackend config > > > variable to "openssl" or "schannel"; This is now also the method > > > used by the installer (rather than copying libcurl-4.dll files > > > around). > > > > Does anyone have a pros/cons list for this option? There is no exhaustive list of pros/cons as of time of writing. Off the top of my head: OpenSSL pros: - well-tested - been the only option for Git for Windows in almost a decade OpenSSL cons: - does not integrate with the Windows Certificate Store Secure Channel pros: - well-tested - is an integral part of the Windows Operating System - supports the Windows Certificate Store Secure Channel cons: - has not been used by many Git for Windows users yet (so may have some surprising issues?) - does not support OpenSSL's way of adding custom certificates via ca-bundle.crt The big deal with the Windows Certificate Store? It can be administered enterprise-wide via regular Windows administration tools. That makes a huge difference when working with an internal server that has a custom SSL certificate. Please note that I, personally, have used Git for Windows almost exclusively via Secure Channel since late January this year. I have not had *any* trouble. But then, I do not use servers with custom SSL certificates at the moment. > > AFAIK OpenSSL is still the default in the GfW installer and I wonder > > why. Only one reason: the law of least surprise. Some users went to certain lengths when working with custom SSL certificates, building elaborate upgrade scenarios that modify the ca-bundle.crt file (and of course none of those efforts try to help any other user having the same problem). > > My gut feeling would be to go with the SSL implementation shipped with > > the OS. However, I don't have enough knowledge of either > > implementation to make an assessment. The reason I worked on cURL to allow choosing the SSL backend at runtime rather than build time is so that you can test this easier. Personally, I think that Secure Channel is the better option, for the same reason you mentioned: it is integrated with Windows. So if you configure proxies via regular Windows settings, Secure Channel will definitely handle it as expected. If you trust individual custom certificates via regular Windows mechanisms, Secure Channel will pick that up (IIUC). Therefore I would expect Secure Channel to provide a far superior user experience to OpenSSL. As a consequence, my plan is to switch the default from OpenSSL to Secure Channel when I feel that enough users have tested that backend and are as satisfied with it as I am. This will of course *not* affect users who upgrade, as the Git for Windows installer remembers previous settings and reapplies them on upgrades. > One fact which immediately comes to mind is that both frameworks use > different sets of certificates (schannel uses the system's one, and > OpenSSL uses what gets shipped with it). Another fact is that they > might have different sets or protocols implemented and/or enabled by > default. Hence switching schannel on for people who used OpenSSL might > break things for them. Indeed. OTOH Secure Channel should be a safe default. Ciao, Dscho
