You missed #58513, right?

@LnL7: what's your thought on this? Any arguments against using the other approach? (not marked as WIP)

It might not be warranted but I still have similar concerns as @copumpkin on d6454e6. This functionality won't work on nixos either (/etc/ssl is readonly) and introducing frameworks could have some undesirable side effects or issues like NixOS/nix#2523.

I marked it wip because I only tested the bootstrap build, not the full stdenv yet.

This functionality won't work on nixos either (/etc/ssl is readonly)

That contradicts my current understanding. "At work" we do successfully use gnutls system trust store on NixOS (in knot-resolver) for verifying TLS servers. I'm not aware of any functionality writing the system trust list (there might be), but reading it seems far more important anyway.

That's my point, add_system_trust is probably not used anywhere. And if it is it's probably not an important feature that will fail.

Then I believe you misunderstood the purpose of the add_system_trust() function; it's precisely what we use.

/**
 * gnutls_x509_trust_list_add_system_trust:
 * @list: The structure of the list
 * @tl_flags: GNUTLS_TL_*
 * @tl_vflags: gnutls_certificate_verify_flags if flags specifies GNUTLS_TL_VERIFY_CRL
 *
 * This function adds the system's default trusted certificate
 * authorities to the trusted list. Note that on unsupported systems
 * this function returns %GNUTLS_E_UNIMPLEMENTED_FEATURE.
 *
 * This function implies the flag %GNUTLS_TL_NO_DUPLICATES.
 *
 * Returns: The number of added elements or a negative error code on error.
 *
 * Since: 3.1
 **/
int
gnutls_x509_trust_list_add_system_trust(gnutls_x509_trust_list_t list,
					unsigned int tl_flags,
					unsigned int tl_vflags)
{
	return add_system_trust(list, tl_flags|GNUTLS_TL_NO_DUPLICATES, tl_vflags);
}

BTW, our gnutls currently does not have a patch to honor NIX_SSL_CERT_FILE :-) The only thing it has is:

lib.optional stdenv.isLinux "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt"

So I guess your approach may work if we supplement it by honoring that variable – I suppose that's how other SSL stuff works on nixpkgs darwin? (I can't really judge the risk in using the system libraries for this. My NixOS doesn't define the variable, so I suppose the /etc/ssl fallback needs to be there anyway.)

I have no idea how I came to the conclusion that it was mutating the trust store. While this patch is basically a revert of c0eb46d3463cd21b3f822ac377ff37f067f66b8d on 3.6.x, implementing NIX_SSL_CERT_FILE instead is probably the way to go then.

Rebased (atop current Hydra's staging-next so testers have some binaries):

• fix trivial conflict with 3.6.6 -> 3.6.7
• don't apply the patch on non-Darwin (forces autotools), so it now builds for me on Linux

I implemented the $NIX_SSL_CERT_FILE patch. I'm quite confident it will all be OK, but I can't test Darwin. I did test it overrides the store on x86_64-linux (in my case it's useful for tests running in nix builds).
@GrahamcOfBorg build gnutls

Thanks! That seems to work as expected, I also updated the patch to be an actual revert of the upstream commit for clarity.

OK. On 3.6.7 grep 'CoreFoundation/\|Security/' only finds this file, some m4+configure stuff and ./gl/tests/*, so it will probably be OK, if it builds for you.

@GrahamcOfBorg eval

(a problem was fixed on staging)

Closely related: #61179