but automatically falling back to bundled webpki-roots trust anchors when it comes up empty. I suspect that might be more user friendly, and matches the approach offered in rustls-platform-verifier (see some discussion in rustls/rustls-platform-verifier#12).

While I'd support this, I believe that should be an additional, recommended function. Not the replacement behavior for this function.

I observed this on a Linux system without ca-certificates installed. Specifically, a GH CI runner I uninstalled most packages from. Then, I also encountered it on a Debian slim Docker image.

I'm fine updating the documentation 👍

Done

Usually we would postpone builder API errors until the end of the builder chain, which this would subvert.

While I'm not against standing in the way in convention with PR, I'd note that policy makes it more difficult to identify which step in the process failed as you get one Result for all steps, not one Result for each step which may fail. While the error itself may reasonably allowing discovery of the issue, the proposed path here is if with_native_roots returns None/error, callers fallback to with_webpki_roots. They'd need a way to introspect the final Result to check if it's due to this specific issue in order to safely execute the suggested fallback (unless they simply blindly try again with with_webpki_roots).

Since the suggested error to replace this with was std:io::Error, not hyper_rustls::config::BuildError, this seems infeasible.

Also, while I do agree the error would be more descriptive, I think None to signify there were no valid roots on the system is fine. Regardless, I'm happy to move it to an error, so long as the policy on where to put the error and the suggested mediation path is resolved.

@ctz Resolved your comments :)

Also, the lib.rs example is failing as its function doesn't return an error, so that does have to be an expect...

Personally, I think that's trivial enough it doesn't have to be in hyper-rustls, but it's hard to argue against libs adding extra helpers to go the extra mile in friendliness...

Anything else needed for this to be merged?

Anything else needed for this to be merged?

Looks like there's a CI failure from another example in lib.rs that needs to expect. Could you fix that up @kayabaNerve? It would also be helpful if you could squash your commit history.

Oh, sorry. I have no idea how I missed that. Will correct that now.

Would love to get this included with whatever release updates to hyper 1.0 :)

Pushed a new single commit.

CI passed :D

Thanks kayabaNerve.

Happy to.