Created attachment 717759 [details] build.log > In file included from /var/tmp/portage/dev-lang/php-8.0.7/work/sapis-build/cli/main/php.h:439, > from /var/tmp/portage/dev-lang/php-8.0.7/work/sapis-build/cli/ext/openssl/openssl.c:27: > /var/tmp/portage/dev-lang/php-8.0.7/work/sapis-build/cli/ext/openssl/openssl.c: In function ‘zm_startup_openssl’: > /var/tmp/portage/dev-lang/php-8.0.7/work/sapis-build/cli/ext/openssl/openssl.c:1224:51: error: ‘RSA_SSLV23_PADDING’ undeclared (first use in this function); did you mean ‘RSA_NO_PADDING’? > 1224 | REGISTER_LONG_CONSTANT("OPENSSL_SSLV23_PADDING", RSA_SSLV23_PADDING, CONST_CS|CONST_PERSISTENT); > | ^~~~~~~~~~~~~~~~~~ > /var/tmp/portage/dev-lang/php-8.0.7/work/sapis-build/cli/Zend/zend_constants.h:50:105: note: in definition of macro ‘REGISTER_LONG_CONSTANT’ > 50 | #define REGISTER_LONG_CONSTANT(name, lval, flags) zend_register_long_constant((name), sizeof(name)-1, (lval), (flags), module_number) > | ^~~~ > /var/tmp/portage/dev-lang/php-8.0.7/work/sapis-build/cli/ext/openssl/openssl.c:1224:51: note: each undeclared identifier is reported only once for each function it appears in > 1224 | REGISTER_LONG_CONSTANT("OPENSSL_SSLV23_PADDING", RSA_SSLV23_PADDING, CONST_CS|CONST_PERSISTENT); > | ^~~~~~~~~~~~~~~~~~ > /var/tmp/portage/dev-lang/php-8.0.7/work/sapis-build/cli/Zend/zend_constants.h:50:105: note: in definition of macro ‘REGISTER_LONG_CONSTANT’ > 50 | #define REGISTER_LONG_CONSTANT(name, lval, flags) zend_register_long_constant((name), sizeof(name)-1, (lval), (flags), module_number) > | ^~~~ > /var/tmp/portage/dev-lang/php-8.0.7/work/sapis-build/cli/ext/openssl/openssl.c: In function ‘php_openssl_generate_private_key’: > /var/tmp/portage/dev-lang/php-8.0.7/work/sapis-build/cli/ext/openssl/openssl.c:3687:7: warning: ‘RSA_new’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] > 3687 | rsaparam = RSA_new(); > | ^~~~~~~~ PHP 7.x has same failure.
Hi. See also https://bugs.php.net/bug.php?id=81278
*** Bug 805167 has been marked as a duplicate of this bug. ***
A fix landed upstream, and is included in dev-lang/php:8.1. Older versions are still broken.
Do we have any chance to get patched somehow php7.4 at least?
(In reply to Conrad Kostecki from comment #4) > Do we have any chance to get patched somehow php7.4 at least? Upstream discussions indicated that they have no intention of backporting the fix to older releases out of concern for introducing bugs in stable releases.
Aim is to unmask OpenSSL 3 by end of year.
(In reply to Sam James from comment #6) > Aim is to unmask OpenSSL 3 by end of year. php-7.4 loses security support in 9 days, which sort of solves that problem. For php-8.0, we should probably just add an upper bound on the dependency. Upstream WONTFIXed the request to backport: https://github.com/php/php-src/issues/9503
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dd1a44d939cae653057dd20dbad8b3440d8c7e41 commit dd1a44d939cae653057dd20dbad8b3440d8c7e41 Author: Brian Evans <grknight@gentoo.org> AuthorDate: 2022-11-20 03:18:47 +0000 Commit: Brian Evans <grknight@gentoo.org> CommitDate: 2022-11-20 03:18:47 +0000 dev-lang/php: Set max openssl version on 7.4 and 8.0 slots Only affects build time and forced rebuild in place catches installed versions Closes: https://bugs.gentoo.org/797676 Bug: https://github.com/php/php-src/issues/9503 Signed-off-by: Brian Evans <grknight@gentoo.org> dev-lang/php/php-7.4.33.ebuild | 2 +- dev-lang/php/php-8.0.25.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
(In reply to Michael Orlitzky from comment #7) > (In reply to Sam James from comment #6) > > Aim is to unmask OpenSSL 3 by end of year. > > php-7.4 loses security support in 9 days, which sort of solves that problem. > For php-8.0, we should probably just add an upper bound on the dependency. > Upstream WONTFIXed the request to backport: > > https://github.com/php/php-src/issues/9503 Sounds good (late reply ;)) and thanks grknight for handling it. It's better than nothing and it stops folks accidentally upgrading and getting into a death loop.
In fact this patch is enough to build PHP-8.0 with openssl-3.0.x: https://github.com/php/php-src/compare/PHP-8.0...bukka:openssl_30
(In reply to Hasso Tepper from comment #10) > In fact this patch is enough to build PHP-8.0 with openssl-3.0.x: > > https://github.com/php/php-src/compare/PHP-8.0...bukka:openssl_30 True, but there have been other bug fixes for openssl-3.x compatibility since that branch was authored, and many commits to the openssl extension more generally that might have different behavior with v3.x but don't mention it in their commit messages. We're not experts on the PHP/OpenSSL code, so it would be hard to know what is important to backport. And especially for a security-sensitive extension, we would rather avoid risking a repeat of the famous Debian bug: https://jblevins.org/log/ssh-vulnkey If it ever becomes a major problem we can reconsider, but chances are, php-8.0 won't be the last consumer of openssl-1.x. (It's also not that bad of an upgrade to 8.1 if you've made it to 8.0 already.)
(In reply to Michael Orlitzky from comment #11) > (In reply to Hasso Tepper from comment #10) > > In fact this patch is enough to build PHP-8.0 with openssl-3.0.x: > > > > https://github.com/php/php-src/compare/PHP-8.0...bukka:openssl_30 > > True, but there have been other bug fixes for openssl-3.x compatibility > since that branch was authored, and many commits to the openssl extension > more generally that might have different behavior with v3.x but don't > mention it in their commit messages. > > We're not experts on the PHP/OpenSSL code, so it would be hard to know what > is important to backport. And especially for a security-sensitive extension, > we would rather avoid risking a repeat of the famous Debian bug: > https://jblevins.org/log/ssh-vulnkey > > If it ever becomes a major problem we can reconsider, but chances are, > php-8.0 won't be the last consumer of openssl-1.x. (It's also not that bad > of an upgrade to 8.1 if you've made it to 8.0 already.) OpenSSL 1.1* will be EOL in September. So, we have two choices (more or less): 1. Switch to purely php8.1 as default now (or perhaps php8.0 and php8.1 for a bit, then 8.1, but still in pretty short order) 2. Figure out how other distros who still ship <8.1 have handled it. For Ruby, we took the equivalent of option 1.
(In reply to Sam James from comment #12) > > OpenSSL 1.1* will be EOL in September. So, we have two choices (more or > less): > 1. Switch to purely php8.1 as default now (or perhaps php8.0 and php8.1 for > a bit, then 8.1, but still in pretty short order) > 2. Figure out how other distros who still ship <8.1 have handled it. > > For Ruby, we took the equivalent of option 1. The PHP project is now empty, and I don't have the bandwidth to work miracles myself, so if it comes down to it, feel free to mask any PHP revdeps of openssl-1.1 along with it. We have 8.1 stable now so the situation isn't so bad. The real headache is the 7.4 -> 8.0 upgrade I think, and everyone has had plenty of time for that. Afterwards, going from 8.0 to 8.1 should be relatively easy. Regardless, there's only so much we can do.
Thanks for the quick reply mjo! Totally understandable and appreciate what you're saying (in particular the licence to do what is needed). I've opened a PR to try switch us to newer defaults.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cf60cddb73476fb9a5c99bd17d69899a134fed40 commit cf60cddb73476fb9a5c99bd17d69899a134fed40 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-06-22 23:06:22 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-06-23 21:41:33 +0000 profiles/base: change to PHP_TARGETS="php8-1" Needed for OpenSSL 3. As noted in the PR, php7-4 is EOL and 8-0 is security-support only, so let's zoom ahead to solely 8-1. Bug: https://bugs.gentoo.org/797676 Closes: https://github.com/gentoo/gentoo/pull/31579 Signed-off-by: Sam James <sam@gentoo.org> profiles/base/make.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
