This tracks support for native TLS cert verification in the big wide world of 'other system tools' and software, typically written in C/C++, which are not programming language runtimes/interpreters.
This is the most difficult one to address for a couple of reasons:
There's a lot of system tools and software out there.
They use a range of HTTPS / TLS libraries, not just one.
There's no effort multiplier for the work you put in. When a programming language runtime is patched to do TLS verification through the native trust store, all programs written in that language are transparently upgraded to the new behaviour (unless the user switches it off). Whereas when you patch one system tool to do native TLS verification, you've only patched... one tool.
It will most likely not be possible to patch all system tools. Instead the most practical thing to do is:
Patch the most widely used tools (e.g. curl, wget)
Patch the most widely used HTTPS / TLS libraries (so that when downstream project maintainers notice there's an update, they will hopefully bump their library dependency to incorporate the change)
Major native CLI tools
Wget
Redis client
Psql
Mysql client
Homebrew
Programming language version managers (asdf / rbenv / pyenv ....)
...
Major networking libraries
Boost.Asio
Asio
Libcurl (fortunately the Mac version uses Secure Transport)
This tracks support for native TLS cert verification in the big wide world of 'other system tools' and software, typically written in C/C++, which are not programming language runtimes/interpreters.
This is the most difficult one to address for a couple of reasons:
It will most likely not be possible to patch all system tools. Instead the most practical thing to do is:
curl,wget)Major native CLI tools
Major networking libraries