Comment by trash_panda
8 years ago
Of course, one should be careful about what one installs on their system. Even more so an Arch user, which should be technical saavy in the first place.
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?
AUR is not an "official" repository at all -- indeed the acronym stands for "Arch User Repository". Kinda like github, you can go put whatever you want in there, and people can download and install it on their machines if they want to.
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').
> 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.
> 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.
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.
1 reply →
AFAIK yaourt specifically is discouraged because its possible for a malicious PKGBUILD file to execute code before it is displayed to you (as a consequence of the way yaourt parses the files). Other AUR helpers do not have this problem.
In my opinion, this is a hard problem and not one that we can expect Arch Linux to take on or solve. We're talking about how we establish that a software package (source code, build script, binaries, etc.) can be deemed trustworthy such that we feel comfortable installing it onto our machine (which may hold important data, personal, financial, etc.) I don't think anyone has a good solution, with the Apple App Store at one extreme and (in my opinion) something like AUR at the other.
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.
I can't speak for all AUR managers but the one I use (yaourt) is probably the most popular one on Arch and it definitely does prompt you to audit the package before you compile it.
No, AUR packages are PKGBUILD files, which are essentially little batch scripts that run inside a fakeroot.
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.
The PKBUILD runs in the fakeroot, but AFAIK the .install files (postinstall hooks etc) run on the host system directly, with root permission. Definitely something you will always want to review.
(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!)
All the install hooks are run chrooted inside the pacman install directory.
But, yeah, they run as root, so they could still do something nasty at install time. Not when you `makepkg` the PKGBUILD, though.
The AUR repo is, basically, a free for all. It’s not the official repository, which is trustworthy - it’s just a hosting space for user-provided build instructions.