Support builds of OpenSSL from vendored source

[sfackler]

Closes #580.

[sfackler]

cc @alexcrichton

[alexcrichton]

Shouldn't this logic (and most of the logic in this script) end up getting removed in favor of the src crate?

[sfackler]

The src crate can only build 1.1.0.

[alexcrichton]

Bah :(

[alexcrichton]

Some things I'd personally do before merging:

• Add documentation in the README for the feature
• Make sure there's a system in place for updating openssl-src -- I'd specifically like to talk to the infra team in Rust about this.

[sfackler]

One other thing we should figure out is the upgrade story. 1.1.0 EOLs in just over a year: https://www.openssl.org/policies/releasestrat.html. We could simply say that we track the newest release?

[alexcrichton]

Yes I'd imagine that the crate provides no guarantee really about what version it provides, other than:

• The version is compatible with the openssl crate
• The version is supported by the OpenSSL project at the time of publication
• The most recent version of the crate uses a version of OpenSSL with no known security vulnerabilities.

That is, I'd imagine 1.0.2 and 1.1.0 would both be fine to use today in openssl-src.

[sfackler]

It is a bit nontrivial due to version-specific features. For example, if we went with 1.0.2, people would presumably want to use set_ecdh_auto, but that's been removed in newer versions. Even for things that aren't removed, you'd need to enable the v111 or v120 or whatever feature to retain access.

We could disable those features when vendored is enabled? Or just not worry about it since it'll only happen once every couple of years.

[alexcrichton]

Hm that's a good point. I wouldn't be too too worried about this yeah but it seems like enabling vendoring probably shouldn't opt you in to a specific version, you'd have to still select it manually? We could then, if necessary, give a nicer error when you require vendoring and features but there's a version mismatch.

[sfackler]

Yeah, you'd still have to manually opt-in. It seems fine to just note our upgrade policy in the documentation. If people want to opt into version specific features they'll just need to be careful around upgrade times.

[sfackler]

One other thing to decide here is how the vendored build is activated. It's currently done via a Cargo feature, but it's not a super great use of that. Only the root crate is going to be the thing that cares, and it normally isn't going to be directly depending on openssl-sys. The other option is to control via an environment variable, but we then have to unconditionally depend on the source package. Seems like not the worst thing though?

[alexcrichton]

Perhaps we could take a leaf out of rayon's book and require RUSTFLAGS='--cfg openssl_sys_unstable'?