Hi all,
I've mentioned this already in a pull request[1], but figure this should
be discussed on the mailing list. Quoting myself from that PR:
| PHP 8.4 is supposed to be supported until 31st Dec 2028, but OpenSSL
| 3.0 will only be supported until 7th September 2026. This might even
| be an issue for PHP 8.3. Unfortunately, even OpenSSL 3.3 support ends
| on 9th April 2026 (thus even earlier than 3.0), but we likely need to
| update to more recent OpenSSL minor versions.
Jakub mentioned in that PR that we may want to wait for OpenSSL 3.4.0
which is scheduled for GA in October, and likely is supported one year
longer as OpenSSL 3.3.0. I think that makes sense (particularly since
OpenSSL 3.4.0-alpha1 has been released today, and I have not detected
any serious issues with it when building nor when running the test
suite; there is a very minor issue regarding the path of the default
cert area which now has a trailing backslash appended[2], but that
doesn't really matter and might be "fixed", here or there).
I'm still not happy considering that this would still leave more than
one year of lacking upstream support, where our Windows builds might
need to be fixed with some publicly available patches, in case there are
any security vulnerabilites (I'm presuming that the PHP project will not
afford a support contract; it seems these don't even apply to Open
Source downstream consumers).
So I wonder about the stability of OpenSSL minor versions nowadays, and
whether we want to update to a new minor version during the lifecycle of
a PHP minor release. For instance regarding PHP 8.3, we may consider
updating OpenSSL to 3.4 roughly in a year, when PHP 8.3 has still actve
support for about four months, so we could still react to issues with
that update.
So one question is whether we should ship OpenSSL 3.4.0-alpha1 for PHP
8.4.0beta5, or to postpone that a bit.
And the other question is whether we are generally fine with updating to
newer OpenSSL versions during the lifecycle of a minor PHP release
(presuming that there are no BC issues, of course).
Thoughts?
[1] https://github.com/php/php-src/pull/15713
[2]
https://github.com/openssl/openssl/blob/8af4c02ea952ca387691c4a077c260ba045fe285/crypto/x509/x509_def.c#L52
Christoph
"Christoph M. Becker" in php.internals (Thu, 5 Sep 2024 19:19:45 +0200):
I'm still not happy considering that this would still leave more than
one year of lacking upstream support, where our Windows builds might
need to be fixed with some publicly available patches, in case there are
any security vulnerabilites (I'm presuming that the PHP project will not
afford a support contract; it seems these don't even apply to Open
Source downstream consumers).So I wonder about the stability of OpenSSL minor versions nowadays, and
whether we want to update to a new minor version during the lifecycle of
a PHP minor release. For instance regarding PHP 8.3, we may consider
updating OpenSSL to 3.4 roughly in a year, when PHP 8.3 has still actve
support for about four months, so we could still react to issues with
that update.
OpenSSL 3.5 has been marked as LTS now and supported up until 2030-04-08.
https://openssl-library.org/policies/releasestrat/index.html
This might be a good time to update OpenSSL to 3.5.
OpenSSL 3.5.2 has been released today. Could we release PHP 8.5 with
OpenSSL 3.5.2 and implement this change before the feature freeze?
Jan
OpenSSL 3.5 has been marked as LTS now and supported up until 2030-04-08.
https://openssl-library.org/policies/releasestrat/index.html
This might be a good time to update OpenSSL to 3.5.
OpenSSL 3.5.2 has been released today. Could we release PHP 8.5 with
OpenSSL 3.5.2 and implement this change before the feature freeze?
I think we should (try to) upgrade to OpenSSL 3.5. I don't think that
feature freeze would be the deadline – after all, it's not really a new
feature, but rather an upgrade of an external library.
Christoph