[Nix-dev] Failure trying to build node package

[Wout Mertens]

On Mon, Oct 6, 2014 at 3:52 PM, Nikolay Amiantov <ab at fmap.me> wrote:

>
> On 10/06/2014 03:36 PM, Wout Mertens wrote:
>
>> Ok, weird. Try also setting OPENSSL_X509_CERT_FILE to that file?
>>
> OPENSSL_X509_CERT_FILE was originally set to same path as GIT_SSL_CAINFO.
> Setting it to /home/... did no effect.
>
>> So this error means that it can't verify the certificate. Normally, with
>> GIT_SSL_CAINFO it should be able to find it :-/ Perhaps npm removes the
>> environment variable?
>>
> A quick grep showed that at least it doesn't fiddle with these variables
> at least, though it can clean the environment completely. It would be
> strange, though -- it then would need to set this variables, and grep found
> nothing.
>
>> I see that you can clone it yourself, can you try under `nix-shell -p git
>> --pure` as well?
>>
> Can't verify the certificate. Setting GIT_SSL_CAINFO helps.


Solution: => https://github.com/npm/npm/pull/6442

Also, git should have this wrapped.


> However, how do you handle openssl? It's a library so you can't use a
>> shell wrapper and it needs OPENSSL_X509_CERT_FILE. Should that go into user
>> environment, into the wrapper for all programs that depend on openssl, or
>> should we create a wrapper library that loads the library with the correct
>> environment set (hmm interesting idea but still requires rebuilding things
>> that depend on it)?
>>
>

> To tell the truth, I've started thinking about it after sending a reply.
> When we use nix stand-alone, do we require user to load some kind of
> environment? I've arrived to the last option (wrapper libraries, I've even
> done something like that), but I haven't thought of rebuilding problem.
> What's the problem with containing it within user environment?


Yes, the user has to source ~/.nix-profile/etc/profile.d/nix.sh. This adds
the user environment to the path. It doesn't include the environment
variables that NixOS defines.

If you contain it in the user environment, the environment variables are
fixed at shell-load-time. In NixOS this could be the start of your desktop
session, on bare nixpkgs it is more likely to just be your terminal.

If the settings need to change, the user needs to logout.

If you use wrapper scripts and libraries, the settings are changed at
runtime, so if you install a new wrapper, new invocations will use the new
settings. However new wrappers mean new inputs and thus rebuilding, which
is exactly why tzdata is not a defined input of glibc but only available
through the environment.

Do we support "different tzdatas" and "different certfiles" on the system?
>
>
Different tzdata doesn't make much sense IMHO, but different certfiles
does, because people don't all trust the same certificates.


> If not, then I would use "$HOME/.nix-profile/etc/tzdata", which would be
>> a symlink to the real tzdata. That would work on NixOS and other
>> distributions as well. I just had an idea of using that to store some kind
>> of "environment", which could be read by LD_PRELOADed or dynamically linked
>> extra library (which may avoid rebuild, then), or nix-shell, for example.
>> This would solve the problem with certificates. Advantages of the first
>> solution is that we have no need to set the environment before running any
>> executable, but I don't like this approach for the need of load some extra
>> library that would use __constructor -- that looks "hacky" for me.
>
>
I don't like LD_PRELOAD at all, it doesn't work on static binaries for
example. A wrapper library that dl_open()s the wrapped library after
changing its environment is better, but not sure if changing processes'
environment variables while they're running is a good idea.

Basically, we strive for compile-time binding of all inputs. This means
that for any change we might have to rebuild the entire system.
As a first optimizing approximation, we create wrappers instead of
hardcoding configuration files.

I noticed that the nix.sh environment script now sets the SSL_CERT_FILE
environment variable. Perhaps there are so few cases that they can all be
hardcoded there. And then git (which has a wrapper anyway) can use that
variable to set its own GIT_SSL_CAINFO.

Wout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20141009/394b74b4/attachment.html