121–130 of 227 posts
Earlier quoted context omitted.
"Review" them how? Read every single line of code before installing something? If it's a binary package, how do you do that? Make reproducible builds for everything you install? Move to from source distro? Putting this on users is not a tenable solution. There's room for common sense, but blaming the users for this is ridiculous
Lets take two real and random examples, and I'll share what I'd look for: First, very easy one, we want to install Brave, so we find https://aur.archlinux.org/packages/brave-bin . All the dependencies are in the official repos already, so those we trust already, you open the downloaded PKGBUILD and you find it's downloading a binary from github.com/brave, you check to see it's the official GitHub profile/organization…
Earlier quoted context omitted.
I'm not asking for myself. Yes, I understand the build process, and know what to check. I've also written PKGBUILDs before and have had packages in AUR. I'm sure you understand it too, as well as many people here. But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, a…
> But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, and warned about AUR-helpers being dangerous, but in practice, it seems AUR-helpers are widely used, and many users likely just click through PKGBUILDs they won't be able to understand. That's where the whole "Not…
Oddly enough, when I was writing that, I wasn't thinking about Arch, but Ubuntu. Years ago, I can remember a situation of a PPA being used for developing something I was involved in somehow, and while the PPA specifically noted that users shouldn't use it, they just did anyway, because they wanted what they saw as the latest and greatest versions of those packages. When the PPA owner added a package that set the default wallpaper to a warning about adding the PPA and updating all packages from it blindly, the users blamed them, rather than understanding the message. At the same time, I was actually using that repository legitimately, and it was useful.
Earlier quoted context omitted.
> users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories. I think this stance should be re-evaluated. Arch Linux developers are doing a fantastic job and I am personally thankful to them - this is not in any way critical of them. And while I don't see an easy solution here, I just feel that the time of "warning users" is long gone with how muc…
> Some other controls could at least alleviate the problem The biggest one I'd suggest they change immediately is remove the ability for anyone to just take over an orphaned package. That's a crazy policy, to me. It should require you to fork it & resubmit, not take over the original. Then they can go through and do purges of orphaned packages that are beyond a certain age.
Earlier quoted context omitted.
As someone already explained in a sibling comment, Arch Linux AUR packages are simple shell scripts that download source code from upstream, apply patches and install. I review them every time I have to install from AUR.
If I understand, the malware is installed via npm from some subshell. But yeah I totally believe you have a detailed review of every package-lock.json and etc.
I installed dwm from AUR once, then Prusa slicer.
Dwm PKGBUILD lists patches, so it's kind of obvious one needs to check them to choose what patches they want.
Prusa slices is downoaded from the official website.
I think you live in a different world ;-)
Earlier quoted context omitted.
"Review" them how? Read every single line of code before installing something? If it's a binary package, how do you do that? Make reproducible builds for everything you install? Move to from source distro? Putting this on users is not a tenable solution. There's room for common sense, but blaming the users for this is ridiculous
> If it's a binary package, how do you do that? You find one that builds from source, or you still review PKGBUILD and friends and lean more on evaluating the reputation of upstream and its maintainers, or you simply decide never to install binary packages. Your policy is yours to decide. > Putting this on users is not a tenable solution. The alternative would be to not have an AUR. Archlinux has official package rep…
And in this alternative past/future, everyone is using GitHub to host their PKGBUILDs instead, then someone gets tired/lazy and builds one repository that indexes those, and we have ArchPacBrewRepository or something, and very same issue appears again, unless people change their approach to installing random 3rd party software.
I cringed hard when some people started to make pacman wrappers that could install from AUR directly. I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.
After using Void Linux I switched to `aurutils` to get a similar separation on Arch. I can easily maintain a local AUR repo by compiling/making my own binaries and can use `pacman` to install and manage them which improves the upgrade process overall.
Earlier quoted context omitted.
Lets take two real and random examples, and I'll share what I'd look for: First, very easy one, we want to install Brave, so we find https://aur.archlinux.org/packages/brave-bin . All the dependencies are in the official repos already, so those we trust already, you open the downloaded PKGBUILD and you find it's downloading a binary from github.com/brave, you check to see it's the official GitHub profile/organization…
Question is if this would be thorough enough for this attack? A package with a slightly more involved build process, maybe some patches because it was made to build on a different distro. Maybe you've already installed (and thoroughly inspected) it before, so you're only updating to a newer version, so you're not as thorough with your review. Or an xz-style backdoor.
I recall the same situation recently with yt-dlp, as they started to depend on a JS engine for some captcha stuff or related. So when you see that, you need to adjust the mindset of "ah whatever it's probably fine" to "Ok, why are these changes actually here?", and if it's not worth reviewing, you might want to reconsider the approach of installing random binaries from the internet that are flagged as unreviewed.
I should be able to set a minimum package age just like I can with pnpm.
Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack.
Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly.
Most of these are not changes to be made by the AUR maintainers, but rather by packaging helpers and 3rd parties.
I cringed hard when some people started to make pacman wrappers that could install from AUR directly. I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.
`yay` (one such wrapper) shows me the PKGBUILD diff on every update. The first time I install something I verify the URL, and check any install script etc. seems sensible; the vast majority of subsequent updates are changes to just version number & checksum. A typosquat attack would be very obvious. (It's a bit vulnerable to it on first install, but so is 'just navigate to the project website [and click download]'.)