std.crypto.Certificate.Bundle/macos: rescanMac picks non-default keychain to pull certificates from

[cixel]

Zig Version

0.13.0

Steps to Reproduce and Observed Behavior

rescanMac populates the system cert pool by reading from the keychain at /System/Library/Keychains/SystemRootCertificates.keychain. When I query my system's keychains, this isn't listed:

$ /usr/bin/security list-keychains
    "~/Library/Keychains/login.keychain-db"
    "/Library/Keychains/System.keychain"

$ /usr/bin/security default-keychain
    "~/Library/Keychains/login.keychain-db"

This causes problems on my work computer, which sits behind an SSL-intercepting proxy. I believe the proxy installed its root CA to one of these keychains, but not to the one which is hardcoded in rescanMac, which leads to TlsInitializationFailed errors for std.http.Client requests. This also means that zig build fails when fetching dependencies.

Expected Behavior

It's unclear to me whether "fault" here belongs to std.crypto.Certificate.Bundle for only checking on spot for the keychain, or to the proxy for installing its root CA to the keychain in /System.

Regardless, I think there are a couple of things that could be done:

• either sub-process /usr/bin/security to query for which keychain(s) to use, or invoke Apple's Security.framework APIs directly
  • it might be necessary to dynamically load the APIs directly from e.g /System/Library/Frameworks/Security.framework/Versions/A/Security using std.DynLib?
• it would be helpful to have a way to supply a cert bundle file with an env var, as in curl's CURL_CA_BUNDLE variable
  • I have a proof of concept for this here which works for me locally
  • this kind of override might become necessary with ship root SSL certificates along with ziglang.org-vendored tarballs #14168, if I'm not misunderstanding it