Build with LibreSSL 3.8.2 fails

[Sp1l]

Subject of the issue

Building with LibreSSL 3.8.2 fails due to incompatible dependencies

Deployment environment

FreeBSD 14.0-RC4
clang 16.0.6
rust 1.73.0
LibreSSL 3.8.2

• vaultwarden version:
  1.30.0

• Install method:
  Build from source

• Clients used:
  not applicable

• Reverse proxy and version:

• MySQL/MariaDB or PostgreSQL version:

• Other relevant details:

Steps to reproduce

Build Vaultwarden on a system that uses LibreSSL 3.8.,2 (released 2023-11-02) for libcrypto and libssl>

Expected behaviour

...
       Fresh vaultwarden v1.0.0 (/wrkdirs/overlays/overlay/security/vaultwarden/work/vaultwarden-1.30.0)
    Finished release [optimized] target(s) in 0.11s

full build log

Actual behaviour

...
[openssl-sys 0.9.92] This crate is only compatible with OpenSSL (version 1.0.1 through 1.1.1, or 3.0.0), or LibreSSL 2.5
[openssl-sys 0.9.92] through 3.8.0, but a different version of OpenSSL was found. The build is now aborting
[openssl-sys 0.9.92] due to this version mismatch.
...
error: failed to run custom build command for `openssl-sys v0.9.92`
note: To improve backtraces for build dependencies, set the CARGO_PROFILE_RELEASE_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation.

Caused by:
  process didn't exit successfully: `/wrkdirs/overlays/overlay/security/vaultwarden/work/target/release/build/openssl-sys-c25c229eed872aed/build-script-main` (exit status: 101)
...

full build log

Troubleshooting data

Patched Cargo.toml

--- Cargo.toml.orig     2023-11-08 12:15:34 UTC
+++ Cargo.toml
@@ -140,10 +140,10 @@ cookie_store = "0.19.1"
 cookie_store = "0.19.1"

 # Used by U2F, JWT and PostgreSQL
-openssl = "0.10.57"
+openssl = "0.10.59"
 # Set openssl-sys fixed to v0.9.92 to prevent building issues with musl, arm and 32bit pointer width
 # It will force add a dynamically linked library which prevents the build from being static
-openssl-sys = "=0.9.92"
+openssl-sys = "=0.9.95"

 # CLI argument parsing
 pico-args = "0.5.0"

Updated Cargo.lock

cargo update -p openssl-sys -p openssl

Build succeeds.

Cargo.lock updated

--- Cargo.lock.orig     2023-11-08 12:15:54 UTC
+++ Cargo.lock
@@ -1949,9 +1949,9 @@ name = "openssl"

 [[package]]
 name = "openssl"
-version = "0.10.57"
+version = "0.10.59"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "bac25ee399abb46215765b1cb35bc0212377e58a061560d8b29b024fd0430e7c"
+checksum = "7a257ad03cd8fb16ad4172fedf8094451e1af1c4b70097636ef2eac9a5f0cc33"
 dependencies = [
  "bitflags 2.4.1",
  "cfg-if",
@@ -1981,18 +1981,18 @@ name = "openssl-src"

 [[package]]
 name = "openssl-src"
-version = "111.28.0+1.1.1w"
+version = "300.1.6+3.1.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "3ce95ee1f6f999dfb95b8afd43ebe442758ea2104d1ccb99a94c30db22ae701f"
+checksum = "439fac53e092cd7442a3660c85dde4643ab3b5bd39040912388dcdabf6b88085"
 dependencies = [
  "cc",
 ]

 [[package]]
 name = "openssl-sys"
-version = "0.9.92"
+version = "0.9.95"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "db7e971c2c2bba161b2d2fdf37080177eff520b3bc044787c7f1f5f9e78d869b"
+checksum = "40a4130519a360279579c2053038317e40eff64d13fd3f004f9e1b72b8a6aaf9"
 dependencies = [
  "cc",
  "libc",

[BlackDex]

We do not support LibreSSL out-of-the-box here because we have a dependency on OpenSSL.
If you want to use LibreSSL you should update the openssl crates in the Cargo.toml currently.

Our building fails using the updated libraries because of a bug/regression in the openssl crate.
Until that is fixed or addressed in some way (and maybe i will create a PR my self if i have time) we are currently sticking to the latest working version of the openssl crates.

[Sp1l]

Thanks for the response! Clear.

As it was pulling in rust/crates/openssl-src-300.1.6+3.1.4.crate I was assuming that it'd build its own library for static linking. (I have little Rust experience). Looks like it doesn't actually build (no refs to openssl-src in the build).

[BlackDex]

Try to use the vendored_openssl feature, that might help maybe?

[Sp1l]

Try to use the vendored_openssl feature, that might help maybe?

Yep, that works as advertised!

we have a dependency on OpenSSL.

Can you elaborate on the dependency? As a Rust novice, it seems that the crate takes care of some of the difference in APIs and I'd assume that the build would fail on missing, or different, functions/methods etc. Makes me curious what I've missed.
It builds fine with LibreSSL 3.8.2 (if I update the openssl crates), but should I expect issues?

FWIW: The bundled 1.1.1 branch of OpenSSL now has one un-patched vulnerability as it is end-of-life. Doesn't look like the affected feature is used in Vaultwarden.

[BlackDex]

I think you are best of by updating both openssl crates before you build. That should solve your issue.

We can't for our build process, because that breaks out Alpine Builds.

[BlackDex]

Also, we do not use OpenSSL v1.1.1, since that is not used by Debian Bookworm and not by the Musl Build image, they both use v3.0 LTS.

It currently only uses v1.1.1 if you use the pinned openssl crate versions and only if you use the vendored option.

[BlackDex]

btw, if they merge my PR sfackler/rust-openssl#2094 into rust-openssl, then we can update the versions again, and you should be able to build without any hassle :)

[zacknewman]

You should be fine removing the explicit openssl-sys dependency—it's an implicit dependency from openssl—and ensuring openssl is at least version 0.10.59 (source: I host Vaultwarden on OpenBSD 7.4-stable which has LibreSSL 3.8.2). In the future before updating Vaultwarden, verify that the version of openssl in Cargo.toml is compatible with whatever version of LibreSSL you have. The openssl crate depends on LibreSSL Portable which can be a month behind LibreSSL, so just exercise patience when that happens.

If you want to "live dangerously", you can patch openssl-sys locally and test to see if everything works fine (sometimes openssl-sys checks for a specific version of LibreSSL, and sometimes it only cares about <major>.<minor> (e.g., all version of LibreSSL from now inclusively until 3.8.9 should be fine due to the recent patch that ignores <patch>)).