I’ve seen AUR warned against often, also by Arch team members.
I never thought it was a huge deal, but apparently anything that can be attacked will be attacked nowadays.This is what happens when a shit load of packages that just sit around basically unmaintained are allowed to sit around.
Maybe injecting the infections made it look like they were maintained? 😋
I start to wonder if we need something sitting between extra and aur, few more trusted maintainers and well secured update process that’s more than the aur Wild West
Also, some sort of yay hook to do some scanning for suspicious diffs and warning or skipping those packages…
I don’t want / need a system where I can blindly update everything, but something to help me avoid having to visually check every package diff would be nice
Yes that would be nice, but I’m not sure that is possible.
Their first option is possible for sure. Just something like the AUR, but that you need a proven record (either on the AUR or on something else) to post. That shouldn’t be too hard.
I feel like this could be a use for LLMs that isn’t slop. It’s not going to catch everything of course but I imagine it would be a whole lot better than nothing
https://aur.archlinux.org/ warns you about it
deleted by creator
We’re currently at 1621.
What to do if I found a package I installed to be in that list? libgdata to be specific?
Edit: Seems that the libgdata package was last installed on March 05.
Have a check if you updated it recently (PKGBUILD history, about June 10-12). If not you’re fine.
If:
- Rotate all credentials — browser passwords, SSH keys, API tokens, and cloud access keys
- Scan for suspicious processes masquerading as kernel threads using tools like rkhunter or chkrootkit (E: It’s supposed to be an eBPF rootkit)
Personally I would reset everything if I got anything, to kill both any infection and my paranoia. Then reset credentials.
Was it installed from the aur? If not, you’re fine
I use Debian btw
A couple of weeks ago, some dingbat of an AUR admin orphaned a package of mine, ignoring the comment I left on it and my post to the mailing list.
Even though this package, to my knowledge, didn’t end up being attacked, I wonder if this was a potential precursor to the recent attack…
To answer your question, generally yes the package maintainer is the one who maintains the package for the current version of the distro, even if upstream is unchanged. If a package is no longer compatible and no one is making it compatible, then yes it’s unmaintained and should be removed.
It wasn’t removed, it was marked as orphaned, which means anyone can take over and mess with it, lowering the bar for supply chain attacks.
If another user had said “I can take care of this long-term, gimme”, I’d had handed it over. Instead, some self-important dingbat with too many privileges decided to mass-mark all packages with an “outdated” flag beyond a certain age as orphaned, then ignored my mailing list post.
For what it’s worth, a distro package maintainer’s inability to update a package to a newer upstream version does not necessarily lead to a package being removed. Debian and Ubuntu kept shipping an ancient version of
freetdssometime in the mid-2010s and the package maintainer was incommunicado.
I got a notification about a package that changed the maintainer that looks rather suspicious to me… So i would still be careful…
https://aur.archlinux.org/account/svantehedlund
That user doesn’t seem to be blocked… So there might still be more going on.
Very normal looking. /s
This attack is ongoing. Don’t let your guard down on AUR PKGBUILDs.
For people that just want to install packages that are not included in the Arch distro, and don’t have the knowledge or time to review PKGBUILD files:
Have a look into the Guix package manager. It works fine on top of Arch, and Guix has 31,000 packages now. Great for cross-language development and also suitable for early sharing of projects. npm support is a bit weak though, but packages written in Python, Rust, or functional languages are well represented.
I think the AUR is great if you are writing some program, want to explore some idea, and want to share it with people you know. Sharing freely is how all open source software is created initially. Open source needs that openness and could not exist without the creativity which the openness makes possible. That’s why Ubuntu for example has launchpad and ppas. But the AUR is not a good software distribution mechanism for people who just want to install and run stuff they have heard of, precisely because it is not vetted, and unsupervised. It can’t because the sheer number of packages it includes, over 114,000 .
By aware that the next target could be the Python / PyPy / pip ecosystem and repos. It is unsupervised, too, and users on average are less technical than Arch users.
“pip install” can run arbitrary code on your computer.
I suggest Guix because it is more looked after. It also has, which is essential, the openness mentioned above: You can pull any Guix package definition from your friend’s web site, and install it as any other package. You just need to configure the package source.
By aware that the next target could be the Python / PyPy / pip ecosystem and repos. It is unsupervised, too, and users on average are less technical than Arch users.
PyPi has been an attack vector for a long time now. Just as with NPM, and others.
I suggest Guix because it is more looked after.
What makes you say that?
In Guix, package definitions are part of the Guix distro and are vetted.
(You can still add your own local package definitions, or pull a package definition of your schoolmates friend from their web site or Codeberg repo - Guix is very open in that sense. But, in the same way as with Ubuntu launchpad and ppa’s or Debian third party repos, you would have to add that package source explicitly. It is not the standard way of distributing packages. )
Also, Guix is rapidly growing (31,000 packages despite it is relatively young). I think the reason is that it both allows for cross-language projects (If you want to publish a vector drawing program with image algorithm libraries written in C, a GUI done in in Python, and memory-safe media importers written in Rust - it is made for that!). And it runs on top of many larger distributions (I use it on Debian stable and Arch).
In Guix, package definitions are part of the Guix distro and are vetted.
Heard you the first time. I asked you what makes you think that’s the case.
Guix is a smaller distro with (presumably) less maintainers, but it has 2x the packages that Arch has in it’s official repos, and you assume they’re well vetted? AUR has 3x (and a shitload of eyeballs), so it’s probably a reasonable assumption as a comparison, but your post is basically just “trust me bro.”
Guix is a smaller distro with (presumably) less maintainers […]
Guix is not a small distro any more and has a lot of support. Yes it has more packages than Arch - but this is hardly an argument against it. It is built on different principles compared to the Arch user repository - keeping control of the own computer was always a core goal of GNU, and this logically includes security from malware.
Guix packages are vetted.
AUR packages aren’t.
And, package definitions in Guix are not shell scripts but highly abstracted functional installers that use the respective build tools of software packages. This makes them much easier to review - and quicker to write, in many cases.
Guix is also fully reproducible, and has the goal to provide safe distributely built software. (It gets significant hate from tech companies for requiring GPL licenses for the core distro, and thus not supporting binary code without source code).
As the case of the xz-utils package shows, this does not prevent that a widely used project is taken over by malicious actors, and stealthily malware becomes inserted. But the effort to do this is much larger, since this needs write access to the software’s source code.
And no, I don’t think Guix is the magical silver bullet for software security. But it is much better than unvetted shell scripts in AUR.
And of course, Guix has disadvantages, too. The biggest disadvantage is IMO that it is really slower than Arch’s pacman, because Guix - being based on source packages - sometimes builds stuff from source. But I think this does not matter so much if one is using it for ten or twelve extra packages. (It also got a lot faster with moving to Codeberg.)
Thank god they’re only niche packages, right?
“I use arch btw” lmao
Arch and AUR are not really the same. To be fair AUR is the fanfiction version that fits inside the story. But you have to purposely work to use it. So it’s not Arch that was compromised.
IsIs it really all that difficult to use these popular coding and browsing tools such as Heroic Launcher, Visual Studio Code and Brave within Arch Linuxes like CachyOS?
Last time I touched an Archy Linux, I don’t recall it being difficult for some of the things on that list. And it still comes from a central store of apps reminiscent of the Microsoft Store for example…
To use the AUR, you have to install a AUR Helper https://wiki.archlinux.org/title/AUR_helpers
They are not just “click and go”. They require a dedicated effort. AND when you’re done, using them requires a specific command. So in short, it’s not pacman and it’s not Arch, the AUR is a special choice
I use AUR BTW!
lmao
deleted by creator
Haven’t seen an arch fuckup like this since they switched to signed packages.
I wouldn’t really categorise it as a fuckup. These are unofficial packages from the AUR. You should trust them as much as random install scripts from a no-name website or git repo.
