this post was submitted on 13 Jun 2026
267 points (99.3% liked)

Technology

85837 readers
3400 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 3 years ago
MODERATORS
top 50 comments
sorted by: hot top controversial new old
[–] Buffalox@lemmy.world 70 points 2 weeks ago (4 children)

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.

[–] Holytimes@sh.itjust.works 26 points 2 weeks ago (1 children)

This is what happens when a shit load of packages that just sit around basically unmaintained are allowed to sit around.

[–] Buffalox@lemmy.world 6 points 2 weeks ago

Maybe injecting the infections made it look like they were maintained? 😋

[–] PumpkinEscobar@lemmy.world 13 points 2 weeks ago (2 children)

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

[–] Buffalox@lemmy.world 6 points 2 weeks ago (1 children)

Yes that would be nice, but I'm not sure that is possible.

[–] Cethin@lemmy.zip 4 points 2 weeks ago

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.

[–] turkalino@sh.itjust.works 4 points 2 weeks ago

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

[–] Peter_Arbeitslos@feddit.org 32 points 2 weeks ago (2 children)
[–] A_norny_mousse@piefed.zip 4 points 2 weeks ago* (last edited 2 weeks ago) (6 children)

I'm still missing any sort of in-depth info about all this.

edit: https://bbs.archlinux.org/viewtopic.php?id=313892

[–] JakoJakoJako13@piefed.social 17 points 2 weeks ago (1 children)

Start here. https://bbs.archlinux.org/viewtopic.php?id=313892

AUR, the Arch User Repository is under an attack. The attack vector is any orphaned package that doesn't have a current maintainer. Those packages are being taken over by a malicious group. https://redlib.catsarch.com/r/archlinux/comments/1u3tn4e/tons_of_new_infected_aur_packages_were_just/ If a package maintainer quits/leaves/abandons a project, anybody can take control of the package if there's been no maintainer for a certain period of time. What we're learning now is that this process could be automated and done en masse. They're modifying PKGBUILD files to use a java script installer like npm, bun, yarn, nodejs to shove malware onto a system. So if you have a package that's marked as infected and you've updated your PC using an AUR helper like yay or paru during this time without checking the PKGBUILD you could be in trouble.

What users are advised to do is not update any AUR packages until otherwise noted. Scan your systems for any packages where the PKGBUILD reports installing an atomic-lockfile, js-digest file through npm, bun, nodejs, yarn and the like. Delete those packages.

The number of infected packages has gone from 400 to 600 to 1500 in a matter of hours last night. The AUR team has been on top of it almost the moment it got recognized. The AUR has well over 100,000 packages. Last night another user ran some numbers and at the time 718 infected packages had no users at all. The most popular package is an old Gnome dependency libgdata that was dropped years ago but could still be on systems. There's a lot of old packages using ancient python2 deps that look to be infected as well. https://redlib.catsarch.com/r/archlinux/comments/1u4fzea/according_to_pkgstats_these_are_the_most_popular/ list of infected packages https://md.archlinux.org/s/SxbqukK6IA Seems like this was caught because old maintainers started getting emails about package updates to old projects they were on. Those OGs sprung into action.

[–] A_norny_mousse@piefed.zip 2 points 2 weeks ago* (last edited 2 weeks ago)

Thanks. The forum thread's beginning suggests a concerted effort around adding the line npm install atomic-lockfile to repos.

Searching for that I quickly found this: https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency and related articles.

Then it seems to change to 'bun' and 'js-digest': bun add figures debug js-digest

Apparently both atomic-lockfile and js-digest are upstream npm/javascript packages that have been infected with datamining malware.

BTW, admins reported as of 12h ago it's all cleaned up.

load more comments (5 replies)
[–] brokenwing@discuss.tchncs.de 2 points 2 weeks ago* (last edited 2 weeks ago) (3 children)

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.

[–] Peter_Arbeitslos@feddit.org 2 points 2 weeks ago* (last edited 2 weeks ago)

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)

(reference)

Personally I would reset everything if I got anything, to kill both any infection and my paranoia. Then reset credentials.

[–] ilmagico@lemmy.world 1 points 2 weeks ago (1 children)

Was it installed from the aur? If not, you're fine

