On Aug 26, 2024, at 1:23 PM, Peter Kokot <p...@php.net> wrote: > > Hello, > > There came up another idea/issue about the Phar extension and its > native SSL support. > > As you might know or not, when building PHP: > > ./configure --with-openssl --enable-phar > > the Phar extension will get so-called native SSL enabled through > OpenSSL directly. However, when built like this: > > ./configure --with-openssl=shared --enable-phar=shared > or > ./configure --with-openssl=shared --enable-phar > > the SSL support will depend on whether the ext/openssl is loaded and > enabled during PHP runtime. SSL support in both cases is done with > different pieces of code (one is using ext/openssl functions and the > other one - native SSL - is using OpenSSL calls directly). Also in > phpinfo output there is a bit of different info given based on the SSL > type. > > On Windows there is also a slight inconsistency at the moment where > there is obsolete --enable-phar-native-ssl configure option available > which is using missing libeay32 library. > > My first understanding was that native SSL is "better" as it uses > OpenSSL directly but it turned out that the code is outdated: > https://github.com/php/php-src/pull/14578 > > So, a new suggestion here is to remove the native SSL support in phar > extension in favor of using a PHP openssl extension's API (or better > call it function calls for the time being): > https://github.com/php/php-src/pull/15574 > > This would make the SSL support in phar more consistent because now > people aren't even aware of this. For example, on Alpine Linux default > packages there is openssl extension used in phar extension and on > Ubuntu's default packages there is this native SSL used. > > Does anyone see any issues with removing the native SSL support in > Phar extension? Let me know. Ideally we would remove it in PHP 8.4 > otherwise in the version after that...
Extensions referencing other extensions' functions (beyond things mediated by the PHP runtime like streams) can be tricky depending on the dynamic linking story. Dynamic linkers that pull from a general symbol slurry (your typical ld.so for instance) don't have a problem with it, but some platforms have more strict linkage, like Windows. IIRC, things like PDO are built into the PHP executable/library for this reason. I know AIX can actually do it both ways; I used to build the ld.so style way (they call it "runtime linking"), but it turns out that causes problems with different versions of symbols (i.e. OpenSSL 1.1 and 3.0 in same address space), so I had to switch to building it with the other dynamic linking option, which means I have to make the same build compromises as on Windows. As such, it might be a bit tricky for people on Windows/AIX; the easiest solution if PHAR is using the openssl extension's symbols would be to not build the openssl extension as shared. (Sorry for the impromptu lesson on dynamic linking; it's complex, ugly, and I still don't fully understand the vagaries myself. If you want more details, I can bury my head in the documentation again. Korrine Adler has an decent summary of the situation here [1].) [1]: https://kadler.io/blog/2024-08-12-openssl3-migration/
