Re: Windows Peer Verification

From: Date: Sat, 22 Feb 2014 13:12:40 +0000
Subject: Re: Windows Peer Verification
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
>
> > 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)

« previous php.internals (#72758) next »