Remove OpenSSL

[briansmith]

I propose that all the OpenSSL functionality be removed from cross. I noticed a lot of the issues in the cross issue tracker are related to cross trying to maintain OpenSSL; all of these issues would just go away if OpenSSL support were removed. And, the experience of using cross for applications that do not use OpenSSL would be improved.

It's not clear why cross includes OpenSSL for some (but not all) targets in the first place. Making OpenSSl easier to use seems out of scope for a tool like this. The rust-openssl crate already has support for building a vendored copy of OpenSSL if it isn't available. If that mechanism and other ways of installing OpenSSL don't work well, that's really OpenSSL's and/or rust-openssl's problem.

In any case, I would like to use cross specifically for applications that often make some effort to avoid depending on OpenSSL. Unfortunately, cross's OpenSSL stuff gets in the way here. For example, does a Rustls application, specifically one that uses the webpki-roots crate for root certificates, work correctly if OpenSSL isn't installed and/or was never installed?

(FWIW, I am the creator of ring and webpki.)

[therealprof]

Big agreement from my side here.

[TotalKrill]

I actually used this because it meant i did not have to compile a version of openssl myself. So would be sad to see it go. It is quite easy to remove yourself though, so a suggestion would be to create a docker image without it and upload and use that instead in the Cross.toml file.

[SirVer]

I just ran into issues because OpenSSL was removed from cross. Every single of my tools I use cross (and trust) for are using OpenSSL and since this happens somewhere deep down in my dependencies, I have little options of not using OpenSSL. Removing it means that cross has lost all value to me overnight :(.

While I fully acknowledge that the maintenance burden is on the maintainers of this repository and I can see that OpenSSL is a pita to maintain, the users of https://github.com/japaric/trust and many cross users that just want to do a web request in their code will have a lot more to deal with now. I hope this move will be reconsidered going forward.

[CryZe]

Yeah this is likely going to cause significant problems for me as well (I switched to rustls for most targets, but rustls only works on "tier 1" platforms).

[surban]

Is it possible to revert to an older Docker image that still includes OpenSSL?

Edit:
cargo install --version 0.1.16 cross

[Emilgardis]

@surban to use another image, use following config: https://github.com/rust-embedded/cross/blob/master/README.md#custom-docker-images

[SirVer]

Reverting to an older version worked for me too for the moment, but of course comes with the downside of bit rot over time. The convenience of cross for my CI pipeline is a fantastic selling point for rust within my organizations.

[briansmith]

I'm glad this change was made because this makes it much easier for library crate developers to use cross to get an environment more like what's typical for their users. One of the biggest issues I had using cross in the past was that cross's configuration is different from what is typical in non-cross environments. As soon as a user couldn't use cross for whatever reason, they couldn't build my stuff that (accidentally) depended on OpenSSL.

[cschneid]

This suddenly broke my CI pipeline. I use trust, which in turn uses cross. I am not directly using openssl, but it is a transient dependency.

I'm not very familiar with how cross works internally, and only sorta know docker. Is it expected that I need to create a new docker file for every target I build for, which also installs openssl?

I have a short term fix of pinning to v0.1.16 as suggested above. I edited the dynamic lookup of the latest tag in trust's ci/install.sh to be hard coded to local tag="v0.1.16"

[SirVer]

@briansmith Your point is very interesting to me. It seems that cross has two major use cases, one is for crate developers, one is for cross compilers. The former probably want to have full control over the containers used, the latter mostly just want working compiles. And for the latter, OpenSSL is a very common (and very painful) dependency - I'd argue it is the only C dependency that basically all rust programs depend upon in their default configuration.

I'd argue that the cross compiler use case should be optimized for, because it probably represents the (mostly silent) majority of users and because the other use case (crate developers) is likely more savvy and interested to having full control over their environment, aka building their own cross docker base images.

Of course this is just my 2c and since I am just a user and not an active contributor I understand that maintainers need to make tradeoffs to make maintenance manageable. I still hope this change can be rolled back somehow.