# OpenSSL and Phar - Thread: https://externals.io/message/38517 - Original archive: https://news-web.php.net/php.internals/38517 - Started by Steph Fox on 2008-06-22T20:32:30+00:00 - Messages: 19 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #38517 — Steph Fox — 2008-06-22T20:32:30+00:00 URL: https://externals.io/message/38517#38517 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 --- ## #38518 — Martin Jansen — 2008-06-22T20:35:19+00:00 URL: https://externals.io/message/38517#38518 · In reply to: #38517 > 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 --- ## #38519 — Pierre Joye — 2008-06-22T20:41:55+00:00 URL: https://externals.io/message/38517#38519 · In reply to: #38517 > 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 http://blog.thepimp.net | http://www.libgd.org --- ## #38534 — Steph Fox — 2008-06-23T10:23:08+00:00 URL: https://externals.io/message/38517#38534 · In reply to: #38519 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 --- ## #38536 — Steph Fox — 2008-06-23T11:12:20+00:00 URL: https://externals.io/message/38517#38536 · In reply to: #38518 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 --- ## #38537 — Steph Fox — 2008-06-23T11:28:25+00:00 URL: https://externals.io/message/38517#38537 · In reply to: #38519 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 --- ## #38538 — Pierre Joye — 2008-06-23T11:43:12+00:00 URL: https://externals.io/message/38517#38538 · In reply to: #38537 > 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 http://blog.thepimp.net | http://www.libgd.org --- ## #38543 — Steph Fox — 2008-06-23T14:38:53+00:00 URL: https://externals.io/message/38517#38543 · In reply to: #38538 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. > > […] > > 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 --- ## #38544 — Pierre Joye — 2008-06-23T15:06:25+00:00 URL: https://externals.io/message/38517#38544 · In reply to: #38543 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 http://blog.thepimp.net | http://www.libgd.org --- ## #38546 — Steph Fox — 2008-06-23T15:44:37+00:00 URL: https://externals.io/message/38517#38546 · In reply to: #38544 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 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 --- ## #38548 — Pierre Joye — 2008-06-23T17:12:59+00:00 URL: https://externals.io/message/38517#38548 · In reply to: #38546 > > […] > > 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. > > […] > > 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 http://blog.thepimp.net | http://www.libgd.org --- ## #38549 — Steph Fox — 2008-06-23T17:21:03+00:00 URL: https://externals.io/message/38517#38549 · In reply to: #38548 > 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 --- ## #38550 — Pierre Joye — 2008-06-23T17:21:50+00:00 URL: https://externals.io/message/38517#38550 · In reply to: #38549 > > > […] > > 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 http://blog.thepimp.net | http://www.libgd.org --- ## #38558 — Greg Beaver — 2008-06-24T00:46:07+00:00 URL: https://externals.io/message/38517#38558 · In reply to: #38537 Steph Fox wrote: > > Hi Pierre, > > OK, I got back to the rest of your email now (caffeine always helps, eh). > > > […] > > 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 --- ## #38559 — Greg Beaver — 2008-06-24T00:58:23+00:00 URL: https://externals.io/message/38517#38559 · In reply to: #38544 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 --- ## #38567 — Steph Fox — 2008-06-24T09:28:11+00:00 URL: https://externals.io/message/38517#38567 · In reply to: #38558 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 --- ## #38568 — Pierre Joye — 2008-06-24T09:57:38+00:00 URL: https://externals.io/message/38517#38568 · In reply to: #38558 > 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 http://blog.thepimp.net | http://www.libgd.org --- ## #38569 — Steph Fox — 2008-06-24T10:49:31+00:00 URL: https://externals.io/message/38517#38569 · In reply to: #38568 Pierre, > > […] > > 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 --- ## #38570 — Pierre Joye — 2008-06-24T11:03:33+00:00 URL: https://externals.io/message/38517#38570 · In reply to: #38569 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. > 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 http://blog.thepimp.net | http://www.libgd.org