Comment by chimeracoder
8 years ago
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 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.
> 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
you wouldn't be saying that "this is a fundamental problem with the security model of git."
From the AUR homepage, in big text:
> AUR packages are user produced content. Any use of the provided files is at your own risk.
AUR has the word "Arch" in its name and is linked right at the top of the Arch Linux homepage and from every Arch Linux webpage. So it's disingenuous to claim it is "not Arch.”
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.
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:
[1]: https://wiki.archlinux.org/index.php/AUR_helpers
I understand your point but the problem is that the title is "Arch Linux AUR Repository Found to Contain Malware" (and not, for example: "AUR Repository Found to Contain Malware"). I would argue that the implication (I guess reputation-wise if that matters) starts with the "Arch Linux" part. It's easy to jump on Arch because of this regardless of the fact that the AUR is not supported. At a cursory glance plenty of people (though incorrect) will equate this to "Arch Linux contains malware"
This isn't unique to Linux.
Most people would read "Apple App Store Found to Contain Malware" as "Apple Devices Found to Contain Malware" too.
1 reply →
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`.
1 reply →
> this is a fundamental problem with the security model of Arch Linux
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.
> this is a fundamental problem with the security model of Arch Linux, but that's been known for a very long time
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.
The thing is not that it's a new deficiency or something, it's just that Arch user conveniently ignore this when praising their distribution over e.g. Debian.
AUR repository isn't supported by the core tools and packages. To use it one has to install external scripts. So it's by no means part of the system.
All it takes to build air packages is makepkg from the core pacman package. With gut you can grab aur packages from the terminal, and hit is also core. Every Arch install must have pacman and hit is in base-devel, a package group in core all AUR pkgbuilds are designed to assume is installed.
Urm, you need git, you need build tools... and pacman.
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.
1 reply →
Which, as I said, very conveniently is glossed over by Arch users.
7 replies →
Fortunately admins are not unreasonable and don't base their decisions on praises but on actual merits, so most servers run Debian rather than Arch (which is an interesting distro for other usage cases).
Who would want to use a rolling release distribution for a (production) server? Sounds like a pretty terrible choice, to be quite honest.
7 replies →