Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72764
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <CAEZPtU4KY-tQ4vEH4n8YN38DdFf6Z8c_2zPDSDYZxkznygZGfQ@mail.gmail.com>
References: <CAH8MpnnmKt2byQU8DcWetnK6W7GB9HuF3srea-ECwQ4RRe1SWQ@mail.gmail.com>
	<CAGAGxbaZ5aCdSxsQrw05_xyxKEAhQY6uGaoAu06GkudKOtdqoQ@mail.gmail.com>
	<CAEZPtU5hn6TFaQdS1eKbgLzBH93e6A6Rvdqhc0Vnj0izxRRD+g@mail.gmail.com>
	<CAGAGxbZJkYRgt0t+5c4_tYY1K17fsK1VZmy4jiH72QgwZwfTDw@mail.gmail.com>
	<CAEZPtU4KY-tQ4vEH4n8YN38DdFf6Z8c_2zPDSDYZxkznygZGfQ@mail.gmail.com>
Date: Sat, 22 Feb 2014 22:59:30 +0000
Message-ID: <CAGAGxbYq7ZSXVOEN_u2ehAd4QQf+Jnty2BRt+M+oDQSm0c+H=Q@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Chris Wright <daverandom@php.net>, Daniel Lowrey <rdlowrey@gmail.com>, 
	Ferenc Kovacs <tyra3l@gmail.com>, =?ISO-8859-1?Q?P=E1draic_Brady?= <padraic.brady@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Windows Peer Verification
From: daverandom@php.net (Chris Wright)

On 22 February 2014 13:19, Pierre Joye <pierre.php@gmail.com> wrote:
> hi Chris,
>
>
> On Sat, Feb 22, 2014 at 11:51 AM, Chris Wright <daverandom@php.net> 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.