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...
