mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
Build with LibreSSL 3.8.2 fails #1760
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Sp1l on GitHub (Nov 8, 2023).
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
full build log
Actual behaviour
full build log
Troubleshooting data
Patched
Cargo.tomlUpdated
Cargo.lockBuild succeeds.
Cargo.lockupdated@BlackDex commented on GitHub (Nov 8, 2023):
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 commented on GitHub (Nov 8, 2023):
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 commented on GitHub (Nov 8, 2023):
Try to use the vendored_openssl feature, that might help maybe?
@Sp1l commented on GitHub (Nov 13, 2023):
Yep, that works as advertised!
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 commented on GitHub (Nov 13, 2023):
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 commented on GitHub (Nov 13, 2023):
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 commented on GitHub (Nov 14, 2023):
btw, if they merge my PR https://github.com/sfackler/rust-openssl/pull/2094 into rust-openssl, then we can update the versions again, and you should be able to build without any hassle :)
@zacknewman commented on GitHub (Nov 15, 2023):
You should be fine removing the explicit
openssl-sysdependency—it's an implicit dependency fromopenssl—and ensuringopensslis at least version0.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 ofopensslinCargo.tomlis compatible with whatever version of LibreSSL you have. Theopensslcrate 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-syslocally and test to see if everything works fine (sometimesopenssl-syschecks 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>)).