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. [1]
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 [1].
[1]: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?
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.