[PHP-DEV] PROPOSAL: new class entry for grouping functions, consts and vars
Hi, I wrote a *rough* patch to add new class entry "definition" for grouping functions, consts and vars. https://github.com/kuzuha/php-src/compare/feature;definition As you know, defining a lot of constants makes php slower. I think autoload is very nice solution to avoid that problem. Autoloading skips unnecessary code and makes php faster. The "definition" block means Grouped defines. That gives autoloading to function, consts and vars. And PSR-0 helps simplify directory tree. Pros: * Never mind where to put .php file for definitions. Following PSR-0 is nice idea. * Can refactoring definitions without hesitation. * Separate implementation from definition specifically. Cons: * Big impact to language. How do you think about this? I hope I'll get your feedback. Best regards, Kuzuha SHINODA
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On 19 September 2013 17:41, Pierre Joye wrote: > It does when you use curl's win32 SSL support. That makes my previous > point wrong as we do not compile it with this option but openssl (for > cross platform compatibility reasons). But as the curl's ca file works > just fine, everything is good. > > Would it make sense to share that option for openssl itself? I think so, particularly if we did make peer validation the default. Most Windows users would be happy to just use the system certificate store, I would think, so that would be one less thing to configure post-install. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On Thu, Sep 19, 2013 at 5:38 PM, Adam Harvey wrote: > On 19 September 2013 17:31, Pierre Joye wrote: >> On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey wrote: >>> As for the CA bundle side of things, I wonder if this is one of those >>> rare times where an ini setting might make sense, as opposed to actual >>> bundling — that would allow distros to point to their packaged bundles >>> without needing to patch php-src, and we could provide from-source >>> installation instructions easily enough to point to common distro >>> locations and the cURL download for users on more exotic OSes (like >>> Windows). >> >> Windows supports that very well, with Curl for example. It can also >> uses the OS certificates database. >> >> For the record here, curl has this setting already: >> >> http://us2.php.net/manual/en/curl.configuration.php#ini.curl.cainfo >> >> which is around for quite some time already. >> >> It could be possible to share it with openssl, but back then I did not >> check it out as only curl was concerned. > > Is that something cURL provides, or that we do? A (very) cursory > Google suggests that OpenSSL doesn't have support for the Windows > certificate store natively, so we'd presumably have to patch that up > (with a sensible default php.ini setting, if we went that way — > "ssl.ca_bundle = win32", or something similar). It does when you use curl's win32 SSL support. That makes my previous point wrong as we do not compile it with this option but openssl (for cross platform compatibility reasons). But as the curl's ca file works just fine, everything is good. Would it make sense to share that option for openssl itself? >> One thing I do not remember off hand is if we actually enable cert >> validation per default with php's curl. It should be as we discussed >> that already many times. > > We do. I checked before the first e-mail. :) Thanks :) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On 19 September 2013 17:31, Pierre Joye wrote: > On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey wrote: >> As for the CA bundle side of things, I wonder if this is one of those >> rare times where an ini setting might make sense, as opposed to actual >> bundling — that would allow distros to point to their packaged bundles >> without needing to patch php-src, and we could provide from-source >> installation instructions easily enough to point to common distro >> locations and the cURL download for users on more exotic OSes (like >> Windows). > > Windows supports that very well, with Curl for example. It can also > uses the OS certificates database. > > For the record here, curl has this setting already: > > http://us2.php.net/manual/en/curl.configuration.php#ini.curl.cainfo > > which is around for quite some time already. > > It could be possible to share it with openssl, but back then I did not > check it out as only curl was concerned. Is that something cURL provides, or that we do? A (very) cursory Google suggests that OpenSSL doesn't have support for the Windows certificate store natively, so we'd presumably have to patch that up (with a sensible default php.ini setting, if we went that way — "ssl.ca_bundle = win32", or something similar). > One thing I do not remember off hand is if we actually enable cert > validation per default with php's curl. It should be as we discussed > that already many times. We do. I checked before the first e-mail. :) Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey wrote:
> On 19 September 2013 10:52, Daniel Lowrey wrote:
>>> *I consider this a bug* I understand that it's easier to code not verifying
>>> the
>>> peer, and the hostname may not be available when you are stacking ssl over
>>> a stream.
>>> But file_get_contents("https://...";) is *precisely* the case that should
>>> work right
>>> out of the box.
>>
>> ^^ This.
>>
>> Before I can fully/cleanly implement these changes we need to decide
>> if PHP wants to move to a secure-by-default model for streams
>> utilizing the built in encryption wrappers. Thoughts?
>
> I think we should do this in 5.6. cURL has behaved this way for
> literally years at this point (verify by default, provide a switch to
> disable verification) and users seem to do just fine there. The much
> improved security story outweighs the (admittedly present) BC issues
> for mine.
>
> As for the CA bundle side of things, I wonder if this is one of those
> rare times where an ini setting might make sense, as opposed to actual
> bundling — that would allow distros to point to their packaged bundles
> without needing to patch php-src, and we could provide from-source
> installation instructions easily enough to point to common distro
> locations and the cURL download for users on more exotic OSes (like
> Windows).
Windows supports that very well, with Curl for example. It can also
uses the OS certificates database.
For the record here, curl has this setting already:
http://us2.php.net/manual/en/curl.configuration.php#ini.curl.cainfo
which is around for quite some time already.
It could be possible to share it with openssl, but back then I did not
check it out as only curl was concerned.
One thing I do not remember off hand is if we actually enable cert
validation per default with php's curl. It should be as we discussed
that already many times.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On 19/09/13 23:41, Adam Harvey wrote: As for the CA bundle side of things, I wonder if this is one of those rare times where an ini setting might make sense, as opposed to actual bundling — that would allow distros to point to their packaged bundles without needing to patch php-src, and we could provide from-source installation instructions easily enough to point to common distro locations and the cURL download for users on more exotic OSes (like Windows). Adam +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
> I think we should do this in 5.6. +1 ... a renewed "emphasis on security" makes a good selling point when answering the "why should I upgrade" questions. At the same time, targeting the next minor version gives people ample time to plan/test/document changes. Secure stream encryption settings by default is a good place to start. > I wonder if this is one of those rare times where an ini setting might make sense I'm generally anti-.ini but this sounds sensible.
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On 19 September 2013 10:52, Daniel Lowrey wrote:
>> *I consider this a bug* I understand that it's easier to code not verifying
>> the
>> peer, and the hostname may not be available when you are stacking ssl over a
>> stream.
>> But file_get_contents("https://...";) is *precisely* the case that should
>> work right
>> out of the box.
>
> ^^ This.
>
> Before I can fully/cleanly implement these changes we need to decide
> if PHP wants to move to a secure-by-default model for streams
> utilizing the built in encryption wrappers. Thoughts?
I think we should do this in 5.6. cURL has behaved this way for
literally years at this point (verify by default, provide a switch to
disable verification) and users seem to do just fine there. The much
improved security story outweighs the (admittedly present) BC issues
for mine.
As for the CA bundle side of things, I wonder if this is one of those
rare times where an ini setting might make sense, as opposed to actual
bundling — that would allow distros to point to their packaged bundles
without needing to patch php-src, and we could provide from-source
installation instructions easily enough to point to common distro
locations and the cURL download for users on more exotic OSes (like
Windows).
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
> If a subjectAltName extension of type dNSName is present, that MUST
> be used as the identity. Otherwise, the (most specific) Common Name
> field in the Subject field of the certificate MUST be used. Although
> the use of the Common Name is existing practice, it is deprecated and
> Certification Authorities are encouraged to use the dNSName instead.
I have a working patch locally that adds SAN verification pursuant to
RFC 2818 as outlined here (mentioned by Ryan):
http://tools.ietf.org/html/rfc2818#section-3.1
Usage looks like this:
```
$ctx = stream_context_create(['ssl' => [
'verify_peer' => TRUE,
'cafile' => '/path/to/cacert.pem',
'SAN_required' => TRUE, // default
'SAN_match' => 'www.github.com'
'CN_match' => 'www.github.com'
]]);
$uri = 'https://www.github.com/';
file_get_contents($uri, FALSE, $ctx);
```
The patch is strict. I.E. it follows the spec and *will* fail your SSL
negotiation attempt (with a descriptive error message to explain why)
if the remote peer provided a list of SAN names and you didn't specify
an `SN_match` stream context option. If no SAN dNSNames are supplied
by the peer the routine will fallback to the CN_match if specified.
This behavior is emphasized with a *MUST* in the RFC (meaning PHP's
current implementation is NOT compliant). I'm happy to bring the
default behavior into line with the spec but we need to determine if
people are okay with making things secure by default. This seems like
a no-brainer to me as IMHO security should be prioritized over
simplicity:
> *I consider this a bug* I understand that it's easier to code not verifying
> the
> peer, and the hostname may not be available when you are stacking ssl over a
> stream.
> But file_get_contents("https://...";) is *precisely* the case that should work
> right
> out of the box.
^^ This.
Before I can fully/cleanly implement these changes we need to decide
if PHP wants to move to a secure-by-default model for streams
utilizing the built in encryption wrappers. Thoughts?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.5.4 has been released
Hi! The PHP development team announces the immediate availability of PHP 5.5.4. This release fixes several bugs against PHP 5.5.3. All PHP users are encouraged to upgrade to this new version. For source downloads of PHP 5.5.4 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on: http://windows.php.net/download/ The list of changes is recorded in the ChangeLog at: http://www.php.net/ChangeLog-5.php#5.5.4 We would like to thank the contributors and the PHP community for making this release available. Regards, Julien Pauli & David Soria Parra
RE: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
-Original Message- From: tjerk.meest...@gmail.com [mailto:tjerk.meest...@gmail.com] On Behalf Of Tjerk Anne Meesters Sent: Thursday, September 19, 2013 4:01 AM > My point is that you need a reasonably up-to-date certs bundle to enable verification by default. Actually, you don't. There is no reason why certificate validation cannot be enabled by default without a CA bundle. Yes, verifications will fail by default but this is no different than the cases where someone has an oddball provider or self-signed certificates; they have to manually add the cert for verification to pass. Additionally, given the current certificate climate, I wouldn't trust anything signed by the global CAs. If you're concerned about security, you should be validating the certificate fingerprint and not trusting CAs. Bryan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
> Am 19.09.2013 um 11:10 schrieb "Leigh" : > > On 19 September 2013 03:20, William Bartlett > wrote: >> I would argue that LTR support is also inconsistent / not desired. >> >> If I wrote: >> >> $i = 0; >> is_three($i = $i + 1, $i = $i + 1, $i = $i + 1); >> >> I would certainly expect is_three to return false, but I would also expect >> $i to contain three. php doesn't normally evaluate arguments lazily, it >> would be weird for that behavior to suddenly crop up. users who want lazy >> evaluation can write it the traditional way (with &&). > > I think there has been some misunderstanding of my intention here > (maybe I communicated it badly) - Originally I was pretty confused > when reading Bobs response as it was way beyond the scope of what I > was proposing. > > When I say parameters evaluated LTR / boolean short-curcuit evaluation > I mean it like this: > > $i = 1; > $f = 1.1; > > is_int($i, $f, $i, $i) => is_int(1) && is_int(1.1) && is_int(1) && is_int(1) > > is_int($i++, $f++, $i++, $i++) => is_int(1) && is_int(1.1) && > is_int(2) && is_int(3) > > $i == 4; > $f == 2.1; > > Internally, processing will stop at the is_int(1.1) and not bother > continuing to check the types of further arguments. > > I did not mean: > > is_int($i++, $f++, $i++, $i++) => is_int($i++) && is_int($f++) && > is_int($i++) && is_int($i++) > > As Bob said, this would take some pretty nuts opcode processing, and > is completely not worth the effort involved. I may have emphasised a > parallel with isset() a bit too much, however isset() cannot take > expressions as input. > > I was never intending to try and evaluate parameters as they were > passed and jump over subsequent evaluations. Standard function call > semantics would still apply. I hope that people find that less > confusing / unexpected. Well, then I misunderstood what you meant. Then the idea is acceptable. Not sure if we need this as it is very easily possible with an one-liner in userspace code. I'm +- 0 on this. Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] free deadlock in timeout signal handler
2013/9/18 Ángel González :
> On 13/09/13 22:10, Lazy wrote:
>>
>> Hello internals,
>>
>> I'm trying to fix deadlock in an ancient php 5.2.17, php hangs on
>> internal libc lock.
>> From my understanding free is not safe to use in a signal handler, and
>> this seems to be the issue here.
>
> No, it's not.
>
>
>> http://marc.info/?l=php-internals&m=121999390109071&w=2 seems to
>> address this issue but it's not present in 5.3 or later releases.
>>
>> Very similar deadlock but with time() instead of free(),
>> https://bugs.php.net/bug.php?id=31749
>
> Are you sure it's with time() ? I do see a free() in that call stack (and no
> time),
> as I would expect, as time() is required by POSIX.1-2004 to be
> Async-signal-safe.
time() refers to https://bugs.php.net/bug.php?id=31749, You are right
this deadlock is related to free()
>> Current php also uses free() in php_error_cb() and external
>> destructors in list_entry_destructor() aren't protected by
>> HANDLE_BLOCK_INTERRUPTIONS() (which seems to be a noop in fastcgi
>> mode), so I suspect 5.5 may also contain this deadlock.
>>
>> main/main.c
>> php_error_cb()
>> 835 if (display) {
>> 836 if (PG(last_error_message)) {
>> 837 free(PG(last_error_message));
>> ...^^ deadlock if previous free was
>> interrupted by a timeout signal
>> 845 PG(last_error_type) = type;
>> 846 PG(last_error_message) = strdup(buffer);
>>
>> I'm thinking about "fixing" this by leaking memory pointed by
>> PG(last_error_message) if php called when a timeout is pending
>> (timeouts are usually very rare, php processes will eventually be
>> restarted so this little memory waste won't have time to make any
>> impact.
>>
>> Is this issue fixed in modern php ? If so I would be grateful for some
>> information about the way it was done. This would save me a lot of
>> time trying to trigger
>> a non existing confition.
>>
>> I will try to reproduce this in a modern version of php.
>
> It probably isn't. PG(last_error_message) is only modified in main.c, I
> would try to use a separate arena for PG(last_error_message) and
> PG(last_error_file). For instance it could be a static buffer reused during
> the whole execution and extended with mmap(2) in the unlikely case it turns
> out to be too small. I suspect it would also make the error handler faster,
> as it would avoid the free() + malloc()
thank You I didn't notice that it is used only there, i will try to
use a static buffer.
I managed to produce a segfault on current php version (php heap
corruption), bug report https://bugs.php.net/bug.php?id=65674
spprintf() allocating memory is also not safe. I will try to fix this
by using a static buffer.
Thanks,
Michal Grzedzicki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On Thu, Sep 19, 2013 at 09:58:59AM +0100, Chris Wright wrote: > On Thu, Sep 19, 2013 at 2:07 AM, Tjerk Anne Meesters > wrote: > > To be practical, verifying certificates requires an up-to-date CA bundle > > to be shipped with PHP; perhaps this is a simple thing to do, I'm not > > sure. > > Unfortunately it isn't. It's easily possible to ship a current CA bundle > *at the point when PHP is built/installed* but this needs to be *kept* up > to date in order to remain useful. In the real world, people don't update > production servers with every new release and the CA bundle that was > correct at the time of print (as it were) would soon become outdated - > although arguably an outdated bundle is better than nothing. Agreed, however few people take PHP from the sources & compile it themselves. Most people will use the PHP that comes with their operating system and will expect their vendor/distributor to keep it up to date (security patches, etc). If the PHP project includes a CA bundle that is kept up to date then the vendor/distributors can update their customers as & when. It is not realistic to expect someone who is running a small web server to put the time into monitoring if they have up to date CA bundles; even if they understand what it is all about they probably don't have the time. This is what people expect the operating system vendor/distributor to do for them; end users will generally install updates when they become available, they generally have a hazy idea what these updates to -- that is OK, they have other things to worry about. What I am saying is that the PHP project should include a CA bundle, probably as a separately installable component that can be updated separately. This will help the vendors/distributors to push out updates to their users. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
On 19 September 2013 03:20, William Bartlett wrote: > I would argue that LTR support is also inconsistent / not desired. > > If I wrote: > > $i = 0; > is_three($i = $i + 1, $i = $i + 1, $i = $i + 1); > > I would certainly expect is_three to return false, but I would also expect > $i to contain three. php doesn't normally evaluate arguments lazily, it > would be weird for that behavior to suddenly crop up. users who want lazy > evaluation can write it the traditional way (with &&). I think there has been some misunderstanding of my intention here (maybe I communicated it badly) - Originally I was pretty confused when reading Bobs response as it was way beyond the scope of what I was proposing. When I say parameters evaluated LTR / boolean short-curcuit evaluation I mean it like this: $i = 1; $f = 1.1; is_int($i, $f, $i, $i) => is_int(1) && is_int(1.1) && is_int(1) && is_int(1) is_int($i++, $f++, $i++, $i++) => is_int(1) && is_int(1.1) && is_int(2) && is_int(3) $i == 4; $f == 2.1; Internally, processing will stop at the is_int(1.1) and not bother continuing to check the types of further arguments. I did not mean: is_int($i++, $f++, $i++, $i++) => is_int($i++) && is_int($f++) && is_int($i++) && is_int($i++) As Bob said, this would take some pretty nuts opcode processing, and is completely not worth the effort involved. I may have emphasised a parallel with isset() a bit too much, however isset() cannot take expressions as input. I was never intending to try and evaluate parameters as they were passed and jump over subsequent evaluations. Standard function call semantics would still apply. I hope that people find that less confusing / unexpected. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On Thu, Sep 19, 2013 at 2:02 PM, Pierre Joye wrote:
>
> On Sep 18, 2013 6:07 PM, "Tjerk Anne Meesters" wrote:
> >
> > On Thu, Sep 19, 2013 at 8:33 AM, Ángel González
> wrote:
> >
> > > On 16/09/13 15:58, Daniel Lowrey wrote:
> > >
> > >> More generally, PHP's stream encryption aspects are quite poorly
> > >> documented. For example, https:// streams disable peer verification
> by
> > >> default. While I understand that this is necessary to provide the
> easiest
> > >> possible user experience for things like `file_get_contents("
> > >> https://somesite.com";)`, it's also horribly insecure. 99% of people
> using
> > >> tools like this won't know anything about this "feature" and won't
> realize
> > >> that their stream transfers are totally vulnerable to
> Man-in-the-Middle
> > >> attacks by default.
> > >>
> > > Count me as one of those that didn't know https:// streams didn't
> verify
> > > certificates. :)
> > > *I consider this a bug* I understand that it's easier to code not
> > > verifying the
> > > peer, and the hostname may not be available when you are stacking ssl
> over
> > > a stream.
> > > But file_get_contents("https://...**";) is *precisely* the case that
> > > should work right
> > > out of the box.
> >
> >
> > To be practical, verifying certificates requires an up-to-date CA bundle
> to
> > be shipped with PHP; perhaps this is a simple thing to do, I'm not sure.
> > This is an oft seen scenario for cURL; the developer would see the
> > certificate issue, search online and continue with `CURLOPT_VERIFY_PEER
> =>
> > 0`. That said, at least cURL is configured to check the certificate by
> > default.
> >
>
> FYI, curl allows to give the path to a cert db, it can be set in php.ini
> too (if I remember correctly)
>
Yes, I know that. This can also be done with the ca_file / ca_path context
options when you use streams. My point is that you need a reasonably
up-to-date certs bundle to enable verification by default.
It could be impractical to ship such a bundle with php itself, in which
case one might consider updating the documentation to highlight where such
cert bundles can be downloaded from.
--
--
Tjerk
RE: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
On Thu, Sep 19, 2013 at 2:07 AM, Tjerk Anne Meesters wrote: > To be practical, verifying certificates requires an up-to-date CA bundle > to be shipped with PHP; perhaps this is a simple thing to do, I'm not > sure. Unfortunately it isn't. It's easily possible to ship a current CA bundle *at the point when PHP is built/installed* but this needs to be *kept* up to date in order to remain useful. In the real world, people don't update production servers with every new release and the CA bundle that was correct at the time of print (as it were) would soon become outdated - although arguably an outdated bundle is better than nothing. IMHO the only real solution to this issue is education - the docs need some big fat red boxes along the lines of "in order for this to be useful you need an up to date CA bundle, it's dead easy to set up, here's how you do it". A fairly decent root CA bundle can be obtained and kept current with a simple cron/wget for http://curl.haxx.se/ca/cacert.pem - this is not the best source in the world but it is probably the simplest to explain to the common man. I figure that a CA bundle that may contain a couple of less than trustworthy certs (see http://sourceforge.net/p/curl/bugs/1178/) is better than completely disabling peer verification. On the same note, I suppose that shipping this bundle with PHP is better than nothing. On Thu, Sep 19, 2013 at 1:46 AM, Ryan McCue wrote: > PHP can't handle subjectAltNames in certificates, which causes quite a > few failures. +1, I've been bitten by this a couple of times, it definitely needs fixing. On Thu, Sep 19, 2013 at 3:58 AM, Daniel Lowrey wrote: > P.S. Thank you to whomever updated > http://php.net/manual/en/context.ssl.php to reflect the > "disable_compression" SSL stream context option (and subsidized my > laziness) :) You're welcome :-) You've got your work cut out breaking your own undocumented API, no time for updating other people's docs :-P On Thu, Sep 19, 2013 at 7:10 AM, Pierre Joye wrote: > FYI, curl allows to give the path to a cert db, it can be set in php.ini > too (if I remember correctly) You do. Were PHP to be shipped with a default CA bundle, it would be nice to see the default ini files preconfigured with this, *however* PHP requires that curl.cafile be an absolute path, which could cause issues here. I don't know how difficult it would be to accept something that could be unambiguous without being absolute? I would suggest that if we were to ship a default CA bundle, it be included in the "extras" directory in the Windows builds. Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
