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).
It's such a nightmare at my current job as well. Everything always just breaks and needs investigating how to fix.
Even putting aside the MITM and how horrendous that is, the amount of time lost from people dealing with the fallout got to have cost so much time (and money). I can't fathom why anyone competent would want to implement this, let alone not see how much friction and safety issues it causes everywhere.
With anti-security policies that: break TLS, thwart certificate pinning, encourage users to ignore certificate errors, expand the attack surface, increase data leak risks, etc. All while wasting resources and money.
Zscaler and its ilk have conned the IT world. Much like Crowdstrike did before it broke the airlines.
Not to mention:
> We only use data or metadata that does not contain customer or personal data for AI model training.
And many things break in different, exciting ways. For example, we discovered that whilst the JVM can be configured to use system certificate store, that does not apply to websocket connections. So the product seems to be able to connect to the server, but all socket connections bork out with TLS errors.
Yeah, and Java has its nice cacerts file so that should have been easy, but then we were using Bazel which does the "hermetic builds" thing so that had to be told about it separately, and on and on with all the other special-snowflake tools.
It added huge amounts of friction which was one reason I decided to move on from that gig.
On Android, macOS/iOS, and Windows, this is a solved problem. Only on the extremely fragmented Linux/Posix runtimes do these problems surface.
Rust's solution is "it depends". You can use OpenSSL (system or statically compiled) or rustls (statically compiled with your own CA roots, system CA roots, or WebPKI CA roots).
I'm afraid that until the *ix operating systems come out with a new POSIX-like definition that stabilises a TLS API, regardless of whether that's the OpenSSL API, the WolfSSL API, or GnuTLS, we'll have to keep hacking around in APIs that need to be compatible with arbitrary TLS configurations. Alternatively, running applications through Waydroid/Wine will work just fine if Linux runtimes can't get their shit together.
Are you sure? It's been a few years, but last I tried Firefox used its own CA store on Windows. I'm pretty sure openjdk uses "<JAVA_HOME>/jre/lib/security/cacerts" instead of the system store too.
> On Android, macOS/iOS, and Windows, this is a solved problem.
Is it, though? It is absolutely trivial for an Android app (like the one you use for banking) to pin a specific CA or even a specific server certificate, and as far as I'm aware it is pretty much impossible to universally override this.
In fact, by default Android apps don't accept any user-installed certs. It uses separate stores for system-installed CA roots and user-installed CA roots, and since Android 7.0 the default is to only include the system-installed store. Apps have to explicitly opt-in to trusting the user-installed store.
Is it solved in macOS? Curl recently removed macOS keychain support as there are like 7 competing APIs 6 of which are deprecated and number 6 is a complete HTTP replacement so curl can't use it.
Only reason why it works on macOS curl is because they're a few versions behind
That last part does sound like a bad deal based on recent anti-owner-control habits like sealed immutable system volumes, but I definitely want to be constrained to a single system cert store controlled by the owner of a computer. Which works for the corporate case as well as the personal one.
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.
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.
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.
I'm in Europe and I see a lot more than that. Apologies for the ugly formatting, mobile:
As part of changing laws in Europe, Meta now offers the option for you to chat with others using third-party messaging apps that have integrated with WhatsApp and that you choose to turn on.
Note: Chats with third-party apps are only available in select regions and may not be available to you.
- You can send messages, photos, videos, voice messages, and documents to end users of supported messaging services that have integrated with WhatsApp.
- Messages or other content you send from WhatsApp to third-party users are encrypted in transit, and WhatsApp can’t see them.
- Third-party apps have their own policies and they might handle your data differently than WhatsApp.
## Eligibility requirements to turn on third-party chats with WhatsApp
- Third-party chats with WhatsApp are only available to users with a WhatsApp account registered to phone numbers in the regions covered by the Digital Markets Act (DMA).
- If you change your phone number to a number registered in a region not covered by the DMA, you won’t be able to use third-party chats on WhatsApp.
- Third-party chats are only available on WhatsApp for iPhone and Android. Third-party chats on WhatsApp are not currently accessible on tablets, web, or desktop.
We care about the safety of our global community when enabling chats with third-party apps. Visit our WhatsApp Privacy Policy for users in Europe for more information.
When you send a message to a third-party app, the phone number registered to your WhatsApp account is available to the third-party app you select. Other people who know your phone number can find and message you from third-party messaging services you've enabled.
Note: Users you’ve blocked on WhatsApp might be able to message you from third-party apps. Learn more about how to block someone in this article.
## Be mindful of the information you share
Before you chat with someone using third-party apps:
- Make sure you know the person you’re chatting with before sharing any personal information.
- Be aware that scams and spam might be more common when messaging with third-party apps.
- If you receive an unwanted message from a third-party chat, you can block the sender from messaging you from the third party.
I reverse engineered what I could, and it's supposed to be all in row 30, column 4 to 11 (8 squares). You may add 2 more squares on the left or right side (it's just checking it's no more than 10 squares).
I'm glad that the programmer put some tolerance to it, but it was impossible for me to know whether he did or not at the time, and that was the end of fun for me :)
I recently wrote some kubernetes charts for running Zulip for my new (smol) org, but I've ran Zulip for the last 3 years as CTO for a mid-sized AAA video game development company...
I really would recommend it over Mattermost (which was in use at another development company I was briefly a part of)
It's a reference to a Simpsons episode where Homer Simpson designs a car, and it's supremely hideous: https://simpsonswiki.com/wiki/The_Homer