Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72758
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.169 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 08:12:40 -0500
Message-ID: <CAH8Mpn=zbsycXdmcqqKhpKtQmojDKKewhNrY+p82KWdzeNvuBQ@mail.gmail.com>
To: Chris Wright <daverandom@php.net>
Cc: Pierre Joye <pierre.php@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1132e4cc4591b804f2fe7e5f
Subject: Re: [PHP-DEV] Windows Peer Verification
From: rdlowrey@gmail.com (Daniel Lowrey)

--001a1132e4cc4591b804f2fe7e5f
Content-Type: text/plain; charset=ISO-8859-1

>
> > 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.

--001a1132e4cc4591b804f2fe7e5f--