New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gnutls: add SSL_CERT_FILE #48317
gnutls: add SSL_CERT_FILE #48317
Conversation
Success on x86_64-darwin (full log) Attempted: gnutls Partial log (click to expand)
|
Success on aarch64-linux (full log) Attempted: gnutls Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: gnutls Partial log (click to expand)
|
@@ -30,7 +30,7 @@ stdenv.mkDerivation { | |||
|
|||
preConfigure = "patchShebangs ."; | |||
configureFlags = | |||
lib.optional stdenv.isLinux "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt" | |||
lib.optional stdenv.isLinux "--with-default-trust-store-file=${cacert}/etc/ssl/certs/ca-bundle.crt" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this still allows to override the certificate store?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it does not allow to override the cert store. As far as I understand, the only way to make this happen is to patch in SSL_CERT_FILE
support into GnuTLS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel comfortable with this solution. Yes, it's guaranteed to work on any system. But it kills any flexibility to add custom certs and makes GnuTLS unusable in environments that require them (unless you want to override cacert
).
Unless we want to patch GnuTLS, I would suggest to leave it as is and document that GnuTLS expects the certs in /etc/ssl/certs/ca-certificates-crt
, so on non-NixOS systems the user should copy or symlink the cert bundle there. Of course that requires root access...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, I will patch GnuTLS then.
This should target staging. |
Success on aarch64-linux (full log) Attempted: gnutls Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: gnutls Partial log (click to expand)
|
Timed out, unknown build status on x86_64-darwin (full log) Attempted: gnutls Partial log (click to expand)
|
I've pushed a GnuTLS patch that adds |
Success on aarch64-linux (full log) Attempted: gnutls Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: gnutls Partial log (click to expand)
|
Timed out, unknown build status on x86_64-darwin (full log) Attempted: gnutls Partial log (click to expand)
|
r += ret; | ||
#endif | ||
|
||
+ char *env = secure_getenv("SSL_CERT_FILE"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you ask upstream to incorporate this patch? Even if they refuse to merge it, we still get a code review from them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, sure, I'll try. However, to make it upstreamable it should probably be under a configure option.
The patch is trivial though, this chunk looks exactly like DEFAULT_TRUST_STORE_FILE
above it, other than secure_getenv
call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would it need to be behind a configure option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I gather, upstream has been hostile to including this previously. So I have little faith for it to be included without it being explicitly enabled by a configure flag, if at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where was this proposed before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the actual upstream thread where the guix developers talked to gnutls. The gnutls people don't really argue against the patch, they just mention that they think using pkcs11 is a better idea. Not sure if that is applicable for us, if I understand that correctly that needs a central service (hard on non-nixos). But upstream never really said "no that patch is a no-go because...".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes having a service would defeat the motivation we had in the first place.
I managed to miss this one (well, I can't remember now anyway). We stumbled into this now due to Darwin, and I implemented a slightly different patch (before noticing this PR):
Let me (tentatively) close in favor of #58611 |
Motivation for this change
At the moment, GnuTLS programs from Nixpkgs will not always work on non-NixOS systems. This patch resolves the issue by providing pure
cacert
at configure time.GnuTLS doesn't have an equivalent of
SSL_CERT_FILE
, it would be nice to patch that in.Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)