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
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.
Would --with-openssl imply --enable-phar-ssl then? Sounds like a good
idea to me.
Martin
Hi Martin,
Would --with-openssl imply --enable-phar-ssl then? Sounds like a good
idea to me.
It certainly could... but what about distro builds?
- Steph
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?
--with-openssl is used by ext/openssl and will continue to be used
like it is now (I'm thinking of adding --with-openssl-dir for
consistency but that's all).
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"?
About the SSL ibraries on windows, they are always distributed as dll
in the PHP releases.
Cheers,
Pierre
Hi Pierre,
--with-openssl is used by ext/openssl and will continue to be used
like it is now (I'm thinking of adding --with-openssl-dir for
consistency but that's all).
This has absolutely no bearing on my question. Perhaps I expressed myself
badly.
- Steph
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.
- Steph
You're missing that Windows users don't tend to roll their own PHP. They
tend to pick and choose their extensions.
I still miss your point here, I was only talking about bins releases
for windows.
At present, if someone were to load php_openssl.dll from PECL
From PECL? it is in our releases and will remain in our releases,
just like all extensions.
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.
--enable-phar-ssl and do (not tested but it gives the idea):
if (PHP_PHAR_SSL == "yes") {
ADD_EXTENSION_DEP("phar", "openssl", true);
} else {
if (PHP_PHAR_SSL != "no") { // be sure to do not enable it when
--disable-phar-ssl is used
ADD_EXTENSION_DEP("phar", "openssl", true);
}
}
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.
it is enabled by default and it is built shared as almost all
extensions. The rest is a matter of documenting it, like almost all
extensions, "please enable phar and openssl (if available) in your
php.ini".
Cheers,
Pierre
Hey Pierre,
--enable-phar-ssl and do (not tested but it gives the idea):
if (PHP_PHAR_SSL == "yes") {
ADD_EXTENSION_DEP("phar", "openssl", true);
} else {
....
Erm... no, you've definitely missed the point. ADD_EXTENSION_DEP() only
works in one of the four possible scenarios, and that one is when both phar
and openssl are built as static. It will break the build for all other
combinations.
There are two ways to get phar to build alongside openssl in the other three
scenarios: You can add an explicit dependency on the underlying OpenSSL
libs, or you can ignore the relationship completely. If you do the former,
the related functionality in phar does not actually require ext/openssl to
be loaded. If you do the latter, it does.
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.it is enabled by default
'enabled by default' usually implies 'built-in'.
and it is built shared as almost all
extensions. The rest is a matter of documenting it, like almost all
extensions, "please enable phar and openssl (if available) in your
php.ini".
We can sign and verify OpenSSL signatures without ext/openssl if we have the
library dependency. In other words, this (with the module checks in util.c
commented out) works fine:
$p = new Phar('sigtest.phar');
$p['a.txt'] = 'whatever';
$pkey = file_get_contents(dirname(FILE) . '/files/private.pem');
$p->setSignatureAlgorithm(Phar::OPENSSL, $pkey);
var_dump($p->getSignature());
output:
array(2) {
["hash"]=>
string(256)
"A408120F3D5EAD7FAFB891FD6D3DB8A35A68741A550009F685517BA05086C35919730B81DAC06408082E0363F7DC25B7F51AFA9D3B598ECBE42D961296A201EE4ECD343BB707CD3C7F8E788C812477343644516591470F885A712326058B8A46DA769DADA8CDBC30C4DF47DD0A13C0A9AEF9FE4E62300EBD79C53215B415999E"
["hash_type"]=>
string(7) "OpenSSL"
}
and so does this:
$p = new Phar(dirname(FILE) . '/files/openssl.phar');
$sig = $p->getSignature();
var_dump($sig);
output:
array(2) {
["hash"]=>
string(256)
"1614A127C7DEB5405D175FFB2D20031E5E78A1FB993D8A854862940F28D0BB3207E1722F424DC731131BFC082D4B8A2F7B053E1B4405400F4D6D6AA0BBF2E45B3028CC6C01C9C361DC1A4B65D3932B075CB33948AF0B147076EBA3B13010B27DC64D7DAD340B2E399CA7848BB59434C1BC55B5B062F134A6943202F8FF63BD7B"
["hash_type"]=>
string(7) "OpenSSL"
}
Currently my config.w32 for PECL looks like this:
ARG_ENABLE("phar", "enable phar support", "no");
ARG_ENABLE("phar-ssl", "enable phar with OpenSSL support", "no");
if (PHP_PHAR_SSL != "no") {
PHP_PHAR = PHP_PHAR_SSL;
PHP_PHAR_SHARED = PHP_PHAR_SSL_SHARED;
}
if (PHP_PHAR != "no") {
EXTENSION("phar", "dirstream.c func_interceptors.c phar.c phar_object.c
phar_path_check.c stream.c tar.c util.c zip.c");
if (PHP_PHAR_SHARED) {
ADD_FLAG("CFLAGS_PHAR", "/D COMPILE_DL_PHAR ");
}
if (PHP_PHAR_SSL != "no" || PHP_OPENSSL != "no") {
ADD_FLAG("LIBS_PHAR", "libeay32.lib ssleay32.lib");
AC_DEFINE('PHAR_HAVE_OPENSSL', 1);
}
ADD_EXTENSION_DEP('phar', 'spl', true);
}
The config.w32 for core needs more thought because phar is enabled
statically by default there. It might be that Greg's is the only solution in
that set-up (i.e. phar only has internal openssl support if ext/openssl is
also statically linked, and the only way to get openssl support in phar
otherwise is to load php_openssl.dll.)
- Steph
Hi,
We can sign and verify OpenSSL signatures without ext/openssl if we have the
library dependency. In other words, this (with the module checks in util.c
commented out) works fine:
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.
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.
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.
As testing has_xxx at runtime looks shiny and powerful, I don't think
it is worth the pain.
Cheers,
Pierre
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
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.
Yes, in config.w32 and config.m4. Either using ADD_EXTENSION_DEP or
ADD_LIBS if you use the library directly. phar works smoothly without
them, fine, that makes them optional deps. But they are still
dependencies.
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... :\
You know how a given feature is tested in phar?
PHAR_G(has_zlib) = zend_hash_exists(&module_registry, "zlib", sizeof("zlib"));
then:
if (!PHAR_G(has_zlib)) ...
--
Pierre
if (!PHAR_G(has_zlib)) ...
Pierre, you'd still need to test for them at runtime whether they were
listed as a soft dependency or not!
- Steph
if (!PHAR_G(has_zlib)) ...
Pierre, you'd still need to test for them at runtime whether they were
listed as a soft dependency or not!
No, not if they are not soft dependencies, this is what is done in 99%
of the php exts (from an user pov, it will be the same yes).
--
Pierre
Pierre Joye wrote:
As testing has_xxx at runtime looks shiny and powerful, I don't think
it is worth the pain.
What pain?
Greg
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:
- ext/phar built statically and ext/openssl built statically (in this
case, it uses openssl lib directly) - 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) - 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) - 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
Hi Greg,
I must be going crazy. Is there an actual problem that needs solving?
Yep, solved yesterday.
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?
No?
On windows, the user would have (by default) phar static and openssl
dynamic.
Only if they run PHP 5.3. Remember I'm still, piece by piece, putting
together a version for PECL/5.2 - and also remember that it's 50-50 whether
phar goes out as static or as shared even in 5.3.
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.
Not so simple. You have to put a weird file in a weird place for ext/openssl
to operate at all. The docs on that are appalling (everywhere), it took me
15 minutes to work out what was wrong with it... If you use phar-ssl you
don't have any of that kind of thing to worry about. If you have ext/openssl
installed you don't need to use phar-ssl.
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.
I still think Option 2 is wide open - i.e. get rid of the native openssl
calls in ext/phar and have openssl support only when ext/openssl is
available. If the performance gain isn't an issue then the only advantage of
having that code in phar is to avoid a mildly problematic ext/openssl setup.
- Steph
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?
You are not going crazy, I was asking the same in my very first reply.
The only thing I like to see in config.w32 (and config.m4 too if
possible) is the dependencies definition. As it has no impact at
runtime (as you explained), it can be used at configure and build time
to check than the right extension or libraries are used. Or at least,
to notify the user than running configure with --disable-all
--enable-phar is not enough to give bz2, zlib or ssl support.
Cheers,
Pierre
Pierre,
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?You are not going crazy, I was asking the same in my very first reply.
Odd, that. I have nothing in my ML archives mentioning this imaginary poor
confused user until Greg's post.
The only thing I like to see in config.w32 (and config.m4 too if
possible) is the dependencies definition. As it has no impact at
runtime (as you explained), it can be used at configure and build time
to check than the right extension or libraries are used. Or at least,
to notify the user than running configure with --disable-all
--enable-phar is not enough to give bz2, zlib or ssl support.
I think you're becoming very confused about the distinction between
developers and users. Most users running PHP under Windows do not build
their own copy of PHP. The rest of us don't need PEAR-type config output
styling etc, we can read standard configuration output thanks. --disable-all
is so rarely used under doze that until I fixed it last week, it hadn't ever
worked. In 5 years (more?) there was only one complaint - from Hector, who
was trying to roll his own PHP for distribution, which is discouraged. Even
nmake clean is reserved for distribution/snapshots builds, and we didn't
have an alternative for it in local builds until very recently. There just
aren't enough people working on PHP under Windows for these things to have
been a real problem. The ones that do, don't build PHP in the way you
anticipate here. The people that build PHP like that are *nix users.
PHP/Windows users use phpinfo() and php -m to find out what they have on
board. phpinfo() explains what is or isn't available in Phar and what is
needed to enable it. They don't need more than this. Are you really
suggesting that developers need more info than this because they're less
able to read than end users are?
Finally, as Greg has already tried to explain, in Phar the dependencies are
100% soft. Building phar alongside bz2 doesn't trigger bz2 functionality,
but loading bz2.so does. There's absolutely no association between the
configure line and the support offered. The one exception here is the
phar-ssl stuff I committed for Windows yesterday, which is fairly likely to
disappear altogether once Greg has had time to think it through properly
because it doesn't really make sense, given our normal context, to offer
built-in functionality in that way.
- Steph
Hi,
Please top to make easy problems an endless pain please. And stop to
mix every topics you can think about in every single discussions.
Also it would be nice if you get cooler and stop to harass me on every
single reply or commit, get a life, do something, whatever helps but
stop to harass me.
<snip>I think you're becoming very confused about the distinction between
developers and users. Most users running PHP under Windows do not build
their own copy of PHP. The rest of us don't need PEAR-type config
--
Pierre