okay so. nix 2.24+ vuln: nar unpacking is fucked, and local unprivileged users, or any binary cache you have configured, can just Get Root on your systemif you create a nar file with a directory containing both a symlink and a directory with the same name, the symlink will be followed and filled with the contents you put in that directory due to a refactoring mistakeand, as the nix daemon usually runs as root (with the nix store mounted read-write), it's possible to write files into e.g. /run/current-system/etc/systemd/system. and as such, and get persistent root access from unpacking a malicious NAR.now do you make Nix read a NAR? well... there's two primary waysany untrusted user that can talk to the nix daemon can write NARs that are either content-addressed, or signed by a trusted key, into the Nix store;...and any binary cache can do this as well, as the daemon will fetch nar files from the binary cache.now this vuln would be evil but local privesc only if this was all, except for a very funny second issue:the signature on NAR files is validated only *after* unpacking the NARso any malicious binary cache can reuse the signature of, say, a store path on cache.nixos, and (this is very likely, of course) if the nix daemon trusts the signature, it will end up unpacking any nar of the cache's choice without checking that the signature (or even hash!) matchesin certain cases (e.g. there's a symlink pointing to root in a trusted nar) this can even be done entirely silently, which is .. very bad.at this point the disclosure timeline has passed; and a point release was even made after the vulnerability was well known by the entire team (GHSA-h4vv-h3jq-v493 was opened a day before the point release); and the severity of the vulnerability is high enough that i want people to be aware of this issue(it's possible to mitigate this issue by downgrading to Nix 2.23, or setting allowed-users to only trusted users; and making sure any binary caches you have set are https and very trusted.)