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.

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/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:

1. 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
2. The attacker forces Nix to build that package from source instead of fetching from a trusted substituter
3. 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
4. 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 :)

In that case, what are they doing to college for?

But also the problem is that they cheat.

Using AI is easy, as you note. You don’t need to go to college to learn to do that.

College can give you many useful skills, mostly related to gathering and processing information, and applying it to solve various issues. If you just copy-paste every question into AI and then copy-paste the answer back, you will learn absolutely nothing.

LLMs hallucinate and there’s nothing we can do to stop them. No amount of QA will fix that fundamental issue of “the LLM is somewhat likely to confidently produce incorrect information”, if you need the answer to be correct you have to do the research yourself, maybe based on the sources the LLM provided, not just sanity-check the output. This is a very useful skill to have for many jobs involving thinking or finding stuff out.

And even if we fix the hallucinations at some point by switching to a different tech (LOL), I do think it’s useful for people to keep some mental skills. Otherwise we will end up with a stupidity and/or dementia epidemics, similar to cars causing an obesity epidemic.

Died as a war criminal fighting for pedophiles, remembered as a consoomer of capitalist glop. True american.

I’d like to add my perspective.

I’m not very anti-AI, I use a locally run model to help me write code (especially boring stuff).

For me it’s mostly about “is it worth the time to package this thing in Nixpkgs, add it to my config, and get used to how it works?”

And for vibecoded projects, even if they work now, the answer is “probably not”; more specifically it’s “let’s look if it’s alive in a year, if I’m still interested”.

As such, I really appreciate when people add a disclaimer so that I don’t have to go look at the code only to be disappointed - I also appreciated it back in the day when someone said “this is my first real project” or something, for similar reasons.

And secondly it’s a question of trust. If the author doesn’t disclose such basic things about the way the project has been developed, and in fact avoids answering when asked directly, what other potential problems could there be semi-hidden in the codebase?

At the risk of stating the obvious, I would like everyone to know that https://www.shellcheck.net/ exists. Unless you are a bash wizard: if your bash script doesn’t pass shellcheck, it is very likely to have bugs.

I think the key point with Linux is that at least no single corporation has enough control over it to dictate the direction of the project on its own. Sure, modern Linux is fairly corporate and somewhat beholden to capitalist interests in general, but there’s a lot of different actors pulling things in different directions, and the community (by that I mean non-corpo interests) still plays a role in decision making.

I didn’t vote to put Linux in AI servers, defense projects, Teslas

The definition of FLOSS mandates that software authors relinquish control over how and by whom their software is used, see for example the JSON licensing controversy. But I agree that we should rethink this somewhat libertarian approach and at least try to prevent our software being used for evil.

I didn’t choose to ban devs based on their nationalities

Yeah that one was a yikes. Especially given it wasn’t even prompted by any legal threats, it was just the Linux devs complying with an unjust law prematurely.

I’d be pretty wary of allowing MIT kernel modules.

Wait, is that a thing?? Unless you mean the out of tree modules, in which case the MIT ones are not the worst offenders (looking at you NVidia)

Ok, so there’s no statistically rigorous review yet, but 73% of LLM-generated apps submitted to FlatHub were abandoned within 6 months. This is about the abandonment rate you should expect to see on any newly announced LLM-written project, and this figure appears to be much higher than hand-written projects (e.g. this study, while not directly comparable, shows a 16% abandonment rate).

The reason for this is sort of obvious to me: an LLM makes it really easy to write code that makes an app work, therefore the threshold of involvement/interest needed to “make an app” is much lower. This in turn removes the selection force that makes software authors likely to be interested in, and thus put in the effort (or tokens) to maintain their software going forward. (this is putting aside the fact that LLMs are still horrible at software architecture and quite bad at infrastructure, making the long-term maintenance more difficult).

I don’t doubt that some people will have a lot of passion for their vibecoded thing, and will keep it going for a while. This might even be the case here given the author went out of their way to post about it on Lemmy and respond to comments, seemingly without an LLM in the loop at that stage of the process. But it’s also important to disclose your LLM use so others can adjust their statistical expectations.

