I was playing with the most recent snap builds and, as expected, the
openssl delegation to OS maintained certificate stores does not work in
windows (like it does everywhere else). In sane distros we're able to take
advantage of the OS-managed cert stores without getting our hands dirty.
However, windows uses a different certificate format which first requires
conversion to .PEM for use with OpenSSL libs. It is possible to load
certs from the windows store at runtime and perform the conversion, however
I'm unfamiliar with the relevant APIs for interfacing with the windows cert
store and wouldn't feel comfortable implementing in the remaining pre-5.6
time-frame. Further, this wouldn't be a particularly good solution for web
environments where we'd be duplicating all the certificate conversion work
in each request (as needed) if we rely on the OS to keep certificates
current. We could generate the converted certs in PEM format once, but then
you basically lose the benefits of updates courtesy of the OS when you do
that.
The options for dealing with this (as I see them) are:
-
Disable peer-verification by default in windows builds. Personally, I
don't see this as a valid option as it's terrifically insecure. I believe
it's better to fail with a warning than allow users to believe they're
conducting safe transfers when they're 100% vulnerable to Man-in-the-Middle
attacks. -
Do nothing and document heavily. Peer verification failures will already
generate an informative error message. Beyond this, the steps required by a
windows user to make peer verification work by default are extremely simple:- Download this file: http://curl.haxx.se/ca/cacert.pem (or equivalent)
- openssl.cafile = C:/path/to/cacert.pem (in php.ini)
Also, we could easily generate a painfully explicit E_WARNING in windows
explaining exactly how to fix the problem in the absence of the requisite
configuration.
- Include the same PEM-formatted CA file curl distributes with windows PHP
binaries and pre-populate the relevant php.ini directive. I don't think
this would come with any licensing issues as the curl cacert file is
licensed under the same licenses as the Mozilla source file it draws from
(MPL 1.1, GPL v2.0 or LGPL 2.1). However, I'm not an expert in these
matters, so others would likely need to comment.
Obviously, we want to avoid a 5.6 release with confused/upset Windows users
whose https:// transfers no longer work as before. However, the simple fact
is that the code that worked previously shouldn't have worked as it was a
massive security problem.
I don't want people to feel like the original peer verification RFC was a
misrepresentation, so if necessary we can vote on exactly how to handle the
situation re: windows users in 5.6. Thoughts?
hi,
I was playing with the most recent snap builds and, as expected, the
openssl delegation to OS maintained certificate stores does not work in
windows (like it does everywhere else).
Please define everywhere else. Last time I checked OpenSsl does not
support WIndows CA store. One has to fetch the binary cert from the
store and parse it using Openssl.
In sane distros
Just because OpenSsl is not used does not mean it is insane, at some
point I could even think the contrary :)
However, windows uses a different certificate format which first requires
conversion to .PEM for use with OpenSSL libs.
Right, except with projects like curl, they provide SSL backend using
the native Windows SSL APIs. Sadly it cannot be used in parallel.
It is possible to load
certs from the windows store at runtime and perform the conversion, however
I'm unfamiliar with the relevant APIs for interfacing with the windows cert
store and wouldn't feel comfortable implementing in the remaining pre-5.6
time-frame.
It also has a performance cost. I am not sure it is worth it as
everything in php relies on OpenSsl right now.
- Disable peer-verification by default in windows builds.
I do not like this idea :) But we have discussed that already back
then. We will bundled the CURL cert file and we have to document where
to fetch it (no matter the OSes btw).
Do nothing and document heavily. Peer verification failures will already
generate an informative error message. Beyond this, the steps required by a
windows user to make peer verification work by default are extremely simple:
- Download this file: http://curl.haxx.se/ca/cacert.pem (or equivalent)
- openssl.cafile = C:/path/to/cacert.pem (in php.ini)
We have to do this step anyway. And again, it is not a Windows problem
but a general problem, the CA DB has to be updated regularly and from
there (or any trusted source)
Also, we could easily generate a painfully explicit
E_WARNINGin windows
explaining exactly how to fix the problem in the absence of the requisite
configuration.
We have to generate one if no valid DB can be found, no matter the OS.
Remember that it is possible to specify a CA file with Curl, we may
think about introducing this setting for php at large, thoughts?
- Include the same PEM-formatted CA file curl distributes with windows PHP
binaries and pre-populate the relevant php.ini directive. I don't think
this would come with any licensing issues as the curl cacert file is
licensed under the same licenses as the Mozilla source file it draws from
(MPL 1.1, GPL v2.0 or LGPL 2.1). However, I'm not an expert in these
matters, so others would likely need to comment.
There is no licensing issue here. No worry :)
Obviously, we want to avoid a 5.6 release with confused/upset Windows users
whose https:// transfers no longer work as before. However, the simple fact
is that the code that worked previously shouldn't have worked as it was a
massive security problem.
Again, please keep in mind that it is not a windows only problem. This
issue has to be addressed on all supported platforms.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Please define everywhere else. Last time I checked OpenSsl does not
support WIndows CA store. One has to fetch the binary cert from the
store and parse it using Openssl.
Sorry, I was unclear. It works out of the box in Mac and the *nix distros
where I tested. OpenSSL stopped shipping their own CA file long ago and
distros generally synthesize the location of certs with OpenSSL compile
time. The Windows cert store uses a different format that can be converted
to the PEM format OpenSSL requires, but for reasons mentioned in my
original mail this is not really an ideal solution.
In sane distros
Just because OpenSsl is not used does not mean it is insane, at some
point I could even think the contrary :)
Again, apologies for being unclear. By "sane" I simply meant that distros
keep their certs up-to-date and the environment variables available to
OpenSSL at compile time reflect the location where the OS stores these
certs. A distro handing out openssl binaries without these cert locations
would be what I classify as "not sane." I'm not trying to imply Windows
inferiority; only difference. The lack of clarity is my fault.
However, windows uses a different certificate format which first requires
conversion to .PEM for use with OpenSSL libs.
Right, except with projects like curl, they provide SSL backend using
the native Windows SSL APIs. Sadly it cannot be used in parallel.
Absolutely. And this is the point of my mail: how best to allow the most
secure and user-friendly experience for users implementing the native PHP
API which, for better or worse, relies on the open PEM format used by
openssl. For users who get their PHP as part of distro this largely is a
non-issue because it's handled by the OS. Again, I'm not claiming Windows
inferiority; only difference. With Mac/*nix we don't have to worry about it
because they're (currently) supporting OpenSSL-backed solutions. There's no
additional step required there.
Again, please keep in mind that it is not a windows only problem. This
issue has to be addressed on all supported platforms.
Once more, I will make sacrifices to the deity of Windows retribution for
the unintentional pejorative tone of my original mail :)
The only real question here is this:
***** Should we ship a CA file? *****
Personally, I say no. If people are going to programmatically use encrypted
stream transfers they need to at the very least understand the basics of
the CA system. We shouldn't subsidize insecurity, and it's trivially easy
to procure a CA file.
The only real question here is this:
***** Should we ship a CA file? *****
Personally, I say no. If people are going to programmatically use encrypted
stream transfers they need to at the very least understand the basics of the
CA system. We shouldn't subsidize insecurity, and it's trivially easy to
procure a CA file.
We should for the windows binaries and use a script to update it. This
script should be part of the src distros.
I have added the curl ca cert file option because many users requested
it. It is very handy to have the ability to get a uptodate certs file,
especially when the OS one is outdated and cannot be updated (yes, it
happens :).
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
The only real question here is this:
***** Should we ship a CA file? *****
Personally, I say no. If people are going to programmatically use
encrypted
stream transfers they need to at the very least understand the basics of
the
CA system. We shouldn't subsidize insecurity, and it's trivially easy to
procure a CA file.We should for the windows binaries and use a script to update it. This
script should be part of the src distros.I have added the curl ca cert file option because many users requested
it. It is very handy to have the ability to get a uptodate certs file,
especially when the OS one is outdated and cannot be updated (yes, it
happens :).
Hi Pierre,
What made you change your mind about this since the discussion in december?
http://grokbase.com/p/php/php-internals/13chgngwf2/php-dev-vote-tls-peer-verification
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Personally, I say no. If people are going to programmatically use encrypted
stream transfers they need to at the very least understand the basics of
the CA system. We shouldn't subsidize insecurity, and it's trivially easy
to procure a CA file.
That's a double standard. You're saying Windows users need to "at
the very least understand" while other users don't need to understand
it at all, because It Just Works.
And anyway I'm not in agreement that if people are going to use
outbound encryption -- if they are going to simply call a PHP function
-- they need to understand how to update their local CA bundle. I
would think that, the majority of the time, users are either [a]
loading a provided "PHP binding" (.PHP file) for a public API or [b]
copying-and-pasting boilerplate code from API documentation and, just
speaking realistically, you should not expect them to know what's
going on under the hood. You can have a relatively good understanding
of HTTP (without the S) and when your service says "now you must use
encryption" there shouldn't be a big learning curve on the user side.
-- S.
Hi,
On 3 February 2014 18:59, Sanford Whiteman
swhitemanlistens-software@cypressintegrated.com wrote:
Personally, I say no. If people are going to programmatically use encrypted
stream transfers they need to at the very least understand the basics of
the CA system. We shouldn't subsidize insecurity, and it's trivially easy
to procure a CA file.That's a double standard. You're saying Windows users need to "at
the very least understand" while other users don't need to understand
it at all, because It Just Works.And anyway I'm not in agreement that if people are going to use
outbound encryption -- if they are going to simply call a PHP function
-- they need to understand how to update their local CA bundle. I
would think that, the majority of the time, users are either [a]
loading a provided "PHP binding" (.PHP file) for a public API or [b]
copying-and-pasting boilerplate code from API documentation and, just
speaking realistically, you should not expect them to know what's
going on under the hood. You can have a relatively good understanding
of HTTP (without the S) and when your service says "now you must use
encryption" there shouldn't be a big learning curve on the user side.
I agree absolutely. For better or worse, we can't expect programmers
to become security experts just because we wish it. I've already noted
a problem with programmers not adopting a simple year-old
disable_compression SSL context option in the wild, and that's in a
population of open source code that has countless experienced
programmers. There may be a minimum bar, but I think people
overestimate how many programmers can jump over it. In that context, a
bit of smart subsidising harms nobody and helps many. One could argue
that setting CN_match on a SSL context is trivial, but then this is
something I saw less than 4 months ago:
"Verify host name for SSL requests – Requests is now the first and
only PHP standalone HTTP library to fully verify SSL hostnames even
with socket connections. This includes both SNI support and common
name checking."
Subsidising the trivial is not a bad thing ;).
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
I'll accept this as a delayed bump of my last post on the topic. ;)
- Disable peer-verification by default in windows builds. Personally, I
don't see this as a valid option as it's terrifically insecure. I believe
it's better to fail with a warning than allow users to believe they're
conducting safe transfers when they're 100% vulnerable to Man-in-the-Middle
attacks.
We can't have Windows swallowing the error while other OSes do not.
Remember that not only do we have Windows production servers, but also
people developing against local Windows installs but rolling out to
other OSes.
Also, the change applies not just to CAs in the public bundle but to
private CAs that will now need to be manually trusted (on all OSes).
You want to flag this problem as early as possible in development.
I don't consider any lowered security restrictions on a Windows build
(of the same PHP version) acceptable. That would be akin to
prescribing PHP-Windows for "toy use only."
- Do nothing and document heavily. Peer verification failures will already
generate an informative error message. Beyond this, the steps required by a
windows user to make peer verification work by default are extremely simple:
- Download this file: http://curl.haxx.se/ca/cacert.pem (or equivalent) - openssl.cafile = C:/path/to/cacert.pem (in php.ini)
Also, we could easily generate a painfully explicit
E_WARNINGin windows
explaining exactly how to fix the problem in the absence of the requisite
configuration.
If [2] is necesssary, then we should accept the burden of being as
verbose as possible.
- Include the same PEM-formatted CA file curl distributes with windows PHP
binaries and pre-populate the relevant php.ini directive. I don't think
this would come with any licensing issues as the curl cacert file is
licensed under the same licenses as the Mozilla source file it draws from
(MPL 1.1, GPL v2.0 or LGPL 2.1). However, I'm not an expert in these
matters, so others would likely need to comment.
I have no idea about the licensing burdens, but [3] is vastly
preferred if available. Encumbering Windows users with manual
configuration when WPI is supposed to be a package managaer.
Another related possibility (if it eases licensing worries somehow) is
having a separate WPI package for "PHP CA Bundle" -- so it can be
maintained + licensed + removed separately. I know you can make one
WPI depend on another (like with the Windows Role/Feature manager et
al.).
-- Sandy
Following on from this thread and Daniel's excellent work on TLS
improvements, and liaising heavily with Daniel off-list, I have
created a PR [1] of some work I have done to get peer verification
working with Windows native certificate store.
This is by far and away the most preferable option as it gives "out of
the box" support for peer verification by default on Windows, and does
not require any additional certificate bundles or configuration. It
also allows us to take advantage of trust updates rolled out via MS
update systems.
The implementation is complete in that it supports all existing
features, although it needs a little polishing and some edge cases
covering before it can be merged. The only definite known issue at the
time of writing is that the method for fetching the CN from the
certificate incorrectly assumes that the returned data will always be
UTF-8 encoded, a solution for this is planned and will be implemented
in the next day or two.
I am by no means an expert on the subject matter here in any respect,
so I encourage ruthless code review.
Note that there are no new features here, it is simply looking to fill
in the gaps in the recent work by providing consistency on Windows.
Following on from this thread and Daniel's excellent work on TLS
improvements, and liaising heavily with Daniel off-list, I have
created a PR [1] of some work I have done to get peer verification
working with Windows native certificate store.This is by far and away the most preferable option as it gives "out of
the box" support for peer verification by default on Windows, and does
not require any additional certificate bundles or configuration. It
also allows us to take advantage of trust updates rolled out via MS
update systems.The implementation is complete in that it supports all existing
features, although it needs a little polishing and some edge cases
covering before it can be merged. The only definite known issue at the
time of writing is that the method for fetching the CN from the
certificate incorrectly assumes that the returned data will always be
UTF-8 encoded, a solution for this is planned and will be implemented
in the next day or two.I am by no means an expert on the subject matter here in any respect,
so I encourage ruthless code review.Note that there are no new features here, it is simply looking to fill
in the gaps in the recent work by providing consistency on Windows.
Count me as a big +1 on this. Delegating out to the OS is the only good
solution and managing/distributing our own CA store is asking for trouble.
That said, I don't have any familiarity with the windows APIs in this area.
I'll be testing, poking and prodding the code in the next couple of days,
though.
hi Chris!
Following on from this thread and Daniel's excellent work on TLS
improvements, and liaising heavily with Daniel off-list, I have
created a PR [1] of some work I have done to get peer verification
working with Windows native certificate store.
Very good job! I like it! Thanks.
This is by far and away the most preferable option as it gives "out of
the box" support for peer verification by default on Windows, and does
not require any additional certificate bundles or configuration. It
also allows us to take advantage of trust updates rolled out via MS
update systems.The implementation is complete in that it supports all existing
features, although it needs a little polishing and some edge cases
covering before it can be merged. The only definite known issue at the
time of writing is that the method for fetching the CN from the
certificate incorrectly assumes that the returned data will always be
UTF-8 encoded, a solution for this is planned and will be implemented
in the next day or two.I am by no means an expert on the subject matter here in any respect,
so I encourage ruthless code review.Note that there are no new features here, it is simply looking to fill
in the gaps in the recent work by providing consistency on Windows.
I have however some doubts about doing that now (not sure if I raised
these points already).
Using Windows CA store is a good thing, from a theoretical point of
view. However it brings a couple of issues with it. The 1st one is
compatibility, it is a different system using different methods to
store, add or manage certificate. One of the key point we try to keep
in PHP is almost 100% compatibility between Windows and other
platforms. That's one of the main reasons why I did not implement SSL
support using WInSSL APIs back then for 5.3.0.
I am also not sure about the impact this change will have on existing
code using more advanced features (context, environment customization,
etc) of openssl, be with stream or with openssl only. It may impact
performance as well a little bit but I need to test it first to
compare, did you try to see if there are performance regressions?
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.
I hope you do not take this reply as a bad reply, I really appreciate
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.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Good morning Pierre,
hi Chris!
Following on from this thread and Daniel's excellent work on TLS
improvements, and liaising heavily with Daniel off-list, I have
created a PR [1] of some work I have done to get peer verification
working with Windows native certificate store.Very good job! I like it! Thanks.
This is by far and away the most preferable option as it gives "out of
the box" support for peer verification by default on Windows, and does
not require any additional certificate bundles or configuration. It
also allows us to take advantage of trust updates rolled out via MS
update systems.The implementation is complete in that it supports all existing
features, although it needs a little polishing and some edge cases
covering before it can be merged. The only definite known issue at the
time of writing is that the method for fetching the CN from the
certificate incorrectly assumes that the returned data will always be
UTF-8 encoded, a solution for this is planned and will be implemented
in the next day or two.I am by no means an expert on the subject matter here in any respect,
so I encourage ruthless code review.Note that there are no new features here, it is simply looking to fill
in the gaps in the recent work by providing consistency on Windows.I have however some doubts about doing that now (not sure if I raised
these points already).Using Windows CA store is a good thing, from a theoretical point of
view. However it brings a couple of issues with it. The 1st one is
compatibility, it is a different system using different methods to
store, add or manage certificate. One of the key point we try to keep
in PHP is almost 100% compatibility between Windows and other
platforms. That's one of the main reasons why I did not implement SSL
support using WInSSL APIs back then for 5.3.0.I am also not sure about the impact this change will have on existing
code using more advanced features (context, environment customization,
etc) of openssl, be with stream or with openssl only. It may impact
performance as well a little bit but I need to test it first to
compare, did you try to see if there are performance regressions?
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.
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.
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.
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.
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.
Not saying it's a bad idea just wondering how practical it is. Or did
I misunderstand what you're getting at?
I hope you do not take this reply as a bad reply, I really appreciate
Not at all :-)
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.
Thanks for your comments, they are most welcome :-)
Chris
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.
hi Chris,
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
hi Chris,
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-cryptoI'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.
Hi,
There is an existing extension already, with a much nicer and
userfriendlier API, https://github.com/bukka/php-crypto
I am glad that you like the API.
The extension is currently useful just for hashing, symmetric cryptography,
random bytes and base64 coding. It means that it's more an alternative for
mcrypt than openssl in the current form. :) There is no support for certs
handling yet.
However I would like to wrap almost all parts of OpenSSL including the
certs. I want to provide a nice user space API and keep the internal code
structured and clean with minimum code duplication. That's probably the
hardest part and takes lots of my time. I would appreciate any help though.
Any ideas or patches are more than welcomed. I work on the stream support
at the moment (see https://github.com/bukka/php-crypto/issues/8 ) and also
need to sort the error handling out (
https://github.com/bukka/php-crypto/issues/9 ). Feel free to comment the
issues if you have any ideas or create a new issue for other feature ideas.
;) The latest commits are on the next branch if you want to see the latest
changes. ( https://github.com/bukka/php-crypto/tree/next )
P.S. sorry for a little hijack of this thread... ;)
Thanks
Jakub
Following on from this thread and Daniel's excellent work on TLS
improvements, and liaising heavily with Daniel off-list, I have
created a PR [1] of some work I have done to get peer verification
working with Windows native certificate store.This is by far and away the most preferable option as it gives "out of
the box" support for peer verification by default on Windows, and does
not require any additional certificate bundles or configuration. It
also allows us to take advantage of trust updates rolled out via MS
update systems.The implementation is complete in that it supports all existing
features, although it needs a little polishing and some edge cases
covering before it can be merged. The only definite known issue at the
time of writing is that the method for fetching the CN from the
certificate incorrectly assumes that the returned data will always be
UTF-8 encoded, a solution for this is planned and will be implemented
in the next day or two.I am by no means an expert on the subject matter here in any respect,
so I encourage ruthless code review.Note that there are no new features here, it is simply looking to fill
in the gaps in the recent work by providing consistency on Windows.
awesome, thank you for putting this together!
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Following on from this thread and Daniel's excellent work on TLS
improvements, and liaising heavily with Daniel off-list, I have
created a PR [1] of some work I have done to get peer verification
working with Windows native certificate store.This is by far and away the most preferable option as it gives "out of
the box" support for peer verification by default on Windows, and does
not require any additional certificate bundles or configuration. It
also allows us to take advantage of trust updates rolled out via MS
update systems.The implementation is complete in that it supports all existing
features, although it needs a little polishing and some edge cases
covering before it can be merged. The only definite known issue at the
time of writing is that the method for fetching the CN from the
certificate incorrectly assumes that the returned data will always be
UTF-8 encoded, a solution for this is planned and will be implemented
in the next day or two.I am by no means an expert on the subject matter here in any respect,
so I encourage ruthless code review.Note that there are no new features here, it is simply looking to fill
in the gaps in the recent work by providing consistency on Windows.
This patch is now merged (thanks Daniel) and will be available in the
next alpha. If anyone finds anything that doesn't behave as expected,
please let me know.
Thanks, Chris
Hi Chris,
Following on from this thread and Daniel's excellent work on TLS
improvements, and liaising heavily with Daniel off-list, I have created a
PR [1] of some work I have done to get peer verification
working with Windows native certificate store.This is by far and away the most preferable option as it gives "out of
the box" support for peer verification by default on Windows, and does
not require any additional certificate bundles or configuration. It also
allows us to take advantage of trust updates rolled out via MS update
systems.The implementation is complete in that it supports all existing
features, although it needs a little polishing and some edge cases
covering before it can be merged. The only definite known issue at the
time of writing is that the method for fetching the CN from the
certificate incorrectly assumes that the returned data will always be
UTF-8 encoded, a solution for this is planned and will be implemented
in the next day or two.I am by no means an expert on the subject matter here in any respect,
so I encourage ruthless code review.Note that there are no new features here, it is simply looking to fill
in the gaps in the recent work by providing consistency on Windows.This patch is now merged (thanks Daniel) and will be available in the
next alpha. If anyone finds anything that doesn't behave as expected,
please let me know.
the tests with the removed pcntl dependencies do fail for me. I made a
small change here
http://git.php.net/?p=php-src.git;a=commitdiff;h=56cbe043810ab773605aa6a6ca2eb362ea9a54e9
but still there are some with the similar diff
TEST 43/79
[C:\php-sdk\php56\vc11\x64\php-src\ext\openssl\tests\bug65538_001.phpt]
========DIFF========
001+ Warning: file_get_contents(https://127.0.0.1:64321/): failed to open
stream: No connection could be made because the target machine actively
refused it.
001- string(12) "Hello World!"
002+ in
C:\php-sdk\php56\vc11\x64\php-src\ext\openssl\tests\ServerClientTestCase.inc(93)
: eval()'d code on line 8
003+ bool(false)
========DONE========
Actually it's great to get rid of that pcntl dependency there, just we
should bring it inline. Working on the further fixes.
Regards
Anatol
Hi Anatol
It's interesting that you should have a problem here, both Daniel and
I extensively "tested the tests" to ensure they would run and pass on
both windows and *nix - although I never tested on mac because I don't
have easy access to one (I'm not sure if Daniel did) but I assumed
they would work nicely there since they worked on all the *nix
flavours I tested. WHat OS are you running these on?
The diff you show doesn't look like it would fix the problem as it
seems to be waiting for eof on stdin in the worker, which shouldn't
ever happen until the test is completed in the main process (the
handle isn't closed until the main process code has finished
executing, which if it uses a wait() will never happen if the worker
executes successfully.
I think it's likely that your machine is having difficulties launching
the background process for some reason, I suggest you inspect the $cmd
path generated in spawnWorkerProcess().
One thought that does occur is that it might be worth changing the
sprintf pattern to "%s" "%s" %s - if you had any spaces in the path to
the PHP binary then the unquoted command would probably fail to
launch.
Hi Chris,
Following on from this thread and Daniel's excellent work on TLS
improvements, and liaising heavily with Daniel off-list, I have created a
PR [1] of some work I have done to get peer verification
working with Windows native certificate store.This is by far and away the most preferable option as it gives "out of
the box" support for peer verification by default on Windows, and does
not require any additional certificate bundles or configuration. It also
allows us to take advantage of trust updates rolled out via MS update
systems.The implementation is complete in that it supports all existing
features, although it needs a little polishing and some edge cases
covering before it can be merged. The only definite known issue at the
time of writing is that the method for fetching the CN from the
certificate incorrectly assumes that the returned data will always be
UTF-8 encoded, a solution for this is planned and will be implemented
in the next day or two.I am by no means an expert on the subject matter here in any respect,
so I encourage ruthless code review.Note that there are no new features here, it is simply looking to fill
in the gaps in the recent work by providing consistency on Windows.This patch is now merged (thanks Daniel) and will be available in the
next alpha. If anyone finds anything that doesn't behave as expected,
please let me know.the tests with the removed pcntl dependencies do fail for me. I made a
small change herehttp://git.php.net/?p=php-src.git;a=commitdiff;h=56cbe043810ab773605aa6a6ca2eb362ea9a54e9
but still there are some with the similar diff
TEST 43/79
[C:\php-sdk\php56\vc11\x64\php-src\ext\openssl\tests\bug65538_001.phpt]
========DIFF========
001+ Warning: file_get_contents(https://127.0.0.1:64321/): failed to open
stream: No connection could be made because the target machine actively
refused it.
001- string(12) "Hello World!"
002+ in
C:\php-sdk\php56\vc11\x64\php-src\ext\openssl\tests\ServerClientTestCase.inc(93)
: eval()'d code on line 8
003+ bool(false)
========DONE========Actually it's great to get rid of that pcntl dependency there, just we
should bring it inline. Working on the further fixes.Regards
Anatol
Hi Chris,
Hi Anatol
It's interesting that you should have a problem here, both Daniel and
I extensively "tested the tests" to ensure they would run and pass on
both windows and *nix - although I never tested on mac because I don't have
easy access to one (I'm not sure if Daniel did) but I assumed they would
work nicely there since they worked on all the *nix flavours I tested.
WHat OS are you running these on?
It's win8 64 bit build of the PHP-5.6The diff you show doesn't look like it would fix the problem as it
seems to be waiting for eof on stdin in the worker, which shouldn't ever
happen until the test is completed in the main process (the handle isn't
closed until the main process code has finished executing, which if it
uses await()will never happen if the worker executes successfully.
The issue I saw there is that while(1) has never exited because it's
expected '---' to appear to break. The way i did it at least jumps out
from the loop. For example stream_server_reneg_limit.phpt does something
else, but also hangs forever similar way. Maybe the piece with '---'
should be restored and '---' appended to all the tests, but actually it
were better to not depend on that.
I think it's likely that your machine is having difficulties launching
the background process for some reason, I suggest you inspect the $cmd path
generated in spawnWorkerProcess().
I've checked that by copying the server code explicitly and ran it in a
separate process. The hang was still there (so not leaving the while(1)
part), for instance with bug46127.phpt .
One thought that does occur is that it might be worth changing the
sprintf pattern to "%s" "%s" %s - if you had any spaces in the path to the
PHP binary then the unquoted command would probably fail to
launch.
There are no spaces in the paths, that's standard approach with
c:\php-sdk... I'll try this anyway.
Have you tested also on 64 bit builds? Maybe it's specific to that. But
the impression I have is that there's something in the PHP
code/environment behaving different for whatever reason.
Hi Chris,
Following on from this thread and Daniel's excellent work on TLS
improvements, and liaising heavily with Daniel off-list, I have
created a
PR [1] of some work I have done to get peer verification
working with Windows native certificate store.This is by far and away the most preferable option as it gives "out
of the box" support for peer verification by default on Windows, and
does not require any additional certificate bundles or
configuration. It
also
allows us to take advantage of trust updates rolled out via MS
update systems.The implementation is complete in that it supports all existing
features, although it needs a little polishing and some edge cases
covering before it can be merged. The only definite known issue at
the time of writing is that the method for fetching the CN from the
certificate incorrectly assumes that the returned data will always
be UTF-8 encoded, a solution for this is planned and will be
implemented in the next day or two.I am by no means an expert on the subject matter here in any
respect, so I encourage ruthless code review.Note that there are no new features here, it is simply looking to
fill in the gaps in the recent work by providing consistency on
Windows.This patch is now merged (thanks Daniel) and will be available in the
next alpha. If anyone finds anything that doesn't behave as
expected, please let me know.the tests with the removed pcntl dependencies do fail for me. I made a
small change herehttp://git.php.net/?p=php-src.git;a=commitdiff;h=56cbe043810ab773605aa6a6
c a2eb362ea9a54e9but still there are some with the similar diff
TEST 43/79
[C:\php-sdk\php56\vc11\x64\php-src\ext\openssl\tests\bug65538_001.phpt]
========DIFF========
001+ Warning: file_get_contents(https://127.0.0.1:64321/): failed toopen
stream: No connection could be made because the target machine actively
refused it. 001- string(12) "Hello World!"
002+ inC:\php-sdk\php56\vc11\x64\php-src\ext\openssl\tests\ServerClientTestCase.
i nc(93): eval()'d code on line 8
003+ bool(false)
========DONE========Actually it's great to get rid of that pcntl dependency there, just we
should bring it inline. Working on the further fixes.Regards
Anatol
--
Regards
Anatol
Hi Chris,
Hi Anatol
It's interesting that you should have a problem here, both Daniel and
I extensively "tested the tests" to ensure they would run and pass on
both windows and *nix - although I never tested on mac because I don't have
easy access to one (I'm not sure if Daniel did) but I assumed they would
work nicely there since they worked on all the *nix flavours I tested.
WHat OS are you running these on?
It's win8 64 bit build of the PHP-5.6The diff you show doesn't look like it would fix the problem as it
seems to be waiting for eof on stdin in the worker, which shouldn't ever
happen until the test is completed in the main process (the handle isn't
closed until the main process code has finished executing, which if it
uses await()will never happen if the worker executes successfully.
The issue I saw there is that while(1) has never exited because it's
expected '---' to appear to break. The way i did it at least jumps out
from the loop. For example stream_server_reneg_limit.phpt does something
else, but also hangs forever similar way. Maybe the piece with '---'
should be restored and '---' appended to all the tests, but actually it
were better to not depend on that.
The reason it was designed like this is to allow two way communication
between the processes via their standard streams to remain open, so
that the wait/notify system works in both directions. As it stands
none of the tests use this, but I figured it was better to leave it
there for future use. It's somewhat concerning if --- never appears
in the stream and that loop runs forever, since it's explicitly added
as an end delimiter by spawnWorkerProcess()...
stream_server_reneg_client.phpt is actually something of a special
case. It's a dirty hack using an external openssl binary to trigger
renegotiations, as there's no way to trigger this directly in userland
PHP at the moment, and both Daniel and I had issues running this test
on Windows. As it turned out, the reason for this was actually a very
old and buggy openssl binary that ships with msysgit bins and so was
in %path% - when we installed a 1.0.1f binary from
http://slproweb.com/products/Win32OpenSSL.html the test ran without
issues. I'm working to figure out exactly when the bug was fixed so we
can check for it in the SKIPIF.
Are you having issues with only certain tests or is it all of the modified ones?
I think it's likely that your machine is having difficulties launching
the background process for some reason, I suggest you inspect the $cmd path
generated in spawnWorkerProcess().I've checked that by copying the server code explicitly and ran it in a
separate process. The hang was still there (so not leaving the while(1)
part), for instance with bug46127.phpt .One thought that does occur is that it might be worth changing the
sprintf pattern to "%s" "%s" %s - if you had any spaces in the path to the
PHP binary then the unquoted command would probably fail to
launch.
There are no spaces in the paths, that's standard approach with
c:\php-sdk... I'll try this anyway.
OK that's not likely to be the issue here then, although we should
probably still make the change to cover this case.
Have you tested also on 64 bit builds? Maybe it's specific to that. But
the impression I have is that there's something in the PHP
code/environment behaving different for whatever reason.
I've not run the tests against a 64 bit build, I did create a 64 bit
binary to verify that it worked but I ran the tests against a 32 bit
build.
Hi Chris,
Following on from this thread and Daniel's excellent work on TLS
improvements, and liaising heavily with Daniel off-list, I have
created a
PR [1] of some work I have done to get peer verification
working with Windows native certificate store.This is by far and away the most preferable option as it gives "out
of the box" support for peer verification by default on Windows, and
does not require any additional certificate bundles or
configuration. It
also
allows us to take advantage of trust updates rolled out via MS
update systems.The implementation is complete in that it supports all existing
features, although it needs a little polishing and some edge cases
covering before it can be merged. The only definite known issue at
the time of writing is that the method for fetching the CN from the
certificate incorrectly assumes that the returned data will always
be UTF-8 encoded, a solution for this is planned and will be
implemented in the next day or two.I am by no means an expert on the subject matter here in any
respect, so I encourage ruthless code review.Note that there are no new features here, it is simply looking to
fill in the gaps in the recent work by providing consistency on
Windows.This patch is now merged (thanks Daniel) and will be available in the
next alpha. If anyone finds anything that doesn't behave as
expected, please let me know.the tests with the removed pcntl dependencies do fail for me. I made a
small change herehttp://git.php.net/?p=php-src.git;a=commitdiff;h=56cbe043810ab773605aa6a6
c a2eb362ea9a54e9but still there are some with the similar diff
TEST 43/79
[C:\php-sdk\php56\vc11\x64\php-src\ext\openssl\tests\bug65538_001.phpt]
========DIFF========
001+ Warning: file_get_contents(https://127.0.0.1:64321/): failed toopen
stream: No connection could be made because the target machine actively
refused it. 001- string(12) "Hello World!"
002+ inC:\php-sdk\php56\vc11\x64\php-src\ext\openssl\tests\ServerClientTestCase.
i nc(93): eval()'d code on line 8
003+ bool(false)
========DONE========Actually it's great to get rid of that pcntl dependency there, just we
should bring it inline. Working on the further fixes.Regards
Anatol
--
Regards
Anatol
Hi Chris,
Hi Chris,
Hi Anatol
It's interesting that you should have a problem here, both Daniel and
I extensively "tested the tests" to ensure they would run and pass
on both windows and *nix - although I never tested on mac because I
don't have easy access to one (I'm not sure if Daniel did) but I
assumed they would work nicely there since they worked on all the *nix
flavours I tested. WHat OS are you running these on?It's win8 64 bit build of the PHP-5.6
The diff you show doesn't look like it would fix the problem as it
seems to be waiting for eof on stdin in the worker, which shouldn't
ever happen until the test is completed in the main process (the
handle isn't closed until the main process code has finished
executing, which if it uses await()will never happen if the worker
executes successfully.
The issue I saw there is that while(1) has never exited because it's
expected '---' to appear to break. The way i did it at least jumps out
from the loop. For example stream_server_reneg_limit.phpt does
something else, but also hangs forever similar way. Maybe the piece with
'---'
should be restored and '---' appended to all the tests, but actually it
were better to not depend on that.The reason it was designed like this is to allow two way communication
between the processes via their standard streams to remain open, so that
the wait/notify system works in both directions. As it stands none of the
tests use this, but I figured it was better to leave it there for future
use. It's somewhat concerning if---never appears in the stream and
that loop runs forever, since it's explicitly added as an end delimiter by
spawnWorkerProcess()...stream_server_reneg_client.phpt is actually something of a special case.
It's a dirty hack using an external openssl binary to trigger
renegotiations, as there's no way to trigger this directly in userland PHP
at the moment, and both Daniel and I had issues running this test on
Windows. As it turned out, the reason for this was actually a very
old and buggy openssl binary that ships with msysgit bins and so was in
%path% - when we installed a 1.0.1f binary from
http://slproweb.com/products/Win32OpenSSL.html the test ran without
issues. I'm working to figure out exactly when the bug was fixed so we can
check for it in the SKIPIF.Are you having issues with only certain tests or is it all of the
modified ones?I think it's likely that your machine is having difficulties
launching the background process for some reason, I suggest you
inspect the $cmd path generated in spawnWorkerProcess().I've checked that by copying the server code explicitly and ran it in a
separate process. The hang was still there (so not leaving the
while(1) part), for instance with bug46127.phpt .One thought that does occur is that it might be worth changing the
sprintf pattern to "%s" "%s" %s - if you had any spaces in the path to
the PHP binary then the unquoted command would probably fail to
launch.
There are no spaces in the paths, that's standard approach with
c:\php-sdk... I'll try this anyway.OK that's not likely to be the issue here then, although we should
probably still make the change to cover this case.Have you tested also on 64 bit builds? Maybe it's specific to that. But
the impression I have is that there's something in the PHP
code/environment behaving different for whatever reason.I've not run the tests against a 64 bit build, I did create a 64 bit
binary to verify that it worked but I ran the tests against a 32 bit build.
I've figured out what's wrong. The issue is the way how the server process
is spawned, under circumstances it might not load the openssl extension.
That's none of issue when openssl is compiled statically like it often
might be done on linux. On windows it's always shared, so the solution is
to ensure there's a suitable php.ini is laying around or explicitly
passing a temporary php.ini to the spawnee and ensuring the openssl deps
are on the path.
Still stream_server_reneg_limit.phpt hangs, but sa you mentioned that
being an issue. Lets see how it behaves further.
Thanks for the help on this.
Anatol
Hi Anatol
Just to follow up on this, I've been kicking around a few ideas to try
and come up with a better way to test this but I've not come up with
anything workable - mostly I've been trying to come up with something
sane based on non-blocking I/O and have concluded that there's no way
to do it that doesn't involved too much code for a meaningful unit
test (and it's of limited usefulness anyway). There really are a lot
of variables here and it's difficult to come up with something that's
going to work in every environment every time, which for me really
limits the usefulness anything you might call a unit test.
One thing I was pondering is throwing together a small server that
could be started by run-tests.php in another process before any tests
are run, which exposes a set of various defined behaviours on various
ports. This way, all unit tests that involve testing the client side
(or where which side you test from is irrelevant) can simply connect
to the appropriate port for the behaviour they want. This would also
have the benefit of making the tests themselves (considerably)
simpler. However, even I am still not sure whether I like the idea.
Thoughts?
Hi Chris,
Hi Chris,
Hi Anatol
It's interesting that you should have a problem here, both Daniel and
I extensively "tested the tests" to ensure they would run and pass
on both windows and *nix - although I never tested on mac because I
don't have easy access to one (I'm not sure if Daniel did) but I
assumed they would work nicely there since they worked on all the *nix
flavours I tested. WHat OS are you running these on?It's win8 64 bit build of the PHP-5.6
The diff you show doesn't look like it would fix the problem as it
seems to be waiting for eof on stdin in the worker, which shouldn't
ever happen until the test is completed in the main process (the
handle isn't closed until the main process code has finished
executing, which if it uses await()will never happen if the worker
executes successfully.
The issue I saw there is that while(1) has never exited because it's
expected '---' to appear to break. The way i did it at least jumps out
from the loop. For example stream_server_reneg_limit.phpt does
something else, but also hangs forever similar way. Maybe the piece with
'---'
should be restored and '---' appended to all the tests, but actually it
were better to not depend on that.The reason it was designed like this is to allow two way communication
between the processes via their standard streams to remain open, so that
the wait/notify system works in both directions. As it stands none of the
tests use this, but I figured it was better to leave it there for future
use. It's somewhat concerning if---never appears in the stream and
that loop runs forever, since it's explicitly added as an end delimiter by
spawnWorkerProcess()...stream_server_reneg_client.phpt is actually something of a special case.
It's a dirty hack using an external openssl binary to trigger
renegotiations, as there's no way to trigger this directly in userland PHP
at the moment, and both Daniel and I had issues running this test on
Windows. As it turned out, the reason for this was actually a very
old and buggy openssl binary that ships with msysgit bins and so was in
%path% - when we installed a 1.0.1f binary from
http://slproweb.com/products/Win32OpenSSL.html the test ran without
issues. I'm working to figure out exactly when the bug was fixed so we can
check for it in the SKIPIF.Are you having issues with only certain tests or is it all of the
modified ones?I think it's likely that your machine is having difficulties
launching the background process for some reason, I suggest you
inspect the $cmd path generated in spawnWorkerProcess().I've checked that by copying the server code explicitly and ran it in a
separate process. The hang was still there (so not leaving the
while(1) part), for instance with bug46127.phpt .One thought that does occur is that it might be worth changing the
sprintf pattern to "%s" "%s" %s - if you had any spaces in the path to
the PHP binary then the unquoted command would probably fail to
launch.
There are no spaces in the paths, that's standard approach with
c:\php-sdk... I'll try this anyway.OK that's not likely to be the issue here then, although we should
probably still make the change to cover this case.Have you tested also on 64 bit builds? Maybe it's specific to that. But
the impression I have is that there's something in the PHP
code/environment behaving different for whatever reason.I've not run the tests against a 64 bit build, I did create a 64 bit
binary to verify that it worked but I ran the tests against a 32 bit build.I've figured out what's wrong. The issue is the way how the server process
is spawned, under circumstances it might not load the openssl extension.
That's none of issue when openssl is compiled statically like it often
might be done on linux. On windows it's always shared, so the solution is
to ensure there's a suitable php.ini is laying around or explicitly
passing a temporary php.ini to the spawnee and ensuring the openssl deps
are on the path.Still stream_server_reneg_limit.phpt hangs, but sa you mentioned that
being an issue. Lets see how it behaves further.Thanks for the help on this.
Anatol