On Mon, Oct 6, 2014 at 3:52 PM, Nikolay Amiantov <a...@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.
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
