<gchristensen>
I think ofborg's evaluation is totally safe?
<gchristensen>
no?
<Mic92>
gchristensen: yes, I think about how safe my evaluation for NUR has to be.
<gchristensen>
AH
<gchristensen>
ehhhh I don't know!
<gchristensen>
well
<gchristensen>
do you feel comfortable running arbitrary builds at eval time?
<Mic92>
if it is on travis, this should be fine. But I think of users running the same tools locally.
<gchristensen>
yeah I don't love that
<gchristensen>
Nix's sandboxing should be very good
<Mic92>
So mean, just but it into the sandbox and everything is good?
<gchristensen>
should be :$ but probably lots of users don't have sandboxing on
<gchristensen>
so I guess seems not good
<Mic92>
but they would only get versions that have checked by the sandbox version first.
<gchristensen>
ah
<gchristensen>
your tool could test for sandboxing first too
<gchristensen>
but still, even with sandboxing an attacker can do scary stuff from a FO dr/
<gchristensen>
drv
<Mic92>
However it might be still possible for code to behave differently if it is running in a sandbox or not.
<Mic92>
code just need to check environment variables
<Mic92>
So I need to build my tools so that they will always require a sandbox.
<infinisil>
A simple way to get around any such check: builtins.currentTime
<infinisil>
Just alter the returned derivation if a certain time has passed, preferably after the check happened
<infinisil>
Ultimately NUR will have to be an untrusted source
<Mic92>
I just want to draw the line between what is safe to use and what not.
<Mic92>
and make review easier
<gchristensen>
if I were you, I'd say IFD is off-limits
<Mic92>
in archlinux most AUR-helpers offer a way to view the PKGBUILDs before building.
<gchristensen>
but I know why you would want it to be okay
<Mic92>
What does IFD stands for?
<gchristensen>
import from derivation
<infinisil>
,IFD
<{^_^}>
import-from-derivation (IFD) is when you evaluate nix from a derivation result, for example `import (pkgs.writeText "n" "1 + 1")` will evaluate to 2
<LnL>
there's a nix.conf option to entirely disable IFD, even for paths in NIX_PATH, etc.
<Mic92>
If evaluation was restricted to the NIX_PATH, how would be IFD harm more then plain evaluation?
<Mic92>
s/then/than/
<FRidh>
doesn't pure evaluation mode check whether sandboxing is used?
<infinisil>
Mic92: How about this: allow repos to have a special derivation which builds a json file. The NUR CI will build that derivation first (with sandbox and everything) and pass the resulting json as an argument to the repos declarations, which they can then use to do fancy stuff
<infinisil>
No IFD needed, we basically emulate one layer of IFD ourselves
orivej has quit [Ping timeout: 240 seconds]
<gchristensen>
what does that buy?
<infinisil>
gchristensen: Allows a form of verified IFD, without having to enable IFD
<Mic92>
FRidh: do you know if pure-eval forbids environment variables?
<infinisil>
Oh and: The json generated from the special drv will be distributed as part of the NUR repo, so it won't be built by anybody's machine
<infinisil>
So it gets regenerated every time NUR updates
<samueldr>
a kind of cached one-tier ifd then?
<infinisil>
Yup
<gchristensen>
sounds annoying to test and dev locally :$
<gchristensen>
I think you should just turn on IFD
<gchristensen>
nix won't build the IFD for things not requested
<Mic92>
infinisil: why would NUR need to build stuff, if the users could do that themselves
<gchristensen>
(right?)
<gchristensen>
and the user will be trusting the expr authors anyway
<gchristensen>
so might as well IFD
<LnL>
Mic92: even tho it's restricted to NIX_PATH, with IFD evaluation still has write access to the store
<Mic92>
gchristensen: I only need to adjust my tooling because at the moment, I ask users to run the update.py script to check when adding a repository, whether there repository evaluates.
<Mic92>
and this checks all other repositories as well
<infinisil>
Mic92: This makes it more trusted in a way: NUR builds the special drv and uses that to verify the rest of the drvs. With IFD you could do a lot of stuff that opens security holes and non-reproducability
<infinisil>
And no IFD at all is rather inconvenient. So this solution would be a compromise between the 2
<infinisil>
An example of what this json drv could be used for: The nixpkgs-mozilla repo would have to be rewritten to put the fetching of the version information into this special drv, then use that in the rest to build the actual things
<infinisil>
Enabling IFD would be easier, but also less secure
<infinisil>
and reproducible of course
<Mic92>
but why this would be need to be builded by NUR, when the users could build it themselves?
<infinisil>
Hmm.. restrict-eval..
<infinisil>
It's a way of avoiding having to enable IFD but still providing some features
<infinisil>
Namely, you can build a json from a derivation and import that into nix again
<infinisil>
I guess IFD isn't too bad though, probably better to just enable it
<infinisil>
This yarn2nix thing is a problem with restrict-eval though, which should probably stay enabled, but allow all internet URI's
<Mic92>
ah the problem is fetchGit without a checksum here.
<infinisil>
Oh yes
<gchristensen>
you can delete the fetchGit builtin :D
<LnL>
yeah, I have something that does some super weird stuff to figure out the arguments to fetchGit, etc. of an existing expression