Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38546
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain phparch.com from 64.99.136.187 cause and error)
Message-ID: <01b401c8d548$0c0e1430$4401a8c0@foxbox>
Reply-To: "Steph Fox" <steph@phparch.com>
To: "Pierre Joye" <pierre.php@gmail.com>
Cc: "Greg Beaver" <greg@chiaraquartet.net>,
	"Marcus Boerger" <mail@marcus-boerger.de>,
	"internals" <internals@lists.php.net>
References: <028a01c8d4a7$18dd4380$4401a8c0@foxbox> <fe05d1540806221341o6ebd3c21v2506d92903778bbe@mail.gmail.com> <008601c8d524$41184e30$4401a8c0@foxbox> <fe05d1540806230443n2217de5bu65ad18f7ef332fb3@mail.gmail.com> <017401c8d53e$de2a9380$4401a8c0@foxbox> <fe05d1540806230806o583a576fk770f6d270922ee16@mail.gmail.com>
Date: Mon, 23 Jun 2008 16:44:37 +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: [PHP-DEV] OpenSSL and Phar
From: steph@phparch.com ("Steph Fox")


Pierre,

> I finally took a look at why phar is not built shared as all other
> extension. It seems to force it only to be able to be run with no dep
> but still uses them if they are lately added (given that phar is now
> built statically, that makes little sense). But in fact, it does have
> deps against ext/zlib, ext/bz2 and now ext/openssl.

It has *optional* dependencies on all three, yes. Not hard dependencies. 
Phar works fine without them, it's just you can't have bz2 compression 
without bz2 etc.

> You may want to use the library directly but as it will be easy and
> problemless for bz2 and zlib, it is going to be a pain for openssl.

Ah, now you understand the problem.

The thing is that direct use equates to "phar needs libeay32.dll". (Not the 
other one in my shared-build tests, not sure why.) Now, as you pointed out 
earlier, libeay32.dll is bundled with the Windows distro, so in itself that 
isn't a problem - people won't struggle to find it. But if phar's built-in, 
that gives PHP a hard third-party dependency by default, which is obviously 
not acceptable.

The way Greg's written it allows for the openssl extension to be a soft 
dependency. If it's not loaded, you just miss that part of Phar's 
functionality, and if you want the functionality you need to load 
php_openssl.dll. However, if you happen to have built openssl statically 
into PHP, you might as well use the underlying library directly, and 
currently under Linux that's exactly what happens. That's fine, but it's 
also a little odd, since it means the only time you don't use ext/openssl is 
when it's there <cough>

Now let's talk about use cases. The way OpenSSL is used in phar is very 
minor - just OpenSSL signature verification and creation from existing 
private keys. If you want to do any more than that you'd need to load 
php_openssl.dll anyway. But most people probably won't want to do any more 
than that. Also, if you want to run ext/openssl under Windows you need to 
set it up a working environment for it, and this isn't necessary if you just 
want to support OpenSSL signatures in ext/phar. So I think we need to offer 
the *option* of having a hard dependency on libeay32.dll, with the default 
being no dependency. In the config.w32 I posted earlier, the assumption is 
that anyone building --with-openssl won't find that hard dependency a 
problem, but I'm not sure this is a good idea, especially given that there's 
a perfectly good fallback solution.

The other thing we could do of course is throw out all that pure library 
code and only offer OpenSSL signature support when ext/openssl is loaded. 
That has the benefit of clarity at least.

> My main question now is why don't you actually reflect the (optional)
> dependencies? bz2 and zlib compression available will not be available
> if bz2 or zlib is not present, same for openssl.

What do you mean? In config.w32? No need. In phpinfo()? We already do, just 
haven't added the openssl part yet because the configuration's up in the 
air.

> As testing has_xxx at runtime looks shiny and powerful, I don't think
> it is worth the pain.

Sorry, I failed to parse that sentence... :\

Cheers,

- Steph

>
> Cheers,
> -- 
> Pierre
>
> http://blog.thepimp.net | http://www.libgd.org