when doing a nix-shell, curl doesn't work inside it for https uris (assuming curl is installed):
$ nix-shell -p --run "curl https://example.org"
curl: (77) error setting certificate verify locations:
CAfile: /no-cert-file.crt
CApath: none
The reason is, that we set SSL_CERT_FILE
in https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L387.
While this may be the right thing to do when creating builds, it clearly isn't the right thing when opening a nix-shell without --pure, at least when -p is used. I believe this should only be done when using --pure.
Workaround is to do unset SSL_CERT_FILE
.
This relates to nixos/nix#777
Can confirm that this is not only an issue with curl
, but for me also with git
and composer
(php), cargo
and maybe even some other tools.
Can someone please fix this?
Maybe even by reverting 39609a0c9414b398330e42f872e7358e30e133dd ?
I added some system information. This happens for me before 39609a0c9414b398330e42f872e7358e30e133dd, too. Indeed, with this new commit there's a new workaround to set SSL_CERT_FILE=/etc/ssl/certs/ca-bundle.crt
in configuration.nix
or something smiliar.
This seems to be a good workaround, since nix-build
etc. and nix-shell --pure
still behave as before (as they should) but nix-shell
doesn't override $SSL_CERT_FILE
.
Still it would be even better when this would work without setting SSL_CERT_FILE
.
This breaks cargo, too.
cc @wizeman, @edolstra
According to my reading of https://github.com/NixOS/nixpkgs/commit/39609a0c9414b398330e42f872e7358e30e133dd, the value of $SSL_CERT_FILE
that's set at the time nix-shell
is invoked get's preserved:
$ echo $SSL_CERT_FILE
/etc/ssl/ca-bundle.pem
$ nix-shell -p bash --run 'echo $SSL_CERT_FILE'
/etc/ssl/ca-bundle.pem
That seems like perfectly reasonable behavior, no?
@peti yes, but it doesn't work when SSL_CERT_FILE is unset.
Well, the thing is that nix-shell
cannot possibly know the right set of trusted CA certificates that you would like to use, so not using _any_ is a perfectly good choice, IMHO.
Well, we could do something, like don't set $SSL_CERT_FILE
when there's a $IN_NIX_SHELL
(which wouldn't exactly do the right thing either, because it also triggers in nix-shell --pure
).
I've now set
environment.variables."SSL_CERT_FILE" = "/etc/ssl/certs/ca-bundle.crt";
in configuration.nix
and that works quite well for me.
Maybe we should set something like that in default nixos.
There certainly is an asymmetry here in the way nix-shell
handles certificates. If you set $SSL_CERT_FILE
explicitly, then your settings are inherited and everything works as expected. If you don't set $SSL_CERT_FILE
, however, then you say, basically, that you want to use the defaults that have been compiled into the programs, but nix-shell
undermines that choice by setting $SSL_CERT_FILE
to a bogus location for you, thereby preventing tools like curl
from using their built-in default behavior. My intuition says that if $SSL_CERT_FILE
isn't set outside of nix-shell
, then it shouldn't be set inside of it either -- at least that seems like the most consistent behavior to me. Whether that choice would have other unintended consequences or not, I cannot say right now.
I think that we can skip setting SSL_CERT_FILE
if we are in a shell. It can certainly improve purity when we are actually building a package, because in general SSL libraries try to read CA bundles from standard locations so something from them might sneak into the result. On the other hand, nix-shell
is used for 1) development; 2) prelimitary testing of the build. In both of those cases having SSL certificates available is more desirable IMHO (we don't limit network in a shell, so why should we limit certificates?).
Also to be honest, I'm generally annoyed by having to run unset
each time I want to develop in a shell ~_~.
I suggest the following:
$IN_PURE_NIX_SHELL
in nix-shell which is set when we're calling nix-shell --pure
(in addition to $IN_NIX_SHELL)if [ -z "$SSL_CERT_FILE" -a ( -z $IN_NIX_SHELL -o -n $IN_PURE_NIX_SHELL ) ]; then
This way we get the desired behavior in nix-shell
while still being as pure as in a normal build when using nix-shell --pure
(which is to be expected when using --pure
).
Also, in the meantime, when people still use versions of nix
that don't have $IN_PURE_NIX_SHELL
yet, nix-shell --pure
wouldn't be as pure as it could be, but this bug would be fixed (which is more important IMHO).
Any progress in this?
This issue is still relevant.
Funny, I've bumped into this again right when you posted this comment.
+1
PR: #15571
hum when building a custom derivation (fcitx), curl fails with this error during a nix-build.
nix-build -A fcitx-master '<nixpkgs>'
while in nix-shell it was ok.
What would be the recommanded way to make the build work within nix-build ?
Note: the previous changes have now moved to these lines https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L458
Euh since a fix for this landed almost three years ago I think we can close this no? https://github.com/NixOS/nixpkgs/pull/15571
Most helpful comment
There certainly is an asymmetry here in the way
nix-shell
handles certificates. If you set$SSL_CERT_FILE
explicitly, then your settings are inherited and everything works as expected. If you don't set$SSL_CERT_FILE
, however, then you say, basically, that you want to use the defaults that have been compiled into the programs, butnix-shell
undermines that choice by setting$SSL_CERT_FILE
to a bogus location for you, thereby preventing tools likecurl
from using their built-in default behavior. My intuition says that if$SSL_CERT_FILE
isn't set outside ofnix-shell
, then it shouldn't be set inside of it either -- at least that seems like the most consistent behavior to me. Whether that choice would have other unintended consequences or not, I cannot say right now.