@k0001, thanks for your PR! By analyzing the history of the files in this pull request, we identified @kosmikus, @globin and @bennofs to be potential reviewers.

NIX_SSL_CERT_FILE is patched into our openssl, but its purpose is to avoid clashing with host tools using host certificate chain. Seems irrelevant for within builds.

@shlevy just saying because it's unclear. For example I think we amended our patch to the Go http library so that it looks for NIX_SSL_CERT_FILE instead of SSL_CERT_FILE (which we had to patch in previously). So for tools that we expect to use in builds and as user tools, that's where this sort of question becomes more important, or at least it's unclear to me. If someone wrote some sort of go downloader fixed output derivation, they'd need to pass in NIX_SSL_CERT_FILE for it to work properly.

Oh, I don't think it's correct to do "instead" semantics. NIX_SSL_CERT_FILE should be an override.

@copumpkin @shlevy For me this change looks somewhat confusing too.

Am I right in my understading that the idea is to make sure that TLS verifications during the build (e.g. fetching sources, etc.) use a fixed set of trusted certs (the one from pkgs.cacert), while making sure at the same time that the path to this bundle is never embedded in the binaries, so that during runtime binaries do their best to use a system-default location (or NIX_SSL_CERT_FILE as an override)?

Aren’t similar changes necessary for all the fetch* functions out there? For example fetchgit does not seem to override anything, which will probably result in a (minor) impurity: if my system trusted roots are different from Hydra’s it is possible that the build will fail for me locally (won’t be able to fetch surces) while succeeding on Hydra. Is that what we want to avoid?

Or could it be that we want the opposite: the system’s preferred certificates to be always used, even during the build?

I stand corrected, fetchgit contains the override. But, looks like, e.g. fetchurl does not.

Why does fetchdarcs need certificates at all? fetchurl doesn't need them because it uses curl --insecure. This is fine because the integrity of the downloaded file is guaranteed by the hash.

@edolstra Ah, yes, of course. Since we are checking hashes anyway, all of the fetch* functions should probably get rid of the pkgs.cacert dependency and just somehow force unsecure download.

#26273

The integrity of the downloaded file is guaranteed, sure, but the privacy of what is being requested isn't!