anecdotally, I’ve built a lot of projects and abandoned them because I ran out of time. With an LLM to reduce the input effort I actually think I would’ve maintained them longer.

Likely you would have also built more projects if you had access to an LLM, thus giving you less time to spend maintaining each individual one. Which is kind of the problem here…

They are here to stay, but stuff built with an LLM is statistically way less likely to be maintained for more than a couple months compared to a hand-written thing. Anecdotally I also feel it’s way more likely to have security issues. So I think it’s important to disclose so people have their expectations set correctly.

Eh, for sure corporations do contribute a lot to every major FOSS project out there. I don’t expect huge, versatile codebases to be maintained by volunteers lemmy-style, and corpos are the dominant organization kind under the capitalist mode of production, so of course they will have the resources to have a foot in every door.

But the key differentiator is how much control any single entity has over the project’s code, maintenance and infrastructure. On one side of the spectrum there’s stuff like Rust or ffmpeg or GNU which are being pulled in various directions by various corpos and the community, on the other there’s stuff like Chromium and AOSP where Google unilaterally controls everything. Projects like Linux or Firefox fall somewhere in the middle. We desperately need more projects to be of the first kind, and I feel like to achieve this projects should go as far as to ban donations over a certain amount and limit the number of contributors affiliated with a single organization. “Avoid success at all costs” is my single favorite rule of FOSS building, and it should be applied to technical, financial and organizational decisions all the same.

FYI there’s a semi-dead fork of OsmAnd called OffRoad which runs on desktop OS’s, including Linux. But it’s a bit borked and doesn’t support most of the cool features.

It was indeed broken, fixed now.

If you decide to actually go for it, in order to get it to compile I did something like this:

nix-shell
mkdir build && cd build
cmake ..
cmake --build . -j$(nproc)
wrapQtApp bin/CarNavigation
NIXPKGS_QT6_QML_IMPORT_PATH=/nix/store/66hlc66dkinbrc7ifq0v6ynaq3vkv35y-maplibre-native-qt-3.0.0/qml bin/CarNavigation

(I’m not sure why the wrapQtApp doesn’t pick up maplibre, maybe it’s something to do with the patches they apply, didn’t have time to investigate. I also didn’t have the time to investigate what is needed to get it “installed”, hence to installPhase and nix-build doesn’t work)

Yeah, it doesn’t have downloadable maps or offline routing (at least yet). It does however cache the map tiles it downloaded, and it seems to also cache some POIs (e.g. I can see opening hours for shops around me even without the internet).

After some finaggling I managed to compile it (here’s the nix file I used to get the dependencies). It’s looking basic but actually promising! Here are some screenshots (sorry for potato quality, it’s the only one Lemmy allows me to upload at for some reason):

The search seems quite nice, it seems to search by names but also allows to search for (some?) OSM tags, e.g. amenity:drinking_water shows up water fountains around you. I’m actually annoyed that other apps don’t allow you to do so this easily.

The navigation also seems to work-ish, which is surprising for such a young app. The only remaining things before it’s really useful is downloadable maps and offline routing.

AOSP is controlled and maintained by a single bad-faith entity. We need a community-maintained, community-led replacement ASAP.

I’m not sure about the target though, amateurs working on their car or restoring old models?

Yeah, personally I’d be their target audience, if they announce it soon enough and it doesn’t cost an arm and a leg. I can also see some european manufacturers looking to decouple from the US tech being somewhat interested.

They may be working on a Linux-based car head unit, which is kinda between a phone and a laptop (like a tablet, which it basically is). If that’s the case, something like this would be a required app, and current (non-android) Linux offerings are somewhat limited (basically it’s just PureMaps and a couple forks, which all work but are a bit janky). If they end up with something useful, it would be great for both phones and cars.

Yes, exactly, I mention it in my comment. It almost did the right thing and blundered in one detail.