Codecov Report

Merging #1128 (502970c) into main (8495c0a) will not change coverage.
The diff coverage is n/a.

❗ Current head 502970c differs from pull request most recent head fc009cf. Consider uploading reports for the commit fc009cf to get more accurate results

@@           Coverage Diff           @@
##             main    #1128   +/-   ##
=======================================
  Coverage   95.60%   95.60%           
=======================================
  Files          60       60           
  Lines       10068    10068           
=======================================
  Hits         9626     9626           
  Misses        442      442           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

This seems kinda trivial except for the insecure verifier, which puts us back at square one of semi-recommending insecure workarounds. I'm not sure this adds much value in its current form.

This seems kinda trivial except for the insecure verifier, which puts us back at square one of semi-recommending insecure workarounds. I'm not sure this adds much value in its current form.

@djc I think the triviality of it is only apparent to the frequent rustls developers. I have spent considerable time figuring it out during my (still incomplete) migration from openssl, and I think it would be really good to help the novice users to avoid all the pain I experienced. Plus this offers a place for more migration recipes to be added by other contributors. Unless you want to make the migration a bit more difficult that is :)

With regards to the dangerous code: I understand you don't like dangerous and unsafe code. None of us do, and in an ideal world we won't have any of it. But there is not much we can do when we port existing code that requires such behavior. We can pretend it doesn't exist, or we can at least provide documentation, and make it just a bit more safe, explaining the risks and how to avoid it.

In this specific case, a well known Martin tile server needs to support PostgreSQL providers such as Heroku, which has self-signed certs that has caused a lot of issues for the Martin users. I would love to solve this in a better way of course, but the first step would be to migrate existing functionality without breaking too much.

I just realized I was referring to Curse of knowledge above. Hope we can move forward on this and collaboratively help all new devs migrate to Rustls as soon as they possibly can.

This seems kinda trivial except for the insecure verifier, which puts us back at square one of semi-recommending insecure workarounds. I'm not sure this adds much value in its current form.

I feel similar to Djc. I think if there are gaps in the existing documentation we should focus on improvements there.

This PR has been open for a good while now without any additional community input in favour. I'm going to close this PR but would encourage you to consider improvements to the existing docs if you still believe there are gaps that make it difficult for new users to understand the Rustls API surface.