191–200 of 234 posts
Am I understanding right that machines without npm aren't affected by this particular strain? The headline got my heart going pretty good this morning.
Earlier quoted context omitted.
It isn't guaranteed that the list is conclusive. Always check PKGBUILD and sources, AUR is not to be trusted for the most part. I'm actually more surprised that such compromise hasn't happened earlier.
> hasn't happened earlier. it happens all the time Just not always on this scale and doesn't always end up on HN. Similar to how you don't see every npm supply chain attack or malicious github action or similar on HN. In general you _have to_ manually review every PKGBUILD update by hand (by diff). Everything else is neglect IMHO. Luckily for most packages this is reasonably doable, IFF you trust the upstream sources…
Don't forgot to also check the applied patch files. Many AUR builds include custom patches to make something work, making this a convenient way add something malicious into the build. An extreme example for patches is ventoy's 1355 line long PKGFILE [0] sourcing lots of patches both from external domains as well from the git server on aur.archlinux.org itself.
[0]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vento...
Earlier quoted context omitted.
To be fair, the advice very rarely is for people to jump onto Arch based distros. The problem is more that the Arch value proposition kinda presupposes the sort of user that's going to "feel superior" about having it installed[0]. It leads to people that have no business installing Arch Linux (as it doesn't match their usecase) installing Arch Linux because it makes them feel cool. I don't have a good answer for this…
To be honest, it took me way too long to figure the Arch etc crowd are hobbyists who enjoy having something which always 'needs maintenance' over the weekend. (And maybe they don't want to admit they are hobbyists because what they are doing seems Very Important.) Sorta like 'car guys' who recommend some old thing you can wrench on.
Basically, my model of a mean arch user would be closer to a DIYer -- likes to follow clear manual instructions, likes sturdy and non-ephemeral things, likes to know what the sausage is made of, but prefers if maintenance costs are minimized (since they will be bearing those costs and are responsible for the thing), so makes choices according to that.
People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs. You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. This really has always been the case; we've had discussion about this for well over a decade. People are always asking why there's no official AUR helper like yay - this is why. A lot of people complain abo…
While that may be true, is the AUR not moderated or operated by arch devs? On Gentoo, I can't just push "npm install malware" to 400 packages in guru without someone else's approval.
> You have to review the source of every PKGBUILD from the AUR you install, full stop.
With a semi official repo, I would expect the people with push access to not upload malicious packages... while its still possible, and things do happen, completely pointing the finger at arch users for simply using arch isn't very helpful.
Earlier quoted context omitted.
Any and all modifications to PKGBUILDs may download something and execute it, that's the very purpose of PKGBUILDs, to download and install new software. I'm sure it would be great to have trusted reviewers look over every update, but the simple reality is that all of this work is done by volunteers and there isn't nearly enough manpower for it. Maybe doing automated LLM reviews would help, but this is a large infras…
> Any and all modifications to PKGBUILDs may download something and execute it A normal PKGBUILD should not download anything programmatically. It should rely on the package manager to download the files listed in the PKGBUILD's source array. If a PKGBUILD is running a command to download something not listed in source, that's a sign that something nefarious could be happening, and such a PKGBUILD absolutely requires…
This is generally not true. Look at a PKGBUILD of:
- any Node.js package. You'll see that the `prepare` step downloads the entire transitive dependency tree from NPM. (This is because it has a massive number of leaves and no system package maintainer can curate them all (let alone resolve each one to a single version that works across all dependees).
- any Rust program. Rust uses static linking, so publishing a system-level package for each library would be pointless. Therefore, during `prepare`, `cargo fetch` it is.
> A less than 100% reliable mechanism sure beats the current situation which is "wait for users report on the forum that they have been pwn3d". May I remind that this is the third time AUR-hosted PKGBUILDs have been compromised?
Are you going to pay the monthly token bill?
Earlier quoted context omitted.
You are thinking of the alarm fatigue[1], but it doesn't apply here -- there are no constant alerts warning that you are doing something dangerous to the point you get desensitized and start to ignore them. The correct analogy here are checklists -- things that you need to check if you are to do this "dangerous" activity (AUR usage), akin to pre-flight checklist. [1] https://en.wikipedia.org/wiki/Alarm_fatigue
Oh yeah, that's the name of it. But I guess something similar happens with checklists, you do it so many times without anything bad ever appearing that you start to subconsciously assume nothing will ever happen. Why check the rotor of my helicopter when nothing ever happened to it for 5 years? This checklist is a waste of time!
True. But you still go through the fucking checklist.
"Oh a new exploit, I wonder if npm is involved at all" Yup. Every time, I guess it's one of the most common attack vectors, can we do anything to secure NPM more against these supply chain attacks? I swear NPM is always involved in all sizable attack vectors these days.
Earlier quoted context omitted.
It adds npm as a dependency, to a go build? It changes the contributor email? to install random npm packages?! in /tmp?! in post_install()??! With a new random contributor email???? Archlinux is focused on enabling a specific type of user, and certainly ones that can read bash scripts, and understand reasonable depedencies vs unreasonable ones. And even then - this is specifically in the AUR and not a package the dis…
> It adds npm as a dependency, to a go build? Programs often invoke other programs through the exec* family of syscalls. For example, git is written in C but it ships with perl dependencies. It is not unreasonable to assume pass-cli added a runtime dependency on a program written in javascript. Regardless, we're talking hundreds of AUR packages have been compromised, I'd be shocked if none of them were javascript-bas…
No, this in no way or shape looks like installing a legitimate dependency to the target audience (expert users). This is a package manager, you don't install dependencies via post_install.
Am I understanding right that machines without npm aren't affected by this particular strain? The headline got my heart going pretty good this morning.
Earlier quoted context omitted.
This doesn't really have anything to do with npm.
anything except that it's malware installed via npm