search

rustls / rustls-platform-verifier

A certificate verification library for rustls that uses the operating system's verifier
Apache License 2.0
63 stars 20 forks source link

Consider merging UNIX functionality from rustls-native-certs #132

Open complexspaces opened 2 weeks ago

complexspaces commented 2 weeks ago

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

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

Ah yes, that makes sense, too!

tbrockman commented 1 week ago

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 commented 1 week ago

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