Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.0

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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