On 22 February 2014 13:19, Pierre Joye <[email protected]> wrote:
> hi Chris,
>
>
> On Sat, Feb 22, 2014 at 11:51 AM, Chris Wright <[email protected]> wrote:
>
>> I have not done any performance testing, I was hoping Daniel would be
>> able to do this as he has already done a lot of work in this general
>> area (high performance network applications written in PHP) and I
>> think he has a better idea of how to extract some meaningful numbers
>> than I do, as well as mature PHP applications that will be able to
>> expose this as the bottleneck, if it is one.
>
> Not that important, see below :)
>
>> This patch has been specifically designed to affect *only* streams,
>> and *not* to affect applications that are using custom certificate
>> validation environments, the code that verifies against the Windows
>> cert stores is only ever used if a cafile/capath is not specified, if
>> the paths to a traditional OpenSSL compatible certificate collection
>> are specified through any method (context option/ini file) then that
>> is used instead. Any potential usage of the openssl_* functions in
>> userland is also completely unaffected.
>
> I missed that part while reviewing the patch. So forget the previous
> reply about not willing to have it in 5.6, this is an excellent thing.
>
> Go ahead with 5.6 and master please :)
>
> NB: should not review patches on my cell ;)
>
>> The main motivation behind this work is to avoid a huge influx of
>> "this code used to work and now I get errors when I run it on
>> Windows!" questions/complaints when people upgrade to 5.6, which is
>> what I see looming at the moment. Anyone who has historically been
>> setting their environment up correctly will be completely unaffected,
>> they will never even enter this code path.
>
> I like to add a default location in php-dir/openssl/... to load the CA
> file.A script will be available to update it and to add it as a cron.
>
>>> 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. This is
>>> what we do in Curl for example.
>>
>> Just so I'm clear on what's being suggested here, are you talking
>> about a new "extension" that would provide a unified abstracted API
>> that could be build against different back-ends? I generally like this
>> idea but it is a huge task... just coming up with a sane userland API
>> that can be fully implemented using both back-ends is hard enough.
>
> There is an existing extension already, with a much nicer and
> userfriendlier API, https://github.com/bukka/php-crypto
>
>
>> I've learned from using PDO that this is not necessarily always as
>> good an idea as it seems on the face of it, because you end up with an
>> API that accommodates only the LCD features of all back ends, or is
>> inconsistent across back ends, or both.
>
> For SSL operation it is way easier than for databases. The operations
> are standard and can be easily abstracted. See Curl or other SSL
> specific libraries.
>
> Thanks for your work!
>
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
Great news :-)
I'm working with Daniel to get the last remaining issues ironed out
and get the tests working on Windows in a sensible way, hopefully will
be ready to merge in the next day or two.