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.
Thread (53 messages)