Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72759
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGAGxbZJkYRgt0t+5c4_tYY1K17fsK1VZmy4jiH72QgwZwfTDw@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>
Date: Sat, 22 Feb 2014 14:19:27 +0100
Message-ID: <CAEZPtU4KY-tQ4vEH4n8YN38DdFf6Z8c_2zPDSDYZxkznygZGfQ@mail.gmail.com>
To: Chris Wright <daverandom@php.net>
Cc: Daniel Lowrey <rdlowrey@gmail.com>, Ferenc Kovacs <tyra3l@gmail.com>, 
	=?UTF-8?Q?P=C3=A1draic_Brady?= <padraic.brady@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Windows Peer Verification
From: pierre.php@gmail.com (Pierre Joye)

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