Hi I just encountered that php-7.2.16 fails to start up (through apache2 and cli) when the sodium USEflag was used for it, but dev-libs/libsodium-1.0.16-r2 was built with the minimal USEflag. # php7.2 php7.2: symbol lookup error: php7.2: undefined symbol: crypto_pwhash_scryptsalsa208sha256_memlimit_interactive
(In reply to Andreas Schürch from comment #0) > Hi > I just encountered that php-7.2.16 fails to start up (through apache2 and > cli) when the sodium USEflag was used for it, but > dev-libs/libsodium-1.0.16-r2 was built with the minimal USEflag. > > # php7.2 > php7.2: symbol lookup error: php7.2: undefined symbol: > crypto_pwhash_scryptsalsa208sha256_memlimit_interactive Reading through the php sources, it requires that the minimal USE flag be consistent when libsodium is built and php is built after. PHP will build both ways, but the runtime will choke if that USE is flipped and libsodium rebuilt without php being rebuilt. It still may make sense to force that flag off to get a positive result.
Specifically once PHP is built: libsodium[minimal] -> libsodium[-minimal] == PHP continues without new functions libsodium[-minimal] -> libsodium[minimal] == PHP fails at runtime without a rebuild
Ah, You are right! I got into that situation as I built php in a ROOT= environment with [minimal] set, while the system libsodium was built without it! I don't know if such a case could be caught!?
This is just the "automagic dependency" problem if you're willing to abstract a bit. PHP has a pretty good build system so this could be improved upstream. Instead of inferring what features are available at build time with e.g. #if defined(crypto_pwhash_scryptsalsa208sha256_SALTBYTES) ZEND_FUNCTION(sodium_crypto_pwhash_scryptsalsa208sha256_str_verify); #endif it should instead require & use a consistent (but perhaps configurable) set of functions. However, the end result of that would be the same: PHP would require more functions to be present at build time, so we would wind up forcing USE="-minimal" on sodium. So maybe we should just do that and not invent more work.
(In reply to Michael Orlitzky from comment #4) > However, the end result of that would be the same: PHP would require more > functions to be present at build time, so we would wind up forcing > USE="-minimal" on sodium. So maybe we should just do that and not invent > more work. Let's do that for now?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=817446c1e669f2c20e017dff61428542b9e3967c commit 817446c1e669f2c20e017dff61428542b9e3967c Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2021-07-01 21:04:37 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2021-07-01 22:10:40 +0000 dev-lang/php: new point releases to fix CVE-2021-2170[45]. We also require libsodium[-minimal] in the new ebuilds, to avoid problems (bug 686602) with the build-time feature detection in PHP. This is unrelated to the security fixes. Closes: https://bugs.gentoo.org/686602 Package-Manager: Portage-3.0.20, Repoman-3.0.2 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> dev-lang/php/Manifest | 5 +- dev-lang/php/php-7.3.29.ebuild | 758 +++++++++++++++++++++ .../php/{php-7.4.20.ebuild => php-7.4.21.ebuild} | 2 +- .../php/{php-8.0.7.ebuild => php-8.0.8.ebuild} | 2 +- 4 files changed, 763 insertions(+), 4 deletions(-)
