Nixpkgs: curl doesn't work in nix-shell because of $SSL_CERT_FILE=/no-cert-file.crt default

Created on 7 Mar 2016  路  20Comments  路  Source: NixOS/nixpkgs

  • Kernel: Linux nixos 4.4.2 #1-NixOS SMP Wed Feb 17 20:31:25 UTC 2016 x86_64 GNU/Linux
  • Nix version: nix-env (Nix) 1.11.2
  • Nixpkgs version: 16.03pre77568.40c586b

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.

enhancement

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, 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.

All 20 comments

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:

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  路  3Comments

langston-barrett picture langston-barrett  路  3Comments

chris-martin picture chris-martin  路  3Comments

domenkozar picture domenkozar  路  3Comments

tomberek picture tomberek  路  3Comments