Update OpenSSL *minor* version on Windows?

php.internals

Christoph Becker

1 year ago
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

Jan Ehrhardt

1 year ago
"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

Christoph Becker

1 year ago
On 05.08.2025 at 15:49, Jan Ehrhardt wrote:
> 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