There are many places where a thrown `std::logic_error` is handled like
a normal error, making it very difficult to get a good stack trace so
we can fix that logic error.

So, we wrap the __cxa_throw function such that we can check if the thrown
exception was a `std::logic_error`, and if so, abort the process so we
can figure out exactly where it happened.

Co-authored-by: Eelco Dolstra <edolstra@gmail.com>

This error no longer seems to occur on Linux 6.19+ anymore. Skip in that
case to fix build.

Example:

  Aborting on unexpected exception of type 'St16invalid_argument', error: bitset::_M_copy_from_ptr

Abort when throwing std::logic_error

…le-test

tests/functional/stale-file-handle: Skip if the error doesn't happen

builtins.wasm: Support WAT, add a test

`nix provenance`'s category was rendered twice because the call to
`unique` took its experimentalFeature field into account.

Change `nix provenance` category

An interrupted `git fetch` can leave behind a `shallow.lock` file
which causes subsequent fetches to fail. Since Nix already has a
PathLock on the repo, it should be safe to just delete this file.

nix develop: Respect legacyPackages

Remove shallow.lock before running git fetch

This prevents multiple processes (like nix-eval-jobs instances) from
fetching the same input at the same time. That doesn't matter for
correctness, but it can cause a lot of redundant downloads.

(cherry picked from commit ff022d8)

The lookupPathResolved cache was a plain unordered_flat_map with
unsynchronized find()/emplace() calls in resolveLookupPathPath().
Multiple threads resolving lookup paths concurrently would race on
this cache.

Replace it with a concurrent_flat_map following the same pattern used
for srcToStore, importResolutionCache, and fileEvalCache.

(cherry picked from commit 04516ac)

Input::getAccessorUnchecked(): Wrap fetches in a path lock

Fix lookupPathResolved thread safety

(cherry picked from commit 0e3412a)

…e output in a temporary directory in the store

Puts the temporary FOD output copies in a temporary directory inside the
store instead of the (for Linux sandboxed builds) chroot.
This prevents file overwrite due to symlink following that std::filesystem::copy_file does.

Also applies the same output copying approach for impure derivations that don't
have network sandboxing and thus are subject to FD smuggling.

Fixes GHSA-g3g9-5vj6-r3gj.

(cherry picked from commit a760af8)

…ew enough kernels

This partially fixes the issue with cooperating processes being able
to communicate via abstract sockets. The fix is partial, because processes
outside the landlock domain of the sandboxed process can still connect to
a socket created by the FOD. There's no equivalent way of restricting inbound
connections. This closes the gap when there's no cooperating process on the host
(i.e. 2 separate FODs).

>= 6.12 kernel is widespread enough (NixOS 25.11 ships it by
default) that we have no reason not to apply this hardening, even though
it's incomplete.

ca-fd-leak test exercises this exact code path and now the smuggling
process fails with (on new enough kernels that have landlock support enabled):

vm-test-run-ca-fd-leak> machine # sandbox setup: applied landlock sandboxing
vm-test-run-ca-fd-leak> machine # building '/nix/store/s7brgi6pdr5f3n8yqlgmdlz8blb89njc-smuggled.drv'...
vm-test-run-ca-fd-leak> machine # building derivation '/nix/store/s7brgi6pdr5f3n8yqlgmdlz8blb89njc-smuggled.drv': woken up
vm-test-run-ca-fd-leak> machine # connect: Operation not permitted
vm-test-run-ca-fd-leak> machine # sendmsg: Socket not connected

(cherry picked from commit 44017ca)

…a79-b80a-4b64-b2a7-a7816356cef4

Release v3.17.3

CI: Do the static build in a separate job