5 ms·

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. Anyway

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?

xiii1408 8y ago
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.
- dbrgn 8y ago
  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!)
  - xiii1408 8y ago
    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.
vertex-four 8y ago
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.
chias 8y ago
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').
- mikekchar 8y ago
  > 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.
  - Zancarius 8y ago
    > 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.

xiii1408 8y ago

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.

dbrgn 8y ago
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!)
- xiii1408 8y ago
  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.

vertex-four 8y ago

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.

chias 8y ago

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').

mikekchar 8y ago
> 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.
- Zancarius 8y ago
  > 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.