Consider merging UNIX functionality from rustls-native-certs

[complexspaces]

This proposal came up at the beginning of the year on the community Discord: Should we soft-deprecate rustls-native-certs in favor of this crate since it provides a superset of functionality? I'm moving this out of the Discord thread so its more visible and easier to track.

There are a few possible approaches here, such as

• rustls-native-certs continues to exist, as is, with a soft-deprecation and this crate will depend on it when targeting a UNIX target.
• rustls-native-certs is archived and its UNIX-specific functionality moves over here.

In the thread, @cpu mentioned they thought a README notice indicating the soft deprecation was uncontroversial. @djc brought up the first approach.

The first path would argue that we would need to maintain the crate either way, so it doesn't gain us much to merge it in here. However, the second approach would give us a lot more flexibility to implement #60 since rustls-platform-verifier could control where it reloads files from more precisely instead of the blunt API. It would also help move people towards doing the more correct thing on all OSes except Linux/BSD.

[djc]

Given my experience so far I think it is too early to do anything like this. On Linux and BSDs, there is basically no benefit to using rustls-platform-verifier, and for now the adoption of rustls-platform-verifier doesn't appear to be taking off (for the past 90 days, the platform verifier got 6% of the downloads compared to native-certs).

I think we should clear the blockers (#58) that allow reqwest to adopt this, enable support in reqwest and ideally lobby for making the default there.

We also have the platform verifier enabled in mainline rustup so once that has been released (hopefully fairly soon) we should get a bunch of extra testing in the wild.

[complexspaces]

Given my experience so far I think it is too early to do anything like this...

That makes perfect sense 👍. I could have been more clear upfront in the issue but I wasn't suggesting doing anything today. I just wanted the subject in an easier-to-track location.

[cpu]

I think we should also consider resolving https://github.com/rustls/rustls-platform-verifier/issues/125 before moving any new code from other repos in here.

[djc]

I think we should also consider resolving #12 before moving any new code from other repos in here.

#12 is marked as resolved... did you mean #58?

[cpu]

https://github.com/rustls/rustls-platform-verifier/issues/12 is marked as resolved... did you mean https://github.com/rustls/rustls-platform-verifier/issues/58?

Oops, dropped a digit in my copy-paste. I meant #125: I think we would want to maintain the development velocity we have in the rustls-native-certs repo and doing that in a world where we move the code in this repo will mean figuring out a way to avoid blocking on individuals where possible.

[djc]

Ah yes, that makes sense, too!

[tbrockman]

and for now the adoption of rustls-platform-verifier doesn't appear to be taking off (for the past 90 days, the platform verifier got 6% of the downloads compared to native-certs).

Just as anecdata, my search for a Rust-equivalent (or something which could be extended to that end) of mkcert led me to rustls-native-certs, and I only found rustls-platform-verifier in a link in one of the issues (https://github.com/rustls/rustls-native-certs/issues/3). It seems to have better search result ranking for queries similar to "rust certificate store".

[ctz]

I think at the very least, we should add to https://github.com/rustls/rustls-native-certs?tab=readme-ov-file#should-i-use-this-or-webpki-roots to explain the various tradeoffs