Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125281
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: [PHP-DEV] Native SSL support in Phar extension
In-Reply-To: <CAAfnsFUP3OoAYSMe2NCo=SFUNtLQU6DiWddhHaXf5xY09GTr5Q@mail.gmail.com>
Date: Mon, 26 Aug 2024 15:05:11 -0300
Cc: Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8664467A-D602-48B6-96CA-D6FAD4488F14@cmpct.info>
References: <CAAfnsFUP3OoAYSMe2NCo=SFUNtLQU6DiWddhHaXf5xY09GTr5Q@mail.gmail.com>
To: Peter Kokot <petk@php.net>
From: calvin@cmpct.info (Calvin Buckley)

On Aug 26, 2024, at 1:23=E2=80=AFPM, Peter Kokot <petk@php.net> wrote:
>=20
> Hello,
>=20
> There came up another idea/issue about the Phar extension and its
> native SSL support.
>=20
> As you might know or not, when building PHP:
>=20
> ./configure --with-openssl --enable-phar
>=20
> the Phar extension will get so-called native SSL enabled through
> OpenSSL directly. However, when built like this:
>=20
> ./configure --with-openssl=3Dshared --enable-phar=3Dshared
> or
> ./configure --with-openssl=3Dshared --enable-phar
>=20
> 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.
>=20
> 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.
>=20
> 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
>=20
> 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
>=20
> 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.
>=20
> 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/=