FAQ
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

Search Discussions

  • Martin Jansen at Jun 22, 2008 at 8:35 pm

    On Sun, Jun 22, 2008 at 10:32 PM, Steph Fox wrote:
    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
  • Steph Fox at Jun 23, 2008 at 11:11 am
    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
  • Pierre Joye at Jun 22, 2008 at 8:41 pm

    On Sun, Jun 22, 2008 at 10:32 PM, Steph Fox wrote:

    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,
  • Steph Fox at Jun 23, 2008 at 10:21 am
    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
  • Steph Fox at Jun 23, 2008 at 11:27 am
    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
  • Pierre Joye at Jun 23, 2008 at 11:43 am

    On Mon, Jun 23, 2008 at 1:28 PM, Steph Fox wrote:


    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,
  • Steph Fox at Jun 23, 2008 at 2:37 pm
    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
  • Pierre Joye at Jun 23, 2008 at 3:06 pm
    Hi,
    On Mon, Jun 23, 2008 at 4:38 PM, Steph Fox wrote:

    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,
  • Steph Fox at Jun 23, 2008 at 4:05 pm
    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
  • Pierre Joye at Jun 23, 2008 at 5:13 pm

    On Mon, Jun 23, 2008 at 5:44 PM, Steph Fox wrote:

    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)) ...
  • Steph Fox at Jun 23, 2008 at 5:19 pm
    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
  • Pierre Joye at Jun 23, 2008 at 5:21 pm

    On Mon, Jun 23, 2008 at 7:21 PM, Steph Fox wrote:
    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).
  • Greg Beaver at Jun 24, 2008 at 12:58 am

    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
  • Greg Beaver at Jun 24, 2008 at 12:46 am

    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
  • Steph Fox at Jun 24, 2008 at 9:26 am
    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
  • Pierre Joye at Jun 24, 2008 at 9:57 am

    On Tue, Jun 24, 2008 at 2:46 AM, Greg Beaver wrote:

    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,
  • Steph Fox at Jun 24, 2008 at 10:48 am
    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
  • Pierre Joye at Jun 24, 2008 at 11:03 am
    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.
    On Tue, Jun 24, 2008 at 12:49 PM, Steph Fox wrote:

    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
    <snip>
  • Greg at Jun 22, 2008 at 9:51 pm
    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
  • Pierre Joye at Jun 22, 2008 at 11:25 pm
    hi Greg,
    On Sun, Jun 22, 2008 at 10:50 PM, wrote:
    Hi,

    Steph, look more closely, the libraries are only used if openssl is built statically. Otherwise, phar directly calls openssl_verify or openssl_sign.
    By the way, any reason why phar is built statically by default?
  • Greg Beaver at Jun 23, 2008 at 3:32 am

    Pierre Joye wrote:
    hi Greg,
    On Sun, Jun 22, 2008 at 10:50 PM, wrote:

    Hi,

    Steph, look more closely, the libraries are only used if openssl is built statically. Otherwise, phar directly calls openssl_verify or openssl_sign.
    By the way, any reason why phar is built statically by default?
    Hi,

    phar is enabled by default in order to fully test it prior to the first
    RC. I proposed[1] that a final vote be undertaken just prior to the
    5.3RC1 release on phar's ultimate fate.

    Greg
    [1] http://www.mail-archive.com/internals@lists.php.net/msg35938.html
  • Pierre Joye at Jun 23, 2008 at 6:14 am
    Hi Greg,
    On Mon, Jun 23, 2008 at 5:32 AM, Greg Beaver wrote:

    phar is enabled by default in order to fully test it prior to the first RC.
    I proposed[1] that a final vote be undertaken just prior to the 5.3RC1
    release on phar's ultimate fate.
    You misread my question. Why is it _statically_ linked by default
    (instead of shared)?

    Cheers,
  • Steph Fox at Jun 23, 2008 at 11:08 am
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJun 22, '08 at 8:31p
activeJun 24, '08 at 11:03a
posts24
users4
websitephp.net

People

Translate

site design / logo © 2022 Grokbase