build curl with winssl instead of openssl #823
Conversation
The native way on windows is to use the windows certificate store. The main reason here is for corporate networks with active directory it's easy to ship a company root ca. Meaning this root ca is not in the default openssl ca-bundle. We disused some aspects of it already here: git-for-windows/git#301 Also I tested a few things with a curl with winssl, which worked flaw less for me. **Pro** * it's native * it's more like how you expect that it works * easier for company's * (no impact on existing users since not a large number of users use this) _not so sure about that_ **con** * it's a regression * it breaks the ca-bundle * already tried with [msygit]( https://groups.google.com/forum/#!topic/msysgit/VqWArHFoeYU ) and reversed My personal standpoint is here to accept the regression since the behavior change is only notable for power users (major git hosting will work regardless github, bitbucket). The disclaimer here is that I use it in a corporate environment, where we have our own root ca.
|
I will stay on openssl version. Feel free to build your custom package for yourself |
|
Works also for me. Do you mind to extend a bit on why you stay on openssl? |
|
We prefer FOSS to proprietary software. |
|
Personally, I would not oppose patches to make curl lookup both cert stores, with perhaps an env var to say which to lookup first. |
|
Yep, I agree, if it is a solution that looks up both (maybe make the order configurable), it is much superior to the current situation. As to preferring FOSS to proprietary software: the Windows Certificate Store is part of the Operating System. So the argument does not apply (otherwise we should avoid using the Win32 API, too, and that would of course be stupid). |
|
@dscho: If you prefer, rephrase what I said as: "I prefer source code I can inspect and modify to binary code I cannot.", so when there's an option to use parts of the Operating System versus another library, my bias is towards the other library (all other things being equal). |
|
Instead of looking up both stores, I would prefer having a separate program that helps you import certificates from the Windows store to MSYS2. Multiple MSYS2 programs use SSL, and if we just patch curl then its behavior would be inconsistent with the other programs, right? |
|
@DavidEGrayson we are talking about MINGW packages, i.e. software that does not use But in principle I agree with trying to fix the most central point of convergence. Thinking about it, that point is probably OpenSSL, right? |
|
A patch to OpenSSL would sound good. Perhaps some of the info here can be of use? http://stackoverflow.com/questions/10095676/openssl-reasonable-default-for-trusted-ca-certificates |
|
@mingwandroid looks like a neat solution without winssl 👍 |
|
So we need someone to step up and do the work. I've got very little time unfortunately :-( |
|
Patching OpenSSL this way will also be a big help to beginners because they won't need to install MSYS2's ca-certificates packages. |
|
@mingwandroid are you referring to the solution in this comment? http://stackoverflow.com/a/19612161 |
The native way on windows is to use the windows certificate store. The main reason here is for corporate networks with active directory it's easy to ship a company root ca. Meaning this root ca is not in the default openssl ca-bundle.
We disused some aspects of it already here: git-for-windows/git#301
Also I tested a few things with a curl with winssl, which worked flaw less for me.
Pro
con
My personal standpoint is here to accept the regression since the behavior change is only notable for power users (major git hosting will work regardless github, bitbucket). The disclaimer here is that I use it in a corporate environment, where we have our own root ca.