Why are so many crates using OpenSSL 0.7?

1

I run into this every now and then. I pin to OpenSSL 0.7 in my Cargo.toml because I always seem to have some dependency stuck on 0.7.14. It doesn't look like I'm alone with this problem when I look at crates.io. From a quick glance it seems like ~90% of the OpenSSL downloads are for 0.7.14.

So I have two questions:

First, what gives? Is there one common project that is holding this all back or some larger problem?

Second, is there anything we should keep in mind as library developers to keep this from happening to our crates? It looks like the OpenSSL crate has been very busy since 0.7.14, but the community isn't picking it up. Breaking API changes happen in pre-1.0 libraries, it's the way of it, but was there anything that could have made to help the community move forward to the new version?

2 Likes
2

I think most of it would be due to Hyper, which is blocked on a whole bunch of things.

3

The comments on that Hyper issue make it sound like Hyper and all of its dependencies have to choose between OpenSSL 0.7, 0.8 and now 0.9. Is there no way for these libraries to simply support multiple OpenSSL versions?

5

When I upgraded my own OpenSSL dependent library to .8, it was non-zero code migration. So no, it wouldn't be trivial to support multiple versions IMO.

6

The OpenSSL C librarys now has 2 APIs, the old 1.0.x versions and the new 1.1.x versions. The new version hides a lots of the internal structs and forces one to access them through proper accessors.The Rust OpenSSL crate, version 0.9 supports the new OpenSSL C API while 0.7 support the old API. All this complicates upgrading to the newer version since this involves breaking changes.

7

See my other reply in the related thread. It's a something that not all system dynamic linkers supported (assuming that these versions of the OpenSSL crate bundle different OpenSSL libraries).