> Build scripts should not run sudo or anything similar. If it does that anyway, it’s wrong. At best, it’s a packaging error, as sudo shouldn’t be expected to work in a non-interactive environment like a build chroot. Sometimes a packager mistakenly tries to move package files into place instead of adding them to the package.
Something I've noticed over time is that security and quality are connected, not inherently but in that there's a lot of overlap. Reviewing an AUR package should include making sure that it doesn't use sudo and doesn't move files into place directly because that's a possible flag for malicious behavior. But equally, sudo is unreliable in the build environment ("sudo shouldn’t be expected to work in a non-interactive environment like a build chroot"), and trying to directly place files instead of packaging them means the package won't upgrade, downgrade, or uninstall cleanly, and won't properly attribute files when you ask the system what owns them. I don't know how well it generalizes, but heuristically I've moved toward viewing security and quality as sufficiently overlapping that they can be treated as a single area.
> I've moved toward viewing security and quality as sufficiently overlapping that they can be treated as a single area.
Quality implies knowledge, understanding, and the willingness to use them. Security is the same, but for the narrowed domain of security best-practices and common vulnerabilities. It's possible for something superficially high-quality to be insecure, but that implies that whoever made it either has extremely lopsided experience, or left the vulnerabilities in intentionally or knowingly. Of course, security is a particularly tricky domain, so even a fairly talented and good-intentioned developer is likely to make some missteps. Those missteps, I'd say, qualify as lapses in quality. I'd be damned surprised, on the other hand, to find that something low-quality is secure, and would assume that any such security is the product of a happy accident or sheer simplicity of the software, and is more likely than not to be lost as it grows and changes.
You mean in the sense that it was secure by virtue of being extremely simple, and lost that security because it grew in complexity without growing in quality?
"End-users need to read and understand shell scripts to make sure they're safe" is a completely unacceptable threat model. The way I see it installing software from the AUR is about as safe as installing software from the pirate bay. Nevertheless, this distribution keeps getting discussed and recommended to people, with the AUR often cited as a reason to use it.
How is that an unacceptable threat model for a repo of packages that are optional and user-made? One that clearly says, "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk." (1)
The AUR, along with Arch's minimalism, is one of my favorite things about it. Instead of cloning the source repo, reading the build instructions, building, and then installing, I download a script, read it to make sure it looks okay (e.g. the source points to what I expect), and then `makepkg -si`.
> The way I see it installing software from the AUR is about as safe as installing software from the pirate bay.
No, if I trust the source - and I often follow the source link to GitHub to check out the project - then it's like one of my distro's packages, except I'm the one saying it's safe for me to install. I'm not claiming it's risk free, but it's been a great boon to me. (2)
2: I used the AUR to compile and install Goldendict-ng, a fork of the dictionary software Goldendict that's being maintained. It accepts my Stardict converted-from-Apple dictionaries and supports Wayland!
> How is that an unacceptable threat model for a repo of packages that are optional and user-made? One that clearly says, "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk." (1)
The AUR is an official part of Arch Linux. It's hosted on the archlinux.org domain with a prominent link to it from the main page. You enable package installation from it either using one of the many transparent pacman wrappers recommended in arch community spaces and on the arch wiki, or by ticking a checkbox in a graphical package manager like pamac. IMO a one-line disclaimer on the aur main page doesn't fix the problem at all.
Security isn't about the trustworthiness of the code you're running, it's about the trustworthiness of the person who's giving you the code. No matter how good you are at auditing bash scripts, there's a malicious bash script that will slip by you, even if you're diligent (which most aren't, even among so-called "power users"). With official packages, I have to trust the people who distribute my OS. With vendor-distributed software (Windows software, PPA, curl | sh) I have to trust the person who wrote the software. With the AUR, I have to trust the first person to park the name of the package.
I mean 99.9% of the problems can be averted by just not installing some random new aur package with 0 votes or popularity.
The vast majority of packages an average user needs are built by arch anyways and aur by large is not nearly as needed. Still would take easily reviewable pkgbuilds over adding some random PPA as all too many ubuntu users tend to do or similar.
I think they have a point, you might (and should) evaluate it for each new package you install. But when you do a full system upgrade, are you telling me you'll review every AUR package again?
I am really really weary of installing anything from "user" repos, whether it's AUR or Fedora copr. It feels like the wild west. Admittedly, maintainers of Debian packages could just as easily mess up or release something malicious, but I at least get the impression that the bar is higher...
That's a good instinct and default. But if you do the process consciously, like OP advices, AUR can be more secure and predictable than alternatives as you build locally from first-party sources.
As someone who is an AUR maintainer with at least 150+ packages, I always dread seeing new AUR packages. A lot of people don't read the packaging guidelines, don't use tools like `namcap` and `extra-x86-64-build` to test their packages, nor do they read other PKGBUILDs to write their stuff. It's pure slop, and I have wasted too much of my time fixing shitty PKGBUILDs because I wanna use that piece of software
As someone who is a maintainer of a few packages, it’s actually really hard to find references for this stuff! The wiki is pretty bare when you start looking for specifics, and like you say there’s tons of crap pkgbuilds when you try to look at what others do.
> Build scripts should not run sudo or anything similar. If it does that anyway, it’s wrong. At best, it’s a packaging error, as sudo shouldn’t be expected to work in a non-interactive environment like a build chroot. Sometimes a packager mistakenly tries to move package files into place instead of adding them to the package.
Something I've noticed over time is that security and quality are connected, not inherently but in that there's a lot of overlap. Reviewing an AUR package should include making sure that it doesn't use sudo and doesn't move files into place directly because that's a possible flag for malicious behavior. But equally, sudo is unreliable in the build environment ("sudo shouldn’t be expected to work in a non-interactive environment like a build chroot"), and trying to directly place files instead of packaging them means the package won't upgrade, downgrade, or uninstall cleanly, and won't properly attribute files when you ask the system what owns them. I don't know how well it generalizes, but heuristically I've moved toward viewing security and quality as sufficiently overlapping that they can be treated as a single area.
> I've moved toward viewing security and quality as sufficiently overlapping that they can be treated as a single area.
Quality implies knowledge, understanding, and the willingness to use them. Security is the same, but for the narrowed domain of security best-practices and common vulnerabilities. It's possible for something superficially high-quality to be insecure, but that implies that whoever made it either has extremely lopsided experience, or left the vulnerabilities in intentionally or knowingly. Of course, security is a particularly tricky domain, so even a fairly talented and good-intentioned developer is likely to make some missteps. Those missteps, I'd say, qualify as lapses in quality. I'd be damned surprised, on the other hand, to find that something low-quality is secure, and would assume that any such security is the product of a happy accident or sheer simplicity of the software, and is more likely than not to be lost as it grows and changes.
This reminds me of Notepad
You mean in the sense that it was secure by virtue of being extremely simple, and lost that security because it grew in complexity without growing in quality?
"End-users need to read and understand shell scripts to make sure they're safe" is a completely unacceptable threat model. The way I see it installing software from the AUR is about as safe as installing software from the pirate bay. Nevertheless, this distribution keeps getting discussed and recommended to people, with the AUR often cited as a reason to use it.
How is that an unacceptable threat model for a repo of packages that are optional and user-made? One that clearly says, "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk." (1)
The AUR, along with Arch's minimalism, is one of my favorite things about it. Instead of cloning the source repo, reading the build instructions, building, and then installing, I download a script, read it to make sure it looks okay (e.g. the source points to what I expect), and then `makepkg -si`.
> The way I see it installing software from the AUR is about as safe as installing software from the pirate bay.
No, if I trust the source - and I often follow the source link to GitHub to check out the project - then it's like one of my distro's packages, except I'm the one saying it's safe for me to install. I'm not claiming it's risk free, but it's been a great boon to me. (2)
1: https://aur.archlinux.org/
2: I used the AUR to compile and install Goldendict-ng, a fork of the dictionary software Goldendict that's being maintained. It accepts my Stardict converted-from-Apple dictionaries and supports Wayland!
> How is that an unacceptable threat model for a repo of packages that are optional and user-made? One that clearly says, "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk." (1)
The AUR is an official part of Arch Linux. It's hosted on the archlinux.org domain with a prominent link to it from the main page. You enable package installation from it either using one of the many transparent pacman wrappers recommended in arch community spaces and on the arch wiki, or by ticking a checkbox in a graphical package manager like pamac. IMO a one-line disclaimer on the aur main page doesn't fix the problem at all.
Security isn't about the trustworthiness of the code you're running, it's about the trustworthiness of the person who's giving you the code. No matter how good you are at auditing bash scripts, there's a malicious bash script that will slip by you, even if you're diligent (which most aren't, even among so-called "power users"). With official packages, I have to trust the people who distribute my OS. With vendor-distributed software (Windows software, PPA, curl | sh) I have to trust the person who wrote the software. With the AUR, I have to trust the first person to park the name of the package.
I mean 99.9% of the problems can be averted by just not installing some random new aur package with 0 votes or popularity.
The vast majority of packages an average user needs are built by arch anyways and aur by large is not nearly as needed. Still would take easily reviewable pkgbuilds over adding some random PPA as all too many ubuntu users tend to do or similar.
> I mean 99.9% of the problems can be averted by just not installing some random new aur package with 0 votes or popularity.
Piracy websites use a similar system. It's not nothing, but it's not enough for me to install pirated software.
Audit the script locally first before running it? How is that unacceptable?
If you find that too risque or tedious, fine, don't use it. It can still be valuable for those happy to put in the effort.
I think they have a point, you might (and should) evaluate it for each new package you install. But when you do a full system upgrade, are you telling me you'll review every AUR package again?
I wish I had the time, but I don't. Feels shitty, but what are you gonna do.
I am really really weary of installing anything from "user" repos, whether it's AUR or Fedora copr. It feels like the wild west. Admittedly, maintainers of Debian packages could just as easily mess up or release something malicious, but I at least get the impression that the bar is higher...
That's a good instinct and default. But if you do the process consciously, like OP advices, AUR can be more secure and predictable than alternatives as you build locally from first-party sources.
(Same can't be said for COPR or PPAs)
The linked article (with the original incident) was really good:
https://www.mh4ckt3mh4ckt1c4s.xyz/blog/aur-chaos-malware-ana...
As someone who is an AUR maintainer with at least 150+ packages, I always dread seeing new AUR packages. A lot of people don't read the packaging guidelines, don't use tools like `namcap` and `extra-x86-64-build` to test their packages, nor do they read other PKGBUILDs to write their stuff. It's pure slop, and I have wasted too much of my time fixing shitty PKGBUILDs because I wanna use that piece of software
As someone who is a maintainer of a few packages, it’s actually really hard to find references for this stuff! The wiki is pretty bare when you start looking for specifics, and like you say there’s tons of crap pkgbuilds when you try to look at what others do.
HN meta question: I noticed that the submission time of this submission recently got reset. Did this post get into some second chance thing?