[–] stardreamer@lemmy.blahaj.zone 3 points 2 weeks ago (1 children)

libgdata here is specifically very messy. It was an official package since it was a required dependency for older versions of GNOME, then in GNOME 50 they dropped the dependency and so did Arch from their repos. But because pacman doesn't remove dangling dependencies, you end up with libgdata still installed, until Arch Linux moves dropped packages into the AUR as an orphan, which happened in this case 5/31. This allowed it to be perfectly timed for the attackers to pick it up on 6/11. Now, you'd inadvertently update libgdata from an AUR source if you're using an AUR helper.

[–] brokenwing@discuss.tchncs.de 1 points 2 weeks ago (2 children)

Yes that seems to be the case. But on 12th of June, I did a yay update. But only librewolf-bin was updated. libgdata (0.18.1-5) was last updated on March 05 2026 for me.

Also I did some digging around. Seems like any packages that were installed using a AUR helper (like yay in my case) would leave logs in the /var/log/pacman. You can see them like this,

grep "package_name" /var/log/pacman

For yay installed packages you can see they are getting installed from ~/.config/yay/package_name. But for my libgdata, it simply says [ALPM] installed libgdata (0.18.1-5).

[–] stardreamer@lemmy.blahaj.zone 1 points 2 weeks ago

Sounds like you got lucky. libgdata was part of the second round of attacks and was quickly reverted. It's likely you're running the last official release.

[–] gratux@lemmy.blahaj.zone 1 points 2 weeks ago

You can also check the build/install date of a package with pacman -Qi

[–] A_norny_mousse@piefed.zip 0 points 2 weeks ago* (last edited 2 weeks ago)

Probably reinstall (all is supposed to be fixed as of over 12h ago). This time check the PKGBUILD and also whichever (git) repo the software is pulled from.
See if infected versions of npm packages atomic-lockfile and js-digest are installed.

See here: https://bbs.archlinux.org/viewtopic.php?id=313892

[–] deathbird@mander.xyz 29 points 2 weeks ago

I use Debian btw

[–] RavuAlHemio@lemmy.world 25 points 2 weeks ago (1 children)

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…

[–] frongt@lemmy.zip 0 points 2 weeks ago (1 children)

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.

[–] RavuAlHemio@lemmy.world 17 points 2 weeks ago* (last edited 2 weeks ago)

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 freetds sometime in the mid-2010s and the package maintainer was incommunicado.

[–] cmhe@lemmy.world 18 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

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.

[–] deathbird@mander.xyz 7 points 2 weeks ago* (last edited 2 weeks ago)

Very normal looking. /s

[–] treadful@lemmy.zip 15 points 2 weeks ago (1 children)

This attack is ongoing. Don't let your guard down on AUR PKGBUILDs.

[–] HaraldvonBlauzahn@feddit.org 3 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

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.

[–] treadful@lemmy.zip 6 points 2 weeks ago (4 children)

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?

load more comments (4 replies)
[–] Tetsuo@jlai.lu 9 points 2 weeks ago

Yesterday that was 400 packages, now it's 1500.

Tomorrow 3000 ?

[–] sinematic@lemmy.zip 6 points 2 weeks ago

Thank god they're only niche packages, right?

[–] blight@piefed.blahaj.zone 6 points 2 weeks ago (1 children)

Does anyone know if the NixOS packages are safer from these types of attacks? As far as I know many packages are missing maintainers.

[–] SlimePirate@lemmy.dbzer0.com 2 points 2 weeks ago

I read a reddit thread about this.

Basically they are significantly safer because the review process is tedious and the PRs take ages to get reviewed. More over the read-only nature of the nix store make most of those techniques useless. You cannnot just take over packages the AUR way.

Moreover, if you use third party nix flakes, you are still safer because they are tied to a specific github repo, so if it gets forked by malicious actor you won't get that update.

However you are still prone to upstream malware. That is nixpkgs probably won't add malware but it could be there before packaging.

[–] darthsundhaft@piefed.social 3 points 2 weeks ago (2 children)
[–] thisbenzingring@lemmy.today 18 points 2 weeks ago (2 children)

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.

load more comments (2 replies)
[–] BlackLaZoR@lemmy.world 3 points 2 weeks ago (1 children)
load more comments
view more: next ›