Support libressl built from git

[theoparis]

I have built libressl from https://github.com/libressl/portable but rust-openssl which is required by nushell does not seem to support the version number:

cargo:libressl_version_number=400000f
...
This crate is only compatible with OpenSSL (...) or LibreSSL through 3.9.x...

As a workaround I modified the build/main.rs file locally in ~/.cargo/registry to remove the panic macros and nushell compiled and ran just fine.

[alex]

In general we don't support a version of LibreSSL until its actually released, as they may make changes to the API or ABI.

[botovq]

I don't think there is a sane way for released versions of rust-openssl to support unreleased/future versions of libressl. It is almost guaranteed that there will be API or ABI breaks between any two stable libressl releases. Often times they will result in compilation failures, but it's not guaranteed. Patching a released version of rust-openssl this way is therefore somewhat dangerous.

rust-openssl's HEAD is generally ready for all changes in libressl/portable. So bleeding edge rust-openssl should be safe to use with bleeding edge libressl and a trick like the one described here may work:

https://github.com/openbsd/ports/blob/ef08b70fc36515dd8f41c4fdffe1dc8db7f0fd2c/security/rust-ring/pkg/README

This still requires you to patch since removing the check means that it has to be added before rust-openssl releases are cut if they happen before a libressl release. Maybe that would be acceptable, but it's up to the maintainers to decide.

[alex]

In general, I'm disinclined towards removing that check before a release, because we generally remove that check when we add the LibreSSL release to CI. We generally try to keep the rust-openssl codebase "release ready", so we can't simply remove the check, because then we couldn't release.

[botovq]

Yes, that's what I thought. By the way, the fact that libressl/portable cranked its version to 4.0 is directly related to the fact that there was a major ABI and API break last week-end (the shared library versions were bumped as well), so the check actually does what it is supposed to be doing.