Update openssl-src to 300?

[link2xt]

Currently openssl-sys crate references openssl-src version 111. Is there any plan to update to OpenSSL 3.0?

[sfackler]

OpenSSL 3 unfortunately has some pretty severe performance regressions. The vendored feature will use 1.1.1 until the upstream situation improves: #1578.

[amousset]

We will likely need to soon switch to openssl 3 anyway as 1.1 will reach EOL (11th September 2023).

[sfackler]

Yeah, it's probably time. OpenSSL 3.1.0 seems to have at least partially resolved the performance regressions.

[Sytten]

I would be very interested in keeping a branch of openssl-sys on openssl 1.1
Some of us need to interact/maintain legacy systems that won't go off because the EOL was decided on a certain date

[amousset]

This issue is only about the version embedded when using the vendored feature (which should always use a supported version IMO), not the general compatibility of the crate.

[Sytten]

Then I might suggest keeping a feature vendored-1.1 or something like that for a little while. I might be in the wrong but we did have issues with our Tauri application when not vendoring because it was expecting openssl 1.1 and only openssl 3 was installed (ubuntu 22.04). We support ubuntu 20.04 which is only EOL in 2025 and it doesn't have an official port of openssl 3.

[daprilik]

For folks interested in using vendored openssl 3.0 today, I've figured out a somewhat hacky approach that allows patching openssl-src in the crate-graph without running into cargo [patch] semver issues.

Create a new crate called openssl-src-hack, with the following Cargo.toml and src/lib.rs:

[package]
name = "openssl-src"
version = "111.25.2+1.1.1t" # !! MUST MATCH VERSION IN `Cargo.lock` !!

[dependencies]
openssl-src = "300.1.0+3.1.0"

pub use openssl_src::*;

Then, patch this crate in via [patch] in your project's Cargo.toml

[patch.crates-io]
"openssl-src" = { path = "./openssl-src-hack" }

It ain't pretty... but it does indeed work, as while the openssl-src versions are ostensibly semver incompatible with one another (i.e: you shouldn't be able to patch a version = "111.25.2+1.1.1t" with a version = "300.1.0+3.1.0"), the actual crate-level API is totally compatible, allowing the patch to go off without a hitch.

[sfackler]

@Sytten If you're using the vendored feature then the version of OpenSSL on the host doesn't matter.

[Sytten]

Agreed thats what I am using, I would just like to retain vendored 1.1.1 maybe under a different feature?

[sfackler]

If you want to continue using an EOL version of OpenSSL you can build it yourself.

[Sytten]

I guess that's fair, I just thought that adding a feature vendored-1.1 would really not be a big maintenance burden and would simplify the life of some people. The current vendor setup is very nice to use and builds seamlessly as part of the larger build, something you would abruptly lose. Happy to contribute the 5 lines of code that this represents if you change your mind.

[micolous]

I guess that's fair, I just thought that adding a feature vendored-1.1 would really not be a big maintenance burden and would simplify the life of some people.

Your proposal (as-written) violates feature unification principle that all features are additive: if the openssl-sys/vendored feature normally pulled in OpenSSL v3, any dependency which tried to pull openssl-sys/vendored-1.1 would change the behaviour of openssl-sys in a non-additive way, and thus also the openssl crate. This causes a problem if any dependency requires OpenSSL v3 (either by API differences, or because of bugs in older versions).

Currently, the only way a package can enforce minimum OpenSSL versions is by failing to build when it encounters them. Keeping such build scripts around is a significant maintenance burden for those package authors... and that's a best-case scenario: the package developers may not even test against old OpenSSL, and just have users encountering bugs in their software!

For a simple solution for you: you should pin a specific (old) version of the openssl crate and also not use vendored. By using vendored, you're missing out on any backported patches for OpenSSL v1.1 from your OS/distribution vendor under an extended support agreement, which go beyond what the OpenSSL project (will soon cease) providing, and (should you need it) be built in a way which meets particular cryptographic certifications or regulatory mandates.

[Sytten]

Your proposal (as-written) violates feature unification principle that all features are additive

This is not an argument, most popular crates added features like uuid-1 and uuid-0.9 during the transition period to ease the developer experience.

Currently, the only way a package can enforce minimum OpenSSL versions is by failing to build when it encounters them

Its not the job a package to decide which version is used IMO. You cannot say that and say in the next paragraph that the OS should provide the openssl version. Those arguments are contrary to each other. If the binding is present you can use it and it's the responsibility of the developer to make sure they are present at runtime/link time.

For a simple solution for you: you should pin a specific (old) version of the openssl crate and also not use vendored

Pinning will at some point be impossible when sub dependency move on and require an higher version of openssl-sys. Broad statement about why static linking is bad are unhelpful and I explained my particular use case in the past. End users don't care about that, they care that their software starts, no matter if they are on Ubuntu 20.04 or Ubuntu 22.04. Turns out APT is a mess and if you link against openssl 3 you have problems on 20.04 and if you link against 1.1 you have problems on 22.04.

I am not letting this go because I know it will cause problems if this transition is not handled correctly. I am not trying to be pedantic for the sake of it.