"This is yet another incident that showcases that Linux users should not explicitly trust user-controlled repositories."
LOL. Why should this only apply to Linux users? We should all be wary of downloading random things from websites.
AUR has always been labeled "user submitted", but I guess it's easy to forget that some "users" are really out to cause harm.
They also keep tools that would easily/automatically build and install packages from AUR out of the main repos, to encourage manual handling and individual consideration of AUR package build scripts.
Also this malware was found in AUR within a few hours of it going up.
Of course, it would be more interesting if we could scan or survey the AUR to get a percentage of suspicious packages. I've long been under the impression that some popular AUR packages (e.g. Google Chrome) are pretty safe from tampering. For anything else, I glance over the PKGBUILD to make sure it's not doing anything obviously fishy, and I've never noticed anything.
Having met these criterias, they need to be sponsored by an existing TU, and then it will be put up to a vote.
Also been a push towards reproducible builds, and the stones have been laid with pacman 5.1.
Sarcasm aside, I think a lot of the pearl-clutching over this incident is down to people not understanding the difference between the official repositories and the AUR.
Anyways, I know I don't manually review everything I install on my system, I trust the packet manager.
I'm not an Arch user so I don't know, but doest the AUR repo have some kind of code signing or automatic analysis of the packages?
The "correct" way to install something from AUR is to go grab the install script, READ THROUGH IT CAREFULLY, then knowing that you just downloaded a thing uploaded by someone unafilliated with Arch, you make your decision on whether or not to run/install it. That said, there are (non-official) package managers that you can use which give you a package-manager-like experience installing packages from AUR and do a pretty good job of sweeping all of that under the rug. Convenient? yes; a good idea? it's your system, you decide (my opinion is 'no').
This frustrates me. Because there is a large vocal group that opposes the use of yaourt (the most popular AUR package manager), I spent a year building packages by hand, just to see if there was something I was missing. I was not. It's just a complete PITA. In the end, I wrote scripts that just about duplicated yaourt -- checks for new versions of packages that I've installed, downloads the latest comments so I can see if there has been any controversy, checks for and installs dependencies, etc, etc.
There is nothing in the manual process that makes it more safe than installing with yaourt. Yaourt prompts you to edit the PKGBUILD file (and even defaults to this!). It is just as easy (and in fact, I think easier) to neglect to check what it's doing when you are building by hand.
After a year of building by hand, I went back to yaourt because I have better things to do with my time than write scripts that duplicate it.
I think the real issue is that many people do not want to legitimise AUR as a source of packages for everyday people. I can sympathise with this point of view and even agree to it to a certain extent. However, avoiding using a tool like yaourt is cutting off your nose to spite your face, IMHO.
I get your point, but I think part of the reason for the official stance against AUR helpers is that they incline users to skip any manual vetting of the PKGBUILDs on their own. In practice, you're always going to have some subset of the population who won't even look at the source PKGBUILDs (helper or not), but I think this is a valid concern. If you download the package sources manually, the effort required to type "makepkg" versus "less PKGBUILD" isn't significant. Contrast this to using a helper, where pressing a key to continue building is an awful lot more tempting than having the helper open the PKGBUILD in your editor (where you now have to press many more keys to continue)--regardless of the defaults.
What I tend to do is use an AUR helper to download the package sources and then manually build them from there. Helpers are incredibly useful for searching/downloading sources from the command line, but I'm not completely convinced having them build/install everything unattended is a particularly great idea. Part of this is the nature of the AUR and part of this is because if you use enough packages from the AUR, sooner or later, you're going to have to intervene and fix something (which defeats the point of using the helper in the first place). Plus, using the helper as a glorified fetch tool gives you something of an intermediate package cache as opposed to dumping everything in /tmp and nuking it between boots.
That said, I do agree it's more to avoid legitimizing the AUR. There's good reasons for this (legal and otherwise). But I think it's important for people to decide precisely how they wish to use the AUR as long as they understand the repercussions.
Also, I believe yaourt is considered deprecated as it hasn't seen updates in quite some time. I'd suggest something else like aurman or yay.
> If you download the package sources manually, the effort required to type "makepkg" versus "less PKGBUILD" isn't significant. Contrast this to using a helper, where pressing a key to continue building is an awful lot more tempting than having the helper open the PKGBUILD in your editor (where you now have to press many more keys to continue)--regardless of the defaults.
You could make the same argument about effort to skip checking being fewer keystrokes to argue that yaourt makes its more convenient to check because that is also fewer keystrokes than typing an additional command manually in the command line. Thus I think the actual reality is people who are lazy will skip a self audit regardless of how they choose to build the package. Ie youart isn't problem.
> Plus, using the helper as a glorified fetch tool gives you something of an intermediate package cache as opposed to dumping everything in /tmp and nuking it between boots.
So change the build location. It's all configurable. /tmp makes sense as a default but I have mine set elsewhere. On a previous system I even had yaourt configured to build in its own ZFS tank.
> Also, I believe yaourt is considered deprecated as it hasn't seen updates in quite some time. I'd suggest something else like aurman or yay.
I often hear the same complaint made about Android apps (re it's not been updated in a while) but when it already does everything it needs to then why should it need to see further updates? It's not like yaourt doesn't keep track of security updates (I mean it's all just wrappers around GNU and BSD tools so if there's a bug in tar or OpenSSL then they will be updated independently anyway).
I've been using yaourt for several years and frankly I've never once felt "damn, this thing needs more maintenance".
Arch discourages tools like yaourt because it makes it so easy to install some an unvetted package and that opens you up to the very real risk of installing malware. As you point out, downloading the package and building it isn't any safer if you don't read through the script. It's easy to make the argument that a casual read through of the package file will only catch the most obviously bad packages and a clever person could easily find better ways to hide their malware payload, so why bother looking at all?
If you aren't going to read the package files, you may as well use a tool like yaourt; there's effectively no difference. In my own experience it's rare that I have to install something from AUR so I can take the time to briefly scroll through the package files and check where the source code is coming from, easy stuff like that.
In the back of my mind, I understand I'm taking a risk; I think that's what Arch is trying to accomplish by discouraging tools like yaourt.
IMHO, the danger of a PKGBUILD itself doing something nasty is small--it would be limited to things like recording `uname -a`, listing all your installed packages: the things mentioned in the article.
The real danger is that the PKGBUILD is installing some software, which you will later run with full user privileges. If you don't notice that the Git repo listed in the PKGBUILD file is wrong, you won't notice that you're actually installing a backdoored version of the package.
(Also, I don't really get the critique of tools like yaourt, since they make it easy to inspect the PKGBUILD and - if present - install files. The tool simplifies downloading, you still need to review yourself!)
But, yeah, they run as root, so they could still do something nasty at install time. Not when you `makepkg` the PKGBUILD, though.
Then the comment section mentions the other one is libvlc.
But the mailing list says this is something different: https://lists.archlinux.org/pipermail/aur-general/2018-July/...
So then there's still two missing.
Here's what I've found that he maintained:
1) balz (https://archive.fo/TjIQI)
2) minergate (https://archive.fo/TjIQI)
3) acroread - as mentioned (https://my.mixtape.moe/kvfpmk.png)
So those "balz" and "minergate" could be the missing two.
Edit: seems like archive.fo is temporarily down, so it will just be my word for it right now. Sorry.
So much for being sneaky malware, he wasn't even trying to hide it... Any insertion of a `curl` command to some shady looking TLD piping to bash is going to be a massive red flag to even unsophisticated linux users.
Not much to see here, fortunately.
A case for putting more things in the main Archlinux repositories!
Anything proprietary can't simply be copied over and mirrored for copyright reasons.
OTOH, you're basically giving Google root access to your machine.
For example for MTP:
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
Not maintained (last commit in 2016). So that will be something low on the priority list.
The dedupe tool looks interesting. Noted on my todo.
Was dropped from the repository. Probably because of the lack of an maintainer.
I see! Time for me to start looking for a new method of transfering files from android then, thanks for the heads up
I personally just install termux, which allows you to install openssh. Run sshd and then you can use rsync or scp or sshfs or other from the host PC.
Honestly, MTP is terrible on every OS though. Mac and Windows have it a _lot_ worse for interacting with MTP devices.
Honestly AUR has covered everything I've needed.
It has options to configure it to do everything automatically, but you have to actively go in and set it so.
if [ -z "$1" ]; then echo "No package name specified."; exit; fi
mkdir -p $1
wget -q "https://aur.archlinux.org/cgit/aur.git/snapshot/$1.tar.gz"
tar xzf $1.tar.gz
read -n 1 -s -p "Press any key to continue..."
echo -e "\n"
sudo pacman -U --noconfirm --needed $1*pkg.tar.xz
Many packages use rolling versions from git commits, so while the PKGBUILDs don't get updated, any time a user re-runs makepkg on that PKGBUILD the latest commit is pulled and built.
In those cases, a PKGBUILD might be months or years old, but still consistently up to date and valid.
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.
Perhaps the answer is a few more TUs to get some of the popular AUR packages adopted and officially supported.
EDIT: s/repository/public database/
The case shown here is pretty obvious looking, but I don't think it would be too difficult to make it better hidden. Seeing what kind of tricks are statistically more common would make PKGBUILDs easier to review.
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;
More info of this particular one at e.g. https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-... or just search for 'linux backdoor attempt'
For kernel devs, specifically the kind that reviews patches submitted by others, I would think it would also be useful to have data on previous successful and failed attempts at introducing backdoors into the kernel.
Right now, I think that for anyone that wants to see this kind of data for any particular kind of software, they'd have to search for it through various mediums like mailing lists or the blog you linked to (through google).
That's an interesting link, by the way. Thanks for sharing.
EDIT: Removed redundant part. Misread what parent post meant.
It has happened to the snap store recently, but AUR has been around for ages.
I heard they're making a change to the policy for uploading packages to AUR. The next time this happens the user will automatically receive an email that says, "Hey, don't do that."
I've gotten to the point where I do not install any AUR helpers on my systems, and manually download PKGBUILDs and install with makepkg. These extra steps force me to 1) review the PKGBUILD + *.install files, and 2) make me reconsider whether or not I want to go through the effort for a package (i.e. "do I really want this thing")
If you want to see all software installed from outside repos defined in /etc/pacman.conf, you can use this pacman option:
I did write a helper, mainly for myself and a few other arch users I know, and if not for having completed it enough to use it, I wouldn't do it again (I don't support pacman wrapping). I use like 5-10 packages from the AUR and I either maintain them or they _never_ change and I would know something is wrong.
The other point to this is how is this sort of compromise best communicated? It's important enough to hit  and obviously this news site, the mailinglist, but not the frontpage of arch itself.
I brought it up partially, and the simple explanation is; We don't. It's unsupported and compromised packages happens. There is no system in place to warn about it and the frontpage is reserved for news about issues regarding official packages.
The good ones do, yes.
> with a default answer of [Y]es.
And therein lies the problem. You may review a handful up front, but then convince yourself that all is good since it's much easier to just press 'enter' and move on. It's MUCH easier to ignore a PKGBUILD when you have to hit one key to skip it than it is if you have to manually download it, put it somewhere, and 'makepkg' on it.
Package managers are an inherently flawed way to distribute software, instead of obtaining your programs from whoever developed that program you get it from your OS developer!.
There's a whole lot of trust that has to go on when installing a package from the AUR - and yes, this is a fundamental problem with the security model of Arch Linux, but that's been known for a very long time.
Honestly, I'd be surprised if this hasn't happened before with orphaned packages.
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
From the AUR homepage, in big text:
> AUR packages are user produced content. Any use of the provided files is at your own risk.
Contrast this to the old debian-multimedia, which had no links from Debian.org and which eventually yielded to pressure to change its name to make clear that it was not part of Debian.
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. 
Most people would read "Apple App Store Found to Contain Malware" as "Apple Devices Found to Contain Malware" too.
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).
But, yeah, they run as root, so they can still do damage.
My point was that the danger zone is when you trust the package, rather than when you run the PKGBUILD itself with `makepkg`. Of course `makepkg -i` runs both `makepkg` and `pacman` as root.
And with every other OS that isn't locked down so the user can't run arbitrary stuff.
The AUR is just the arch equivalent of downloading a `.exe` installer and running it. Yes, clearly there are security concerns there, but they aren't specific to Arch.
If you want a level of trust, then don't build AUR packages and install things using the package manager (AUR packages aren't supported by it) which have trusted maintainers and are signed.
It's exactly the same problem that every other distro has when users compile or install unvetted community packages.
The only way to make unvetted community repositories safe is to have users look at the sources before building or installing. Arch encourages users to do that -- AUR helpers and binary repositories are discouraged, and the source package format is simple enough that an average user could probably spot something like this.
That's it. But oh yeah, because I do these things by hand and check whether the source urls point to the place I'd actually like to install (and other code doesn't download external sources, eg. in the PKGBUILD or external scripts like *.install files), I'm suddenly an exception.
I just noticed that the blue used on the Archlinux logo is actually quite consistent with Rick's hair color. https://i.imgur.com/kkE25w2.jpg Fits me. I don't give a damn.
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 distribution. If it weren't arch, they might be downloading third party RPMs or debs from untrusted sources. Would that be reason for a technically competent person to avoid RHEL or Debian? Of course not.
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 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.
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.
Funny that I only ever hear of this when talking about security aspects, not
when discussing available software. In the latter case I always hear how many
things are there in AUR, especially comparing to Debian. AUR must have failed
miserably in not trying to pass false sense of security.
One argument does not invalidate the other. It is true that tons of software are available in AUR that is not easily available in other distros. It is also true that AUR is not supported.
A similar thing happens with PPAs in Ubuntu or even with Flatpak/Snaps: they brings tons of additional software to the distro, however they're unsupported and can be security nightmares .
:Yeah, even when Flatpak/Snaps are properly sandbox (since some apps are not), they can include software to mine cryptocurrencies for example.
I used Arch on my laptop (primarily used for development) for several years. It mostly worked great and I always had access to the newest whatever with a minimum of hassle. I don't have many complaints, but occasionally after an update something critical would stop working.
I'm on Solus now and, so far, it's been pretty great. :-)
Rolling release is great for technically competent users to install on their workstations, but why would you ever want a rolling release on a production server?