Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AUR packages compromised with Infostealer and Rootkit

discourse.ifin.network

Post reply on HN
Print view View original

71–80 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#71

Post by Tharre »

harvie wrote: post #55

7+ 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…

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.

Re: AUR packages compromised with Infostealer and Rootkit

#72

Post by rossvor »

bachmeier wrote: post #59
lordleft wrote: post #51

Earlier quoted context omitted.

You’re not wrong, but then we ought to pump the brakes in telling everyone and their mother to hop onto arch based distros that make installing AUR packages seem as safe as any other action (via Shelly on cachyos for example)

Honestly, it's hard to see how Arch is a usable distro for most potential users without AUR. If you want a large selection of official packages, the Debian world is going to be the better choice.

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 they require updates too frequently or they want a slew of other AUR only packages as dependencies), I either find alternatives or alternative sources for them (e.g. flathub).

Arch still hits the sweet spot for me -- unobtrusive, close to upstream, and well-documented enough to keep full control over your own system. Both for the times when you want to go with the most default path and for the cases when you want to deviate and go play in the weeds.

Re: AUR packages compromised with Infostealer and Rootkit

#73

Post by aquova »

As people have noted, this sort of thing has become inevitable and likely to increase in occurrence unless some changes are made. I'm a big fan of the AUR PKGBUILD system, and I leverage it quite frequently to write my own. The most egregious issue in my opinion, and one of the low hanging fruit to fix, is the fact that anyone can adopt an orphaned package with no notification to end users that this has happened.

It's honestly more trouble than it's worth to get your package deleted, instead leaving orphaning as the more optimal way to relinquish control. This should be the opposite in my opinion, or at the very least the users should be made very aware that an orphaning has occurred. Perhaps that burden is more on the AUR helper like paru and yay (who I would encourage to make such a change).

Re: AUR packages compromised with Infostealer and Rootkit

#74

Post by keysersoze33 »

The (Arch) community is moving quickly to release scripts/tools.

Right now, this is the most up to date, consolidated utility to check for infection:

https://github.com/lenucksi/aur-malware-check

Also, the aur-request mailing lists has many delete/orhan requests coming through to undo the malicous commits:

https://lists.archlinux.org/archives/list/aur-requests@lists...

Re: AUR packages compromised with Infostealer and Rootkit

#75

Post by reorder9695 »

williebeek wrote: post #43

I remember installing an emulator (Mednafen) on Arch Linux about a decade ago. The program failed to run because it was linked against a library my system didn't have. Turns out, the maintainer built the software on his own system and it used a library he had on his system but was not listed in the dependencies. It is an officially maintained package and I always assumed these were built on a dedicated build server i…

Tools exist (e.g. pkgctl) to allow you to test building and installing the package on a clean image to catch these kinds of things, maintainers should really be using these before publishing.

Re: AUR packages compromised with Infostealer and Rootkit

#77

Post by WhyNotHugo »

This 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.

Re: AUR packages compromised with Infostealer and Rootkit

#78

Post by Matl »

scary-size wrote: post #8
lordleft wrote: post #4

This is especially gnarly as more people have been picking up arch distros as of late (like CachyOS).

Installed CachyOS to replace my Win 10 installation a month ago. Not looking back! But yeah this sucks, I've mostly used Ubuntu with apt in the past. Pacman and makepkg felt a bit weird to use in the beginning.

Best to stick to official repositories only.

Re: AUR packages compromised with Infostealer and Rootkit

#79

Post by rossvor »

hootz wrote: post #62
akdev1l wrote: post #36

Earlier quoted context omitted.

The canonical answer to any concerns with the AUR is always “just read the PKGBUILDs bro”

For every single update, for all your AUR packages, all the time. You know that thing where if you make a security review feature obnoxious, after some time people will just accept everything without even looking? Yeah...

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

Re: AUR packages compromised with Infostealer and Rootkit

#80

Post by kpcyrd »

williebeek wrote: post #43

I remember installing an emulator (Mednafen) on Arch Linux about a decade ago. The program failed to run because it was linked against a library my system didn't have. Turns out, the maintainer built the software on his own system and it used a library he had on his system but was not listed in the dependencies. It is an officially maintained package and I always assumed these were built on a dedicated build server i…

This may happen even with `pkgctl build` if a makedepends= (transitively) pulled in the shared library into the build environment, but depends= doesn't.

There's warnings in place if a .so dependency is detected, but it's up to the maintainer to notice and act on it.

For safety/security concerns, Arch Linux has been one of the driving forces in the reproducible builds project, and for large parts of the operating system it's possible to independently verify that those binaries have in fact been built from source code. It's auditing story for official packages is stronger than that of NixOS (and on par with Debian):

https://reproducible.archlinux.org/

All of this is entirely unrelated to the AUR incident however.

Post reply on HN