Re: Missing symbol under tox in openssl stuff

On 28-2-2020 13:59, kefu chai wrote: That file does (no longer) exist in my /usr/local... I checked by looking in the ports makefile, which registers the defaults. And you can check this when running make config, it'll also tell you that SSLv3 is off. What I do find in /usr/local/include/openssl is: /usr/local/include/openssl/ssl.h:DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *SSLv3_method(void)) /* SSLv3 */ /usr/local/include/openssl/ssl.h:DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *SSLv3_server_method(void)) /usr/local/include/openssl/ssl.h:DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *SSLv3_client_method(void)) And the openssl in base is 1.1.0, and in ports is 1.1.1 so in both it should be deprecated.... But in the ports Makefile it is not default on: OPTIONS_DEFAULT=ASM ASYNC CT GOST DES EC MAN3 MD4 NEXTPROTONEG RC2 RC4 \ RMD160 SCTP SHARED SSE2 THREADS TLS1 TLS1_1 TLS1_2 Now this issue comes in a few flavours: Currently this only breaks in master, when with run-tox-mgr. This I can fix on by jenkins builder by manually installing a libcrypto that does take SSLv3. As long as the ports I make do not include cephadm, things will be fine. I still have not finished all the preparations for the ceph15 port. Ceph14-14.2.7 has just been submitted. So that will oke as long as nothing is being backported. Once that happens those versions will also suffer. Question is what happens when I release a package with cephadm in it which requires py-cryptography? As long as the FreeBSD port of that also does not need SSLv3 we're oke. Which will be since there is no tox involved. So for this it is only a problem when tox does not install the FreeBSD py-cryptography port but tries to fix it by itself. Hence my question if it would be sensible to get virtualenv/tox/pip/.... to prefer FreeBSD ports first. Or maybe even get src/tools/setup-virtualenv.sh or src/script/run_tox.sh to install if first before tox installs even more things (using py3??). Would that make sense? Now for something totally different with openssl versions: I have a similar problem of incompatible crypto I think when building my bhyve/rbd-device plugin where as things can get incompatible due to: src/common/ceph_crypto.h: namespace ceph::crypto::ssl { # if OPENSSL_VERSION_NUMBER < 0x10100000L And that if I try to run my plugin with a librados which is compiled on a platform with openssl < 0x10100000L it will crash in HMAC routines. Took me a while to figure that out. But that is more a development issue and I'm running way too many different combinations of release of Ceph and FreeBSD. Perhaps it is possible to glue a const in like namespace ceph::crypto::ssl { ........... public: const int rados_uses_ssl_version = OPENSSL_VERSION_NUMBER; Such that it is possible to ERR-out with a decent errormessage if not all versions match??? But then this needs to be mapped to C-code also, to be workable. --WjW