Live data from Hacker News

Arch Linux AUR Repository Found to Contain Malware

sensorstechforum.com

61–70 of 137 posts

Re: Arch Linux AUR Repository Found to Contain Malware

#61
As an Arch user this bothers me since a while. On the one hand the AUR contains packages I don't want to miss, on the other hand installing and updating from the AUR is tiresome.

Recently I switched to the AUR helper aurman which is great, but it still doesn't free you from reviewing PKGBUILD changes. Sometimes I wish there would be some kind of review process where popular packages could be labeled as 'reviewed' (e.g. by experienced/trusted arch users) and an (optional) option within the AUR helpers to accept 'reviewed' packages without presenting the PKGBUILD for review.

I know that wouldn't be perfect either, but at least it would increase the efficiency and as a user one could focus on the less popular packages where it is unlikely that someone else will find some malware.

Re: Arch Linux AUR Repository Found to Contain Malware

#63
post #46
post #38

Earlier quoted context omitted.

> "but you don't get to separate the two in the case of an OS or distribution." Actually I do get to do that. It's an important distinction because if the software isn't at fault, then a technically competent user can safely use it by merely not being as dumb as the average user. But if the software itself is at fault, then the technically competent user should stay clear of it. Idiots will be idiots no matter the di…

> It's an important distinction because if the software isn't at fault, [...] Though the software is at fault. It created a false sense of security, misleading the users. What else in Arch just feels secure, but in fact is not? And then, if the users around the software generally exhibit a jockey attitude, you get the whole environment built in a similar manner, not a robust one. The software may technically not be a…

> Though the software is at fault. It created a false sense of security, misleading the users. What else in Arch just feels secure, but in fact is not?

AUR never tried to pass false sense of security, it is explicitly declared as not supported everywhere.

> And then, if the users around the software generally exhibit a jockey attitude, you get the whole environment built in a similar manner, not a robust one. The software may technically not be at fault and technically could be used in a safe manner, but you won't get much exposure to that, any such use will be cumbersome and difficult (because nobody uses it this way), so you still should stay clear of the software. So no, you don't get to separate the users and the OS/distribution.

Except it is not, experienced users of Arch community vocally recommends new users to not blindly trust AUR, and the dangers of AUR is also documented everywhere. This is also one of the reasons that yaourt is shamed in public Arch communities like /r/archlinux, since it defaults to poor security behavior.

Re: Arch Linux AUR Repository Found to Contain Malware

#64
post #26

This is exactly what we've been preparing for. Don't use yaourt, and read those diffs. I know a lot of people don't do this, but it's important.

What would you recommend over yaourt?

aurman. More choices can be found here https://wiki.archlinux.org/index.php/AUR_helpers

Re: Arch Linux AUR Repository Found to Contain Malware

#65
post #15

Earlier quoted context omitted.

> yes, this is a fundamental problem with the security model of Arch Linux No, it's not. AUR is not Arch, and is not "supported" by Arch. It's a fundamental problem with the security model running code from randos on the internet. If someone published a git repo on GitHub that installed malware when you ran git clone git://github.com/user/repo . && ./configure && make && sudo make install you wouldn't be saying that…

AUR PKGBUILDs are much more restricted than this, since they're restricted to a fakeroot. Of course, if you're ultimately going to run the program, the binary set up by the PKGBUILD has a lot of control. But the PKGBUILD itself is limited in what it can do (to things like listing your installed packages, getting `uname -a`--the stuff mentioned in the article).

No. Whatever you stick in the install= file will run as root at install time. If you're using an AUR helper/running `makepkg -i`, the PKGBUILD absolutely can run code as root, without waiting for you to interact with the installed program. Installing a package from a PKGBUILD is no more or no less "powerful" to an attacker than `make && sudo make install`.

Re: Arch Linux AUR Repository Found to Contain Malware

#66
post #15

The Arch User Repository hosts whatever people want to upload to it, with basically no proactive vetting whatsoever. In addition, the installation scripts run arbitrary code, a portion of which must run with root privileges. When a package gets orphaned, that means that anybody in the community can take over maintainership of the package. There's a whole lot of trust that has to go on when installing a package from t…

> yes, this is a fundamental problem with the security model of Arch Linux No, it's not. AUR is not Arch, and is not "supported" by Arch. It's a fundamental problem with the security model running code from randos on the internet. If someone published a git repo on GitHub that installed malware when you ran git clone git://github.com/user/repo . && ./configure && make && sudo make install you wouldn't be saying that…

Just to emphasize how little AUR is supported by Arch:

Even the 'AUR helpers' aren't part of the normal Arch repositories. So if you wan't a less manual access to the AUR you have to install such a program manually.

And the Arch Wiki states:

  Warning: AUR helpers are not supported by Arch Linux. It is recommended to become familiar with the manual build process in order to be prepared to troubleshoot problems on one's own. [1]
[1]: https://wiki.archlinux.org/index.php/AUR_helpers

Re: Arch Linux AUR Repository Found to Contain Malware

#67
post #58

For the people interested, here's the actual commit from the acroread package: https://aur.archlinux.org/cgit/aur.git/commit/?h=acroread&id...

Following the URLs it appears that it sets up a systemd timer to post some system info to pastebin every hour. However the script also appears to have a mistake which I think would cause it to only log to /root/home/*/compromised.txt.

$uploader "$FULL_LOG"

should be

upload "$FULL_LOG"

Re: Arch Linux AUR Repository Found to Contain Malware

#68

As an Arch user this bothers me since a while. On the one hand the AUR contains packages I don't want to miss, on the other hand installing and updating from the AUR is tiresome. Recently I switched to the AUR helper aurman which is great, but it still doesn't free you from reviewing PKGBUILD changes. Sometimes I wish there would be some kind of review process where popular packages could be labeled as 'reviewed' (e.…

In a sense we already have that, in the form of the `community` repo: Trusted Users mark a package as safe, adopt it, and it gets packaged up and supported.

Perhaps the answer is a few more TUs to get some of the popular AUR packages adopted and officially supported.

Re: Arch Linux AUR Repository Found to Contain Malware

#69

Unfortunately lots of things one actually wants are on AUR, things like jpeginfo, golly, steam-fonts, simple-mtpfs, jslint, ... A case for putting more things in the main Archlinux repositories!

What packages would you like to se inn our repositories?

Imho, especially things that are important solutions to common things on the Archwiki but are AUR, indicated with the AUR superscript there.

For example for MTP: https://wiki.archlinux.org/index.php/Media_Transfer_Protocol The one that worked most stable for me was simple-mtpfs, but it's AUR.

It happens with other archwiki topics too, I encounter it regularly though can't think of good examples from the top of my head currently. E.g. the btrfs article mentions several AUR utilities though admittedly nothing important I need right now :)

And then some important development tools, like closure-compiler https://aur.archlinux.org/packages/closure-compiler/

Post reply on HN