The ebuild currently is using openssl? ( dev-libs/openssl:0=[sslv3=,static-libs?,${MULTILIB_USEDEP}] ) which forces an exact match. However, curl can be built without sslv3 support (which is the better option) against an openssl with sslv3 support (should this be needed for other use cases). A better choice would be openssl? ( dev-libs/openssl:0=[sslv3?,static-libs?,${MULTILIB_USEDEP}] ) which forces on sslv3 on openssl if it's enabled for curl, but ignores it otherwise.
This is likely related to 744934, but I felt a new bug is better than reopening the old one.
Unfortunately can't do that, it re-introduce the original automagic issue that this is meant to fix. # USE=sslv3 emerge -1 openssl # USE=-sslv3 emerge -1 curl (allowed due to sslv3?) # USE=-sslv3 emerge -1 openssl x86_64-pc-linux-gnu-gcc -o test test.c -lcurl /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libcurl.so: undefined reference to `SSLv3_client_method@OPENSSL_1_1_0' collect2: error: ld returned 1 exit status
Thanks for the explanation. For future reference: -sslv3 on curl does not do what one would expect. It does not *disable* sslv3 support in curl, as that is still autodetected from an OpenSSL with enables SSLv3 support. What Ionen describes is the situation where a user installs an OpenSSL with sslv3 useflag, builds curl against it, then disables sslv3 on OpenSSL. Portage has no way to understand that libcurl requires OpenSSL with SSLv3 support (as curl is build with -sslv3), and thus a rebuild failes to consider it. The proper solution would be to create a patch for curl that actually force-disables sslv3 support on top of the requested change.
Re-opening given getting user requests to find an alternate (working) solution for this, I'll leave decision up to the maintainer on what to do with this.
(In reply to Ionen Wolkens from comment #4) > Re-opening given getting user requests to find an alternate (working) > solution for this, I'll leave decision up to the maintainer on what to do > with this. The logic in the build system is convoluted, which is one of the reasons I went with a match with openssl.
These sslv3 issues may be more far reaching than just curl wget and curl built with -Wl,-z,now: $ wget wget: symbol lookup error: wget: undefined symbol: SSLv3_client_method, version OPENSSL_1_1_0 $ curl curl: symbol lookup error: /usr/lib64/libcurl.so.4: undefined symbol: SSLv3_client_method, version OPENSSL_1_1_0 Now I just lost both fetching tools.
WONTFIX: + This is irrelevant with openssl 3 + All versions of cURL for the last two years (almost to the day) refuse to do sslv3 connections + Blanket disabling sslv3 to prevent an unlikely issue from occurring is unpalatable; someone, somewhere, may want to enable it + I don't want to maintain a curl build system patch that won't be upstreamed + Just use a modern / decent TLS implementation
If curl does not accidentally use sslv3 just because the use flag is set, all is well and the base for the bug does not exist (any more).
