Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38535
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain phparch.com from 64.99.136.171 cause and error)
Message-ID: <001701c8d521$97a83740$4401a8c0@foxbox>
Reply-To: "Steph Fox" <steph@phparch.com>
To: "Marcus Boerger" <mail@marcus-boerger.de>,
	<greg@chiaraquartet.net>
Cc: "internals" <internals@lists.php.net>
References: <20080622215109.PNGU6859.atlmtaow02.cingularme.com@COM>
Date: Mon, 23 Jun 2008 12:09:20 +0100
Organization: php|architect
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: OpenSSL and Phar
From: steph@phparch.com ("Steph Fox")


Hi, Greg,

OK, you've missed my point too, so let's start over from scratch. Please 
read carefully.

I am working under Windows, a little-known operating system which as yet has 
no way of offering openssl support in ext/phar. My task is to make that 
work.

If I set it up in the usual way, this configuration works as expected:

--enable-phar --with-openssl

It works by defining PHAR_HAVE_OPENSSL, which switches everything on. That 
triggers a dependency on the openssl libraries, but it's hidden because the 
openssl extension shares that dependency.

If PHAR_HAVE_OPENSSL is not defined, phar relies on openssl extension calls. 
(I haven't yet investigated what happens to those when the user has no 
ext/openssl support at all.) Using something like PHAR_HAVE_OPENSSL_EXT to 
define that relationship can't work because there is no correlation between 
shared extensions that might be loaded by users and the original configure 
line for a given PHP build. We can only know whether or not the openssl 
extension was _built_ at the same time as phar.

These configurations can only work if we give phar an **explicit** 
dependency on the openssl libs:

--enable-phar=shared --with-openssl
--enable-phar --with-openssl=shared
--enable-phar=shared --with-openssl=shared

The question is whether that dependency should be triggered by an explicit 
configuration option, instead of implicitly by the coincidence of 
having --with-openssl in the configure line. I personally feel that we 
should, and suggest we use --enable-phar-ssl[=shared] for this.

Thanks,

- Steph



----- Original Message ----- 
From: <greg@chiaraquartet.net>
To: "Steph Fox" <steph@phparch.com>; "Marcus Boerger" 
<mail@marcus-boerger.de>
Cc: "internals" <internals@lists.php.net>
Sent: Sunday, June 22, 2008 9:50 PM
Subject: Re: OpenSSL and Phar



Hi,

Steph, look more closely, the libraries are only used if openssl is built 
statically.  Otherwise, phar directly calls openssl_verify or openssl_sign.

Greg

-----Original Message-----

From:  "Steph Fox" <steph@phparch.com>
Subj:  OpenSSL and Phar
Date:  Sun Jun 22, 2008 4:32 pm
Size:  701 bytes
To:  "Greg Beaver" <greg@chiaraquartet.net>,"Marcus Boerger" 
<mail@marcus-boerger.de>
cc:  "internals" <internals@lists.php.net>


Hi Greg, all,

It seems we don't use the openssl extension API at all in ext/phar, just the
actual OpenSSL headers and libs. That means Phar with OpenSSL support can be
both built and run without ext/openssl being built at all, but requires
third-party libs (under Windows at least - ssleay32.dll and libeay32.dll) in
the same way that ext/openssl does.

I'm wondering if we shouldn't have a separate configuration option for
this - something like --enable-phar-ssl - rather than testing
for --with-openssl in the config line.

The chief advantage of this approach is that it doesn't matter whether
phar-ssl is built as shared or not, since the dependency is outside PHP.

Thoughts?

- Steph