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.
AUR packages compromised with Infostealer and Rootkit
91–100 of 234 posts
Re: AUR packages compromised with Infostealer and Rootkit
#92People 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…
Why does nobody act like it is then? I don't use Arch but every Arch user talks about the Aur so matter-of-factly yet nobody treats it with the caution that it demands.
Re: AUR packages compromised with Infostealer and Rootkit
#93People 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…
>You have to review the source of every PKGBUILD from the AUR you install, full stop
Believing that even a small fraction of users actually do this is deeply detached from reality.
Re: AUR packages compromised with Infostealer and Rootkit
#94Earlier quoted context omitted.
Obviously usages vary greatly, but I doubt it's that of big deal for majority of Arch users (maybe it's different for Arch derived distros). My AUR maintained package count has been in single digits for decades (both on my home PC and work station), and I don't think it as a heavy burden to update those packages. There's a certain selection bias going on here -- I drop AUR packages if they become too annoying (if the…
I think the issue with AUR is that you get your foot in the door with packages like spotify[1]. It does its magic to allow you to install a .deb package on your distro. I don't know how else to install the Spotify desktop app without AUR. But once you're willing to do that, why not go a little further and trust other packages? Now, someone could argue that the Spotify app isn't important, but there's a reason it has…
I don't have it installed, so I can't comment if it requires constant babysitting, but looks pretty okay to me -- it has no AUR-only dependencies (++), one extra shell script (--), popular (++ given enough eyeballs...). Should be fairly easy to review, anything fishy should be fairly visible in git diff. If I needed it I would be using this PKGBUILD. It's a net gain that it exists there, someone else done most of the work for me.
> Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.
I mean yeah, but everything is trade off of volunteer + user attention. There is no trusted user™ who uses spotify, so it's not in official packages. So you as user need to maintain it yourself or rely on AUR and verify.
Re: AUR packages compromised with Infostealer and Rootkit
#95Earlier quoted context omitted.
No it shouldn't. You don't break everyone's workflow just because some people refuse to take basic security advise seriously. > New API should have infrastructure for informing users and making sure they've read the message before proceeding. How would that even work? AUR packages are just git repos, everything that AUR helpers are doing or not doing is not under the control of the arch maintainers.
> How would that even work? Are you seriously asking how would sharing short text notes over internet work? If you need to be 100% git-centric, you can have git repo for messages. Client will then remember last commit displayed to user and refuse to continue unless latest message was displayed. BTW some AUR clients displayed ArchLinux RSS feed before... Too sad the issue is not even mentioned in the RSS feed...
You seem confused about how the AUR works. There is no "client" like you're talking about that can show the user anything.
There are AUR helpers, but these are completely unaffiliated with arch and the people running the AUR. The canonical, recommended way of installing arch packages is cloning a git repo, reading through the sources and then building it with makepkg. There is no client there that could show the user anything.
Re: AUR packages compromised with Infostealer and Rootkit
#96This is one of the aspects of AUR which never fully convinced me: it purely hosts user-generated content, there's no review process or alike. I'd really prefer to see a model where a 'community' repository contains user submitted packages which have at least one Trusted User review the package before it's merged in. This doesn't just prevent malware, but also common mistakes in general.
This is essentially what the [extra] repository is. Not using the AUR and sticking to official Arch Linux packages exclusively is a very valid and reasonable choice (that I follow myself actually).
A large number of "an Arch Linux update broke my system" is very likely due to incorrect AUR use that AUR helpers don't handle for you. There's an elaborate writeup here from just 2 months ago: https://lists.archlinux.org/archives/list/arch-dev-public@li...
Re: AUR packages compromised with Infostealer and Rootkit
#97Lots of discussions now, from different source articles:
https://hn.algolia.com/?dateRange=last24h&page=0&prefix=fals...
Re: AUR packages compromised with Infostealer and Rootkit
#987+ hours into this and still no mention on archlinux.org webpage nor on aur.archlinux.org. Why??? AUR should have been blocked until user takes action to prove he knows about this. Eg. change AUR API URL slightly so yay/yaourt users need to look up what is going on. New API should have infrastructure for informing users and making sure they've read the message before proceeding. Especially when they're not even sure…
Are you paying maintainers for that, or are you just blindly demanding things from a piece of software maintained by volunteers before saying iT'S sO uNprOfEsSiOnAL ?
Re: AUR packages compromised with Infostealer and Rootkit
#99People 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…
> You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates.
But isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package, etc? (Unless you are running them somewhere without internet access or without access to anything you don’t mind being public?)
Maybe it’s not the case for aur, but the others could theoretically be improved with better permissions, sandboxing, etc. I guess browser extensions basically have those options, even if no “normal” users use them.
Unfortunately 99.99% of people can’t or don’t have the time to review everything. :-(
I guess distro packages where there are trusted maintainers, or places like the iOS App Store where there are both permissions and somewhat of a review process, are the safest.
Re: AUR packages compromised with Infostealer and Rootkit
#100People 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…
> I'm not sure what the alternative would be, reviewing every adoption request seems like too much effort and wouldn't necessarily even help every time.
Even the most primitive LLM review workflow would have caught this compromise.
Adding or modifying any invocation to a PKGBUILD that may download something from the network and execute it (whether using npm, pip, curll|bash, or whatever else) -> automatically quarantine the PR and flag for 2 human reviews required. Same for anything that looks like obfuscation. Same for anything that adds dependencies on the wrong language ecosystem (like new use of javascript ecosystem tools in a c++ based package).
I have no idea why they don't do this already.