SSL{,_CTX}_get_ex_new_index: expose CRYPTO-based definition to LibreSSL

[vishwin]

Not sure how this got missed until some linker errors I experienced now, but this has apparently been the case for time. Present in all currently supported LibreSSL versions.

[botovq]

I would like to understand the motivation for this change better. What is that linker error you run into?

I don't particularly like replacing the binding to an existing public symbol with a hand-written translation to rust just because for some reason OpenSSL decided to replace said symbol with a preprocessor macro that rust doesn't understand.

[vishwin]

error: linking with `cc` failed: exit status: 1
  |
  = note:  "cc" "-m64" "<1 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "<sysroot>/lib/rustlib/x86_64-unknown-freebsd/lib/libcompiler_builtins-*.rlib" "-Wl,-Bdynamic" "-lssl" "-lcrypto" "-lsqlite3" "-lnettle" "-lhogweed" "-lgmp" "-lrt" "-lutil" "-lexecinfo" "-lkvm" "-lmemstat" "-lkvm" "-lutil" "-lprocstat" "-lrt" "-ldevstat" "-lbz2" "-lexecinfo" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lrt" "-lutil" "-lexecinfo" "-lkvm" "-lmemstat" "-lkvm" "-lutil" "-lprocstat" "-lrt" "-ldevstat" "-L" "/wrkdirs/overlays/overlay/security/sequoia-sq/work/rustcHfXrre/raw-dylibs" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/usr/lib" "-L" "<sysroot>/lib" "-L" "<sysroot>/lib" "-L" "<sysroot>/lib" "-L" "<sysroot>/lib" "-L" "<sysroot>/lib" "-o" "/wrkdirs/overlays/overlay/security/sequoia-sq/work/target/release/deps/sq-fa25542a8117f5aa" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs" "-Wl,-rpath,<sysroot>/lib"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: ld: error: undefined symbol: SSL_get_ex_new_index
          >>> referenced by mod.rs:4372 (src/ssl/mod.rs:4372)
          >>>               /wrkdirs/overlays/overlay/security/sequoia-sq/work/target/release/deps/sq-fa25542a8117f5aa.sq.19bbb7c83867ca2a-cgu.0.rcgu.o:(once_cell::imp::OnceCell$LT$T$GT$::initialize::_$u7b$$u7b$closure$u7d$$u7d$::h9d0ab18e7a25b679)
          >>> referenced by mod.rs:4366 (src/ssl/mod.rs:4366)
          >>>               /wrkdirs/overlays/overlay/security/sequoia-sq/work/target/release/deps/sq-fa25542a8117f5aa.sq.19bbb7c83867ca2a-cgu.0.rcgu.o:(core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h657f9203f69ea9d5)
          >>> referenced by mod.rs:4366 (src/ssl/mod.rs:4366)
          >>>               /wrkdirs/overlays/overlay/security/sequoia-sq/work/target/release/deps/sq-fa25542a8117f5aa.sq.19bbb7c83867ca2a-cgu.0.rcgu.o:(std::sync::poison::once::Once::call_once::_$u7b$$u7b$closure$u7d$$u7d$::hf02d0d42057baf2e)

For some reason this was not a problem in LibreSSL 4.1 and corresponding previous crate versions, particularly openssl-0.10.72 and openssl-sys-0.9.108. Also doesn't seem to be a problem with other crates/programs under LibreSSL 4.2.0 and corresponding current crate versions. There are two more linker errors on different symbols during this run but they are out of scope of this discussion. Symbol clashing is also a possibility.

[botovq]

Ok, thanks, that gives me some pointers. I'm not necessarily opposed to merging this (it will also reduce the still rampant libressl special casing in these crates), but I'd like to see if I can figure out what's going on. Will get back to you tomorrow.

[botovq]

I haven't managed to reproduce this. On OpenBSD 7.8 with libressl 4.2, rust 1.90, sequoia-sq 1.3.1 builds just fine after running cargo update openssl-sys openssl (almost - it needs a workaround for a cfg bug in openpgp-cert-d).

Thus, I'm still not convinced this PR is the right thing to do.