The only hope is that people will start to see these racist, genocidal, slave-owning assholes for who they are. They belong in the same corner of history as trump.
Yeah, that thread about looking up people's skirts was just insanely disgusting, it made me ashamed to share a social network with those people. The Grande one was quite bad as well. It's making me rethink Lemmy usage, maybe I should just quit social media altogether.
During this war statements from the Iranian government have generally been true, especially if compared to the waves of self-contradictory bullshit flowing from the US. Of course during a war no side will be completely honest and open about everything, but Iran has been more trustworthy than the west so far.
It's not about the license in this case, but about the admin overhead of auto-contributing changes (you need to set up a special account and write a detailed wiki page about what you're doing).
Video consoles are either desktop computers with proprietary parts, or tablets with proprietary parts. There is nothing especially difficult to repair in them compared to the rest of their categories.
Well, in that case remember to force everyone to use the same Nixpkgs version (otherwise you'll still end up with a lot of duplicated packages), and run nix-store --optimise; nix-collect-garbage -d regularly (ideally via cron or something).
I'd like to note that the 4 points are not separate issues, they are all requirements in order for an attacker to get access.
I’m not too worried about hash squatting, I guess there’s no way around it, but other ways of managing packages have way worse flaws than that.
"hash squatting" is not really an issue on its own. Unless an attacker can breach the sandbox, given the same derivation hash, the resulting derivation output would be the same regardless of which user requested the build.
I do want my users to be able to build packages. In most cases I imagine we’ll use pre built packages, but often packages available are not optimized for certain architectures.
Actually, Nix without the ability to build derivations would just be useless. In Nix, everything is a derivation, even if you just want to have multiple packages installed into your user profile at once, behind the scenes it's a derivation which simply combines binaries from multiple other derivations, which will not be available in the remote cache and needs to be "built" (in the most trivial sense possible) locally.
How does the nix sandbox work? Just so I know what I’m working with. Do you know where I can read about it?
You can think of the Nix sandbox as a kind of lightweight container, into which Nix mounts all the dependencies needed to build the derivation (including source code and such), and then runs the builder command. On Linux it is using User Namespaces (and a few other sandboxing tools), in a similar way to what Docker does (in fact there is some work to use runc as a sandbox backend but it's not usable yet). I don't know if it's described in a lot of detail anywhere, but a brief description is available in the manual.
Does root actively run installed packages at any point? If that is the case I’d be a bit wary to use nix for this purpose.
Once again, just random packages in Nix Store are not "installed" in any real sense. In order for any user (incl. root) to install/run something, they have to be the one explicitly doing it, e.g. via nix profile install or nix shell. That also means that if you're not using NixOS, you can actually just not do anything as a root user and then no code from /nix/store will be executed with root privileges at all.
To reiterate, unless your threat model involves sophisticated attackers[^1], users installing packages with Nix is as secure as them just building code from source manually, or dropping binaries into their own $HOME/.local/bin. One user installing a package into their profile does not affect other users or root in any way.
From what I can tell from your other replies, you are setting up a common build server with your coworkers. In that case I'd say it's 100% fine, both workplaces where I've been doing Nix work had a server like this, there were never any issues with privilege escalation or malware spreading between users.
[^1]: The attackers need to have access to an unpatched 0-day Nix sandbox breach or a critical nix-daemon issue, which is very unlikely. If that makes you feel any safer, I know that Nix has been scanned for vulnerabilities by at least one frontier-class LLM with no such vulnerabilities discovered, so just a script-kiddie with access to ChatGPT won't be able to find anything like that.
That's obviously wrong. I don't need to read Mein Kampf to know that nazism is a bad idea. Sure, it helps, but it's not necessary.
Similarly, I don't need to read the entire corpus of christian theology to understand that the bible is mostly fiction and that christofascists are wrong and awful people (don't get me wrong, those are two separate facts - I don't think all christians are awful).
Nothing is actually "installed as root", except for stuff that the root user installs themselves. The Nix Store (where all the "derivations"/packages are stored) can be thought of more as a cache, just because a package is there doesn't mean it's used anywhere. Users don't get to choose the cache "key" (i.e. the directory name in /nix/store) either - it is determined by all the build instructions and dependencies needed to build the package, and Nix doesn't (well, at the very least shouldn't) give users any control about the package build process after it starts.
When users install something, Nix fetches or builds that package into /nix/store - which doesn't affect other users in any way - and then just symlinks that particular package into some user-owned directory in their $PATH (e.g. $HOME/.local/share/nix/profiles/default or so), which also doesn't affect root or other users in any way.
So, basically, if some user installs malware only they are affected - the fact that it's also in the shared /nix/store is irrelevant since there's nothing in other user's profiles or $PATH or whatever that references it in any way.
The most likely vulnerability is something like this:
The attacker guesses the nix store path of some package that root will use in the future (e.g. glibc from a more up-to-date Nixpkgs version compared to what root currently uses) - note that users can't replace a derivation that's already in the store, so they need to guess a future derivation path
The attacker forces Nix to build that package from source instead of fetching from a trusted substituter
The attacker finds a way to breach Nix's sandbox during the build and inject their own backdoor into the resulting package ← this is the difficult part, there are currently no such known sandbox holes
The attacker then waits until root starts using that package in the store, at which point the backdoor becomes actively ran as root.
I must add that this is theoretical and I don't think has ever happened in practice on a multi-user system.
Sorry, I'm pretty bad at explaining stuff, hopefully it makes some sense :)
Also, sadly this is not that real passport. You can tell (at a minimum) because the first machine-readable passports were issued in 1980, and Egypt didn't start issuing MRPs until 2008.
The first one I could actually solve myself without hints or looking stuff up...
The only hope is that people will start to see these racist, genocidal, slave-owning assholes for who they are. They belong in the same corner of history as trump.
Yeah, that thread about looking up people's skirts was just insanely disgusting, it made me ashamed to share a social network with those people. The Grande one was quite bad as well. It's making me rethink Lemmy usage, maybe I should just quit social media altogether.
Honestly nothing wrong with that, not my cup of tea but content like that definitely has an audience...
During this war statements from the Iranian government have generally been true, especially if compared to the waves of self-contradictory bullshit flowing from the US. Of course during a war no side will be completely honest and open about everything, but Iran has been more trustworthy than the west so far.
It's not about the license in this case, but about the admin overhead of auto-contributing changes (you need to set up a special account and write a detailed wiki page about what you're doing).
Yes, fair.
I think kickback is like a small party https://www.urbandictionary.com/define.php?term=kickback
Impossible, COMMIE SOLAR PANELS don't work AFTER THE SUN SETS so this is ANOTHER DEMOCRAT LIE.
If he ever invited Vance to the house, I would just never look under couch cushions ever again if I was him.
Computers could make cars a lot more reliable and moddable. It's proprietary/locked-down software and hardware that's the problem.
I would hope that the Switch falls under "Tablets". Because that's exactly what it is.
Video consoles are either desktop computers with proprietary parts, or tablets with proprietary parts. There is nothing especially difficult to repair in them compared to the rest of their categories.
Well, in that case remember to force everyone to use the same Nixpkgs version (otherwise you'll still end up with a lot of duplicated packages), and run
nix-store --optimise; nix-collect-garbage -dregularly (ideally via cron or something).I'd like to note that the 4 points are not separate issues, they are all requirements in order for an attacker to get access.
"hash squatting" is not really an issue on its own. Unless an attacker can breach the sandbox, given the same derivation hash, the resulting derivation output would be the same regardless of which user requested the build.
Actually, Nix without the ability to build derivations would just be useless. In Nix, everything is a derivation, even if you just want to have multiple packages installed into your user profile at once, behind the scenes it's a derivation which simply combines binaries from multiple other derivations, which will not be available in the remote cache and needs to be "built" (in the most trivial sense possible) locally.
You can think of the Nix sandbox as a kind of lightweight container, into which Nix mounts all the dependencies needed to build the derivation (including source code and such), and then runs the builder command. On Linux it is using User Namespaces (and a few other sandboxing tools), in a similar way to what Docker does (in fact there is some work to use
runcas a sandbox backend but it's not usable yet). I don't know if it's described in a lot of detail anywhere, but a brief description is available in the manual.Once again, just random packages in Nix Store are not "installed" in any real sense. In order for any user (incl. root) to install/run something, they have to be the one explicitly doing it, e.g. via
nix profile installornix shell. That also means that if you're not using NixOS, you can actually just not do anything as a root user and then no code from/nix/storewill be executed with root privileges at all.To reiterate, unless your threat model involves sophisticated attackers[^1], users installing packages with Nix is as secure as them just building code from source manually, or dropping binaries into their own
$HOME/.local/bin. One user installing a package into their profile does not affect other users or root in any way.From what I can tell from your other replies, you are setting up a common build server with your coworkers. In that case I'd say it's 100% fine, both workplaces where I've been doing Nix work had a server like this, there were never any issues with privilege escalation or malware spreading between users.
[^1]: The attackers need to have access to an unpatched 0-day Nix sandbox breach or a critical nix-daemon issue, which is very unlikely. If that makes you feel any safer, I know that Nix has been scanned for vulnerabilities by at least one frontier-class LLM with no such vulnerabilities discovered, so just a script-kiddie with access to ChatGPT won't be able to find anything like that.
That's obviously wrong. I don't need to read Mein Kampf to know that nazism is a bad idea. Sure, it helps, but it's not necessary.
Similarly, I don't need to read the entire corpus of christian theology to understand that the bible is mostly fiction and that christofascists are wrong and awful people (don't get me wrong, those are two separate facts - I don't think all christians are awful).
Well, IIRC The Hobbit was initially just a collection of bedtime fairy tales he made up for his children, of course it had inconsistencies.
Actually, thinking about it, that seems like a plausible source of the Old Testament as well...
Assuming you're talking about Nix the package manager,
Nothing is actually "installed as root", except for stuff that the root user installs themselves. The Nix Store (where all the "derivations"/packages are stored) can be thought of more as a cache, just because a package is there doesn't mean it's used anywhere. Users don't get to choose the cache "key" (i.e. the directory name in /nix/store) either - it is determined by all the build instructions and dependencies needed to build the package, and Nix doesn't (well, at the very least shouldn't) give users any control about the package build process after it starts.
When users install something, Nix fetches or builds that package into
/nix/store- which doesn't affect other users in any way - and then just symlinks that particular package into some user-owned directory in their$PATH(e.g.$HOME/.local/share/nix/profiles/defaultor so), which also doesn't affect root or other users in any way.So, basically, if some user installs malware only they are affected - the fact that it's also in the shared
/nix/storeis irrelevant since there's nothing in other user's profiles or$PATHor whatever that references it in any way.The most likely vulnerability is something like this:
I must add that this is theoretical and I don't think has ever happened in practice on a multi-user system.
Sorry, I'm pretty bad at explaining stuff, hopefully it makes some sense :)
Also, sadly this is not that real passport. You can tell (at a minimum) because the first machine-readable passports were issued in 1980, and Egypt didn't start issuing MRPs until 2008.
Given the word "prototype" it probably doesn't have any sort of flight certification or approval. So it's basically a futuristic garden ornament.