[Nix-dev] is there something like unsafeImpureEnvVars?

[Ben Franksen]

Shea Levy wrote:
> Fetching source over the network is the main reason fixed output
> derivations even exist. When chroot builds are enabled, networking is not
> allowed for non-fixed output derivations.

Interesting, I did not know this.

I agree that this policy makes sense for stuff that gets downloaded from the 
internet, and especially if you base a complete linux distribution on it 
(security considerations: you want to make sure that the source has not been 
tampered with).

> Why is this case special?

The repo server is in-house, and we talk about ssh access, limited to the 
trusted maintainers of the code base. The level of security here is arguably 
better than using an NFS share (which would appear as a local path to Nix 
and thus allow unrestricted (non-fixed output) derivations even with chroot 
builds if I understood you correctly... or maybe not, depending on whether 
the share gets bind-mounted into the builder's environment or not).

We have many modules in many versions. I was hoping I could avoid to list 
each and every one of them in our "local" nix expression tree, and instead 
(mostly) rely on functions that get the version number as a parameter.

But I must admit: I am half convinced that relying on module name and 
version alone to correctly identify a source may not be strong enough to 
actually *guarantee* consistent and repeatable builds, even in our limited 
setting.

Cheers
Ben

>> On Apr 13, 2014, at 16:03, Ben Franksen <ben.franksen at online.de> wrote:
>> 
>> Hello
>> 
>> Is there *any* way (besides hacking the Nix source code) to circumvent
>> the limitation on impureEnvVars, i.e. that one has to provide the hash up
>> front, making the derivation fixed-output? What I am asking for is
>> something akin to unsafePerformIO in Haskell (which exists for similar
>> situations, and motivated the name unsafeImpureEnvVars in the subject).
>> 
>> Effectively I want to be able to say to Nix: "I swear these variables are
>> used in a pure way, just believe me."
>> 
>> Background:
>> 
>> I want to use fetchdarcs for remote repositories via ssh; we use darcs to
>> version control our software internally (even stuff we get from the
>> outside, to track patches for customisation and bug fixes). We use tags
>> to identify versions and have lots of darcs repos, all on a single
>> server, accessible to developers via ssh.
>> 
>> Unfortunately, fetchdarcs fails in this case because, to avoid being
>> asked for a passphrase, ssh (in this case called via darcs) needs to know
>> how to access a runnig ssh agent, and this knowledge is encoded in two
>> environment variables: SSH_AGENT_PID and SSH_AUTH_SOCK. But of course
>> these are not defined in the builder, its environment gets cleared before
>> it starts.
>> 
>> Now, there is the attribute impureEnvVars. But that works only if you
>> pass the expected hash to the builder (so the derivation becomes
>> fixed-output). That means either I hard-code the expected hash into the
>> derivation, or pass it as an argument. In both cases, I need to find out
>> the hash before-hand. This makes it very inconvenient for users to add
>> new version of packages.
>> 
>> Note that this is *only* because of the two environment variables. I can
>> use fetchdarcs just fine with any local path or remote http url without
>> providing any hash.
>> 
>> Note also that use of these variables does not imply any impurity, they
>> are only used for authentication.
>> 
>> Cheers
>> Ben
>> --
>> "Make it so they have to reboot after every typo." -- Scott Adams
>> 
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
-- 
"Make it so they have to reboot after every typo." -- Scott Adams