Re: Windows Peer Verification

> > > this patch and the effort you put in it. But I have to say that I am > > not in favor of doing that in 5.6.0 and not only for this area in any > > other major version. A more global approach will be more beneficial > > and may bring less confusion to our users. It will also reduce support > > requests from windows users as well, who are following the numerous > > documentation out there about working with openssl on windows, from > > various areas. > > I hear what you are saying and I don't disagree. This is only really > intended to prevent the breakages that the recent changes would cause > for Windows users. I can see how it could be considered a band-aid fix > and may be viewed as undesirable in this respect, but I don't view > this fix as preventing your proposed global approach, merely buying > some time to do it properly. > > I like this patch because it doesn't impact the rest of the stream context ecosystem. Basically the windows certifcate store only comes into play in the following scenario: - No "cafile" or "capath" specified in the stream context - No openssl.cafile or openssl.capath ini directive specified The interface presented to end-users is transparent and works exactly the same way externally regardless of OS. Pierre: if we can demonstrate minimal/no performance differential in windows while not changing the outward facing API would you still be uncomfortable with integrating this patch (or reasonable derivation) for 5.6? I'm just a bit concerned about an impending flood of "My SSL doesn't work in windows!" bug reports in 5.6 ... Obviously this is more of a near-term patch to avoid interruptions and breakage for windows users. The goal should definitely be creating a unified API without mixing and matching the various OS-specific functionality together in a convoluted #ifdef hell. > At the end, I would prefer to have full support of the Windows Crypto > APIs and OpenSSL using one single and unified APIs. The new crypto > APIs could be a good base for that. We can then provide two builds, > one for openssl and one for the Windows Crypto API support. Totally agree. I've been poking around at the pecl crypto API recently and it seems like a good place to start.