Posted by jwilk 5 days ago
https://forum.endeavouros.com/t/malicious-aur-checkup-script...
An Arch maintainer that I personally know once admitted that he rarely review upstream changes when bumping package versions. He only does that when the build breaks.
I can't blame him for what he did, since it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI" where more and more software are being aggressively refactored (or rather rewritten) and added more features.
What we can do is choosing a stable distro (like Debian) where packages are more thoroughly reviewed, and apply security practices (such as TOTP, sandboxing browsers and video players, etc.) even though they cause inconvenience.
If you distribute an update that has malware, that is you publishing malware.
Cool story bro. Assuming that's common, I have trouble understanding why Arch (non-AUR) is any more at risk than Debian--besides the latter being more popular and having more users/incidental testers, which is a real benefit if that's your goal, but has its own drawbacks (like older and known-vulnerable packages lingering for longer before updated releases are made available).
> it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI"
Aren't Debian and friends similarly at risk of this as well, then?
> security practices (such as TOTP, sandboxing browsers and video players, etc.)
I'm not sure if those are more or less prevalent on Arch; I know that many IDEs and GUI programs I've installed on Arch ran by default in Flatpaks or similar, and Debian/Ubuntu like Snaps, but I'm honestly not familiar with whether those ecosystems have significant and/or equivalent penetration in different distros.
There's also plenty projects that silently fix security bugs without issuing a CVE or even labelling them. So now the maintainer of that packages has to monitor the commit logs, figure out if a particular bug fix has security implications and then backport it to the older version which is becoming harder and harder over time.
Unless you have a massive team or a big enough army of volunteers, the LTS model is becoming less and less viable over time, you are often safer on rolling release or close to it (something like Fedora's pace is good).
There's no silver bullets here.
Which is why the whole process is open sourced and you can get easily the source version of a package, edit it and rebuild it.
Because it's a trade-off, just like stability is, they're both software bugs in the end so mitigating them has similar pros and cons.
Where are you drawing your conviction that non-rolling-release distro maintainers are doing a more thorough review of upstream changes?
> such as TOTP
What?
It is so sad that every goodwill eventually got enshittified as well.
The AUR is, as many others have pointed out, a deliberately un-vetted pile of random Git repos. Arch deliberately doesn't even ship with a default one-click installer for AUR packages; their published guidance is "git clone this stuff from wherever it's hosted and build it at your own risk". Plenty of third-party, non-Arch-blessed tools turn that into a one-click process, but it's not "part" of Arch itself--at least not any more than, like, curl | bash or directions on how to add rando websites to /etc/apt/sources.list.d is part of Debian and friends.
I've used Arch as a daily driver for years. At peak, I've had five (5) total packages, with no transitives, installed from the AUR. Today I have one: sublime-text-4. It's perfectly possible--and extremely reasonable for many users, even power users--to live in an AUR-less world, or to use so few AUR packages that the guidance of "read what you're installing, doofus" is manageable and not onerous.
There's no maintainer vetting process in nixpkgs as far as I know, anyone can own a bunch of packages. There are quality standards and it's not "here's a bunch of nix code for folks" but it's the next possible thing in the line after that.
I don't; I use Arch on 100% of my personal servers, have done so for something approaching 20 years, and don't see myself changing.
But I treat the AUR for what it is: a place where anybody can say "here's a PKGBUILD for folks" and it's on me to evaluate it on its merits.
I was legitimately asking the person upthread what other distro they felt had a better model for this kind of sharing, because they seemed to think this was a reason for Arch users to jump ship and I was curious what they thought would be the elements of a better system.
I would never use anything equivalent to AUR on any distro due to the obvious security implications. That’s been my position for as long as I have known about Arch. I never understood Arch users using the AUR as a selling point for the distro.
Then again I live in the opposite end of the spectrum where I run only Debian Stable on my Linux desktop as well as my servers, where packages make it through Sid and Testing before getting to Stable and I can be relatively sure any supply chain attacks have been caught by then (like xz for example which was caught before it left Sid).
For those unfamiliar with Debian, Sid is basically a rolling release similar to using Arch with the official repositories (which is already dangerous without even touching the AUR), then packages move to Testing, then later eventually make it to Stable.
It’s basically like a crowdsourced set of people’s tips and tricks for installing stuff on Arch, all written in the format Arch uses for packages.
Similar to how I’d not blindly take code from an AI and whack it into production, I wouldn’t blindly take an AUR PKGBUILD and execute it. But it’s nice to have a place to go see “huh, I wonder if anybody has shared their approach so I can borrow from it”.
However, I’ll push back a bit from my perspective as a Debian Stable user. I would consider even the official Arch repositories to be dangerous just like I consider Debian Sid’s repos to be dangerous (packages are too new and not sufficiently vetted). Then regarding installing packages not available in the main Debian repos, I’ve never really had any issues installing them either as there is always either an official developer run apt repo I can add, or an official deb package, or it just builds directly from official source without tweaks. So I’ve honestly never felt like I was missing “a crowdsourced set of people’s tips and tricks for installing stuff” on Debian as I’ve just never needed one.
I do realize that installing the latest packages directly from a developer’s repo or latest deb package or source is as dangerous as the Debian Sid or Arch official repos for the same reason (too new, not vetted), but the difference is those are only a tiny portion of the packages installed on my system (like a percent of a percent, maybe a half dozen packages out of hundreds). If I ran Sid or Arch, it would be 100% of the packages on my system which is an attack surface orders of magnitude larger.
EDIT: It did just occur to me after posting this reply that I use Homebrew pretty extensively as a package manager on macOS and its official repos are equivalent to Sid/Arch official repos, so I may be a bit of a hypocrite here :P
Fwiw the Arch docs are pretty clear that the AUR is a Wild West and that you should be vetting anything you find there before you run it.
With opensuse official packages also use the same infrastructure. It is actually quite fascinating and powerful. (I know a lot less about COPR but I would imagine it would be equally as good. Wezterm switched to that for its packages)
But let's hope we get this solved, like peer review model, vouch, or something
It is very good to be able to find build/install files for everything
We can also add npm to package.mask.
Can you elaborate?
This confuses me - why would a proof-of-work anti-scraping system like Anubis prevent registrations?
This is not much, but it could deter some low effort adversaries.
Then set it in a loop on all the packages for a particular system, I don't have experience in package maintenance and would be curious what kind of issues would come up.
It's an interesting idea, not sure I'd recommend it broadly, but if someone told me they prefer to trust an LLM than third-parties I'd get it at least.