[openssl][0.9.24] Fail to build on hosts with openssl 1.1.1

[otavio]

Today I updated my host development machine and found that it was not building my source code anymore.

Got the following failure:

error: failed to run custom build command for `openssl v0.9.24`
process didn't exit successfully: `.../target/debug/build/openssl-4dcd4d0c1d4575a6/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to detect OpenSSL version', .../.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14
note: Run with `RUST_BACKTRACE=1` for a backtrace.

It needs to be upgraded to openssl-sys last releases. This is important as multiple vendors will start upgrading OpenSSL and more people will face it. For now, I downgraded my host to openssl 1.1.0

[andrzejressel]

I'm having the same error, but I think it's dependency problem and not library's. Current library version is 0.10.12 and I think we should send PR to dependencies to use the latest version.

[sfackler]

I would prefer that people update to the current release of this crate that already supports 1.1.1.

[est31]

Note that updating to the current release is often non-trivial and takes longer than it should.

E.g. I filed seanmonstar/reqwest#308 in June. It took until August until it was fixed on master. That's 8 months after the openssl 0.10 release. And there still isn't a released version of reqwest yet that ships with the newer openssl.

I do agree that it's prefferable if people updated to the current release of reqwest, but I don't think that letting compilation fail is a good way to convince them to do this update. If you want the ecosystem to switch to your newer versions more eagerly, you should bring it to them. Ask them to update it. But don't force them, please. The current way of treatment is just annoying everyone in the ecosystem.

[est31]

E.g. the iron framework still uses hyper 0.10 and depends on hyper-native-tls. And hyper-native-tls only supports native-tls 0.1 which only supports openssl 0.9. So what to do now? Sure, optimally iron updates its hyper dependency from 0.10 to 0.12, but this will neccessitate major changes and most likely get to users as well through a change in the iron API.

[andrzejressel]

Frankly, this example for me shows "fault" of iron, not openssl. As a library developer I should ensure that I'm using the latest dependencies. openssl-rust developer shouldn't care which version native-tls, hyper or iron uses - his job is to ensure compatibility with latest openssl.

[est31]

native-tls, hyper-native-tls are both maintained by the same person as the openssl crate is. Yet both required breaking changes to update from openssl 0.9 to 0.10.

[sfackler]

If you want the ecosystem to switch to your newer versions more eagerly, you should bring it to them.

There are 161 crates on crates.io which directly depend on rust-openssl, and 105 that directly depend on native-tls. It is not feasible for me to push out upgrades to all of those whenever I cut a new release.

But don't force them, please. The current way of treatment is just annoying everyone in the ecosystem.

What are your expectations around support? How many crates continue maintaining old major versions in perpetuity?

[mqus]

just a question for my usecase: I have openssl 1.0.2p installed alongside 1.1.1, how do I tell cargo to use only openssl1.0.2p?

On topic: I would really appreciate it if you push a 0.9 update but I completely understand your concerns and won't try to convince you otherwise.

[sfackler]

Set the OPENSSL_DIR environment variable to point to the location 1.0.2 is installed

…

On Sun, Sep 16, 2018 at 1:08 PM mqus ***@***.***> wrote: just a question for my usecase: I have openssl 1.0.2p installed alongside 1.1.1, how do I tell cargo to use only openssl1.0.2p? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#994 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABY2UdGF_QH79i_GQrDdD6go5v_CXX7Aks5ubq_HgaJpZM4WqWbx> .

[est31]

There are 161 crates on crates.io which directly depend on rust-openssl, and 105 that directly depend on native-tls. It is not feasible for me to push out upgrades to all of those whenever I cut a new release.

I think it's important to get the populous projects that are using your crate to use the newer version before you end support for the older one. And with enough time in between the two events so that users are given time to switch. The number of popolous projects is small, I'd say. Even simple pings would help: "hello, I'd like you to update to openssl 0.10, as openssl 0.9 will go out of maintenance on ABC"

What are your expectations around support? How many crates continue maintaining old major versions in perpetuity?

My expectation is that if there is a significant amount of users of a specific version of a crate, that version should still see some little level of support. Given that high-profile projects like reqwest or iron are still using openssl 0.9, this seems to be fulfilled.

[otavio]

I understand that ultimately, 0.9.x need to be abandoned and all energy and effort to be focused on 0.10.x or any other future release, however, we are facing some major changes in multiple projects and upgrades have been slowed down a bit.

The openssl upgrade from 1.1.0 to 1.1.1 is a minor release, from user point of view. I understand it ended having more features added along the way but adding support for existing features would be enough and provide an upgrade path for users.