Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38558
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <486043CF.6030103@chiaraquartet.net>
Date: Mon, 23 Jun 2008 19:46:07 -0500
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Steph Fox <steph@phparch.com>
CC: Pierre Joye <pierre.php@gmail.com>, 
 Marcus Boerger <mail@marcus-boerger.de>,
 internals <internals@lists.php.net>
References: <028a01c8d4a7$18dd4380$4401a8c0@foxbox> <fe05d1540806221341o6ebd3c21v2506d92903778bbe@mail.gmail.com> <008601c8d524$41184e30$4401a8c0@foxbox>
In-Reply-To: <008601c8d524$41184e30$4401a8c0@foxbox>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] OpenSSL and Phar
From: greg@chiaraquartet.net (Greg Beaver)

Steph Fox wrote:
>
> Hi Pierre,
>
> OK, I got back to the rest of your email now (caffeine always helps, eh).
>
>> I'm not sure it makes sense to have the ssl optional features enabled
>> but not ext/openssl. Or to say it better, I don't see the gain. What
>> is the gain besides being able to say: "heh you can use the ssl
>> features without having ext/openssl but you need the libs anyway"?
>
> You're missing that Windows users don't tend to roll their own PHP. 
> They tend to pick and choose their extensions.
>
> At present, if someone were to load php_openssl.dll from PECL 
> alongside built-in Phar in 5.3 they'd probably wonder why it wasn't 
> working as advertised. If the dependency were made explicit in Phar, 
> the only thing ext/openssl would be needed for is explicit openssl 
> calls - which is far easier to understand.
>
> FWIW, I think having Phar built-in is actually a disadvantage when it 
> comes to this kind of thing. ext/openssl isn't enabled by default and 
> is only available as shared to the vast majority of Windows users.
Hi,

I must be going crazy.  Is there an actual problem that needs solving?  
You're saying that a user who improperly installs php_openssl.dll (i.e. 
does not follow instructions and set up ssleay.dll and libeay.dll) 
should magically be able to use phar with openssl?  Why?

ext/phar uses openssl, and thus works in all of these situations:

1) ext/phar built statically and ext/openssl built statically (in this 
case, it uses openssl lib directly)
2) ext/phar built statically and ext/openssl built dynamically (in this 
case, it checks for openssl dynamically at runtime, and directly calls 
openssl_sign or openssl_verify)
3) ext/phar built dynamically and ext/openssl built dynamically (in this 
case, it checks for openssl dynamically at runtime, and directly calls 
openssl_sign or openssl_verify)
4) ext/phar built dynamically and ext/openssl built statically (in this 
case, it checks for openssl dynamically at runtime, and directly calls 
openssl_sign or openssl_verify)

#1 is the fastest alternative, but the difference is insignificant for 
any application of significant size, as the extra code in #2, 3, and 4 
is only called once.

On windows, the user would have (by default) phar static and openssl 
dynamic.  To enable openssl signing, you simply need to enable 
php_openssl.dll, which means setting up a few dlls as described on the 
installation page for openssl.  Once done, phar then works great with 
openssl signatures.

Where is the problem?  Any user who has control over their windows build 
and wishes to compile in openssl statically for maximum performance may 
do so, but I would challenge any user trying to eke out such a small 
performance gain would be better served by using unix, where PHP is just 
plain faster no matter what.

Pierre: the difference between phar and other extensions is that phar 
has the ability to handle all 4 of the above situations for bz2, zlib 
and openssl, whereas no other extensions possess this kind of true 
optional dependency handling.  So, I fail to see how the use of runtime 
extension detection is anything other than a really great idea that 
solves the problem of optional dependency handling regardless of 
static/dynamic compilation.

Greg