←back to thread

Stop Breaking TLS

(www.markround.com)
170 points todsacerdoti | 3 comments | 10 Dec 25 07:06 UTC | HN request time: 0s | source
Show context
gschizas ◴[10 Dec 25 09:31 UTC] No.46215801[source]▶
The fact that most tools have completely different ways to allow them to add certificates is the biggest pain. Git, Python and Rust also have large issues. Git doesn't default to "http.schannel". Python (or rather requests, or maybe urllib3) only looks at its own certificate store, and I have no idea how Rust does this (well, I use uv, and it has its own problems - I know about the --use-native-tls flag, but it should be a default at the least).
replies(5): >>46215828 #>>46215876 #>>46216017 #>>46216074 #>>46216859 #
1. sureglymop ◴[10 Dec 25 09:44 UTC] No.46215876[source]▶
I have this similar gripe when it comes to http proxy configuration. It's invisible to you until you are in an execution environment where you are mandated to use the providers proxy configuration.

Some software reads "expected" env variables for it, some has its own config or cli flags, most just doesn't even bother/care about supporting it.

replies(1): >>46216018 #
2. amiga386 ◴[10 Dec 25 10:05 UTC] No.46216018[source]▶
Chiefly because "supporting it" requires a full JavaScript interpreter, and subscribing to changes in "system settings" during the lifetime of your program. Easier just to support http_proxy/https_proxy/no_proxy (and what standard for no_proxy? Does it support CIDR ranges?) or even less flexibility than that.
replies(1): >>46226135 #
3. sureglymop ◴[11 Dec 25 00:35 UTC] No.46226135[source]▶
If only http_proxy/https_proxy/no_proxy at startup time were more widely supported then. In my case I had to deploy software into a kubernetes cluster managed by a different company that required these configurations.