feat: use native-tls instead of rustls

[mkroening]

This PR makes ureq use native-tls instead of rustls via ureq::tls::TlsProvider.

On my machine, this decreases compilation time from 5.5 s to 3.0 s.

The TlsProvider docs say:

Defaults to Rustls because this has the highest chance to compile and “just work” straight out of the box without installing additional development dependencies.

This PR in its current form should not be merged, though. On GitHub's ubuntu-latest and macos-latest, it works, but on windows-latest, the doc test fails with:

thread 'main' (4316) panicked at ovmf-prebuilt\src\lib.rs:9:6:
failed to update prebuilt: Request(NativeTls(Custom { kind: Other, error: "unable to find any user-specified roots in the final cert chain" }))

I don't think it is worthwhile to work around this in this crate. I assume this is not trivial, since this is not already worked around in ureq.

After having done the work, though, I still wanted to open a PR in case anyone else is interested in discussing this.

[fogti]

It might be a good idea to expose a function which allows one to pass a custom TlsConfig into the download functionality, and only enable the ureq/rustls feature by default via

[features]
default = ["ureq/rustls"]

in Cargo.toml

[nicholasbishop]

In #244, you noted:

For us, an optional GitHub-CLI-based gh release download would solve this. Being based on the GitHub CLI, this is not a very general solution, though.

I think that could be a good solution here too. Sketching out the idea:

• Make ureq an optional dependency, enabled by default.
• If ureq is not enabled, attempt to download via command-line tools.
  • Doesn't have to be gh, could use curl which is likely more widely installed.
• We could even take this idea bit further and instead of a ureq feature, have a pure-rust feature. If not enabled, then download, decompress, and sha checking could all be done with command-line tools, leaving only the log dependency.

The main downside I see is complexity, since we'd have two code paths to test. Probably not a big deal, but I think it is worth considering whether extra complexity is justified by the timing speedups. I'd like to understand your use case(s) better. Are you running only in CI, or CI and locally? Is the time spent building ovmf-prebuilt a significant portion of your overall build time?

[mkroening]

Thanks for getting back so quickly!

Compared to Curl, gh uses the CI's GitHub token, which helps avoid getting rate-limited (cli/cli#3820 (comment)). But Curl would be a sensible fallback, of course.

We could even take this idea bit further and instead of a ureq feature, have a pure-rust feature. If not enabled, then download, decompress, and sha checking could all be done with command-line tools, leaving only the log dependency.

That would sound sensible if we decide decreasing compile times is worth these changes.

I'd like to understand your use case(s) better. Are you running only in CI, or CI and locally? Is the time spent building ovmf-prebuilt a significant portion of your overall build time?

We are running both in CI and locally. We use a custom cargo xtask command for running different scenarios of our operating system (some of those in UEFI with OVMF). ovmf-prebuilt is not built for end users of OS anymore, though. Also, ovmf-prebuilt is not built more than one time per CI job, so this issue is not critical to us.

Initially, I thought that going for native-tls instead of rustls would be a free speed-up, but it seems not to be worth the downsides (see reqwest v0.13 - rustls by default - seanmonstar).