buildRustPackage no longer works in darwin sandbox due to SSL errors

I’m still trying to figure out what’s going on, but buildRustPackage no longer works in the darwin sandbox. Specifically the cargoDeps step fails with network errors:

    Updating crates.io index
warning: spurious network error (2 tries remaining): [60] SSL peer certificate or SSH remote key was not OK; class=Net (12)
warning: spurious network error (1 tries remaining): [60] SSL peer certificate or SSH remote key was not OK; class=Net (12)
error: failed to sync

Caused by:
  failed to load pkg lockfile

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  [60] SSL peer certificate or SSH remote key was not OK; class=Net (12)

I can’t do a true bisect because I’m not willing to spend forever rebuilding the darwin stdenv or other dependencies, but I did manage to track this down to merge commit e50c67ad7ee which is a merge of staging-next into master. This merge includes a bump of rustc from 1.41 -> 1.42, which seems like the most likely culprit, but I can’t be sure.

This suggests to me that cargo 1.42 is changing how it fetches the index such that it’s no longer using NIX_SSL_CERT_FILE, or even SSL_CERT_FILE or CARGO_HTTP_CAINFO (since we wrap cargo to set those env vars to our ca-bundle.crt). However CARGO_HTTP_CAINFO is still documented in latest master as containing the CA bundle file. So I’m really not sure what’s going on.

It’s strange that this only happens on Darwin. That suggests that Cargo is still using the SSL certs, but something about the SSL certs themselves does not work in the Darwin stdenv? But then I’d expect a lot more to fail outside the Rust ecosystem.

This suggests to me that Cargo 1.42 is using the system certificate store instead of the SSL certs provided by Nix. But looking at the diff from 1.41.0 to 1.42.0 shows no changes to the libcurl dependency, and no changes to the code that fetches the registry. So I don’t know what’s going on. Maybe it’s not cargo itself that broke but some other change included in the staging merge? I really don’t know.

Here’s an oddity: cargo 1.41.0 links to libcurl.4.dylib but cargo 1.42.0 doesn’t. Maybe it’s statically linking its vendored copy of curl instead, but if so, I can’t figure out where this change is introduced. It looks like the static copy of curl will use SecureTransport on macOS, but that shouldn’t prevent it from reading our certificate bundle anyway since we pass it in the CARGO_HTTP_CAINFO env var. Still, that seems like the most likely cause of the breakage. I just can’t figure out what caused it.

CC @retrry who’s listed as the maintainer of cargo and @qyliss who updated rust from 1.41.0 to 1.42.0.