| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
We shouldn't pollute stdout.
|
|
|
|
|
|
|
|
This is already done by coerceToString(), provided that the argument
is a path (e.g. 'fetchGit ./bla'). It fixes the handling of URLs like
git@github.com:owner/repo.git. It breaks 'fetchGit "./bla"', but that
was never intended to work anyway and is inconsistent with other
builtin functions (e.g. 'readFile "./bla"' fails).
|
|
Using a 64bit integer on 32bit systems will come with a bit of a
performance overhead, but given that Nix doesn't use a lot of integers
compared to other types, I think the overhead is negligible also
considering that 32bit systems are in decline.
The biggest advantage however is that when we use a consistent integer
size across all platforms it's less likely that we miss things that we
break due to that. One example would be:
https://github.com/NixOS/nixpkgs/pull/44233
On Hydra it will evaluate, because the evaluator runs on a 64bit
machine, but when evaluating the same on a 32bit machine it will fail,
so using 64bit integers should make that consistent.
While the change of the type in value.hh is rather easy to do, we have a
few more options available for doing the conversion in the lexer:
* Via an #ifdef on the architecture and using strtol() or strtoll()
accordingly depending on which architecture we are. For the #ifdef
we would need another AX_COMPILE_CHECK_SIZEOF in configure.ac.
* Using istringstream, which would involve copying the value.
* As we're already using boost, lexical_cast might be a good idea.
Spoiler: I went for the latter, first of all because lexical_cast does
have an overload for const char* and second of all, because it doesn't
involve copying around the input string. Also, because istringstream
seems to come with a bigger overhead than boost::lexical_cast:
https://www.boost.org/doc/libs/release/doc/html/boost_lexical_cast/performance.html
The first method (still using strtol/strtoll) also wasn't something I
pursued further, because it is also locale-aware which I doubt is what
we want, given that the regex for int is [0-9]+.
Signed-off-by: aszlig <aszlig@nix.build>
Fixes: #2339
|
|
This reverts commit d277442df53a01343ba7c1df0bbd2a294058dcba.
Make sucks.
|
|
Fixes #2361.
|
|
Fun fact: rules with multiple targets don't work properly with 'make
-j'. For example, a rule like
a b: c
touch a b
is equivalent to
a: c
touch a b
b: c
touch a b
so with 'make -j', the 'touch' command will be run twice. See
e.g. https://stackoverflow.com/questions/2973445/gnu-makefile-rule-generating-a-few-targets-from-a-single-source-file.
|
|
|
|
Fix symlink leak in restricted eval mode
|
|
In EvalState::checkSourcePath, the path is checked against the list of
allowed paths first and later it's checked again *after* resolving
symlinks.
The resolving of the symlinks is done via canonPath, which also strips
out "../" and "./". However after the canonicalisation the error message
pointing out that the path is not allowed prints the symlink target in
the error message.
Even if we'd suppress the message, symlink targets could still be leaked
if the symlink target doesn't exist (in this case the error is thrown in
canonPath).
So instead, we now do canonPath() without symlink resolving first before
even checking against the list of allowed paths and then later do the
symlink resolving and checking the allowed paths again.
The first call to canonPath() should get rid of all the "../" and "./",
so in theory the only way to leak a symlink if the attacker is able to
put a symlink in one of the paths allowed by restricted evaluation mode.
For the latter I don't think this is part of the threat model, because
if the attacker can write to that path, the attack vector is even
larger.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
parser.y: fix assoc of -> and < > <= >=
|
|
|
|
The parser allowed senseless `a > b > c` but disallowed `a -> b -> c` which seems valid
It might be a typo
|
|
forceValue() were called after a value is copied effectively forcing only one of the copies keeping another copy not evaluated.
This resulted in its evaluation of the same lazy value more than once (the number of hits is not big though)
|
|
Apparently, on macOS, 'long' != 'int64_t'.
https://hydra.nixos.org/build/77100756
|
|
|
|
Closes #2282.
|
|
stored in mkApp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is primarily useful for processing Cargo.lock files.
|
|
Even on 32-bit systems, Value has enough space to hold a double.
|
|
This makes it possible to build with -DGC_DEBUG.
|
|
This reduces the risk of object liveness misdetection. For example,
Glibc has an internal variable "mp_" that often points to a Boehm
object, keeping it alive unnecessarily. Since we don't store any
actual roots in global variables, we can just disable data segment
scanning.
With this, the max RSS doing 100 evaluations of
nixos.tests.firefox.x86_64-linux.drvPath went from 718 MiB to 455 MiB.
|
|
|
|
This prevents EvalState::resetFileCache() from parsing everything all
over again.
|
|
|
|
|
|
|
|
json-to-value: Use strtol instead of strtoi
|
|
NixInt is long, so strtoi is too restrictive.
|
|
|
|
add builtins: __bitAnd, __bitOr, __bitXor
|
|
If the Env denotes a 'with', then values[0] may be an Expr* cast to a
Value*. For code that generically traverses Values/Envs, it's useful
to know this.
|
|
This prevents hydra-eval-jobs from statting the same files over and
over again.
|
|
|
|
|
|
|
|
|
|
Fixes #1374.
Closes #2129.
|
