With regards to sandboxing etc. maybe. With regards to packages? Official repos support signing and usually rely on maintainers with proven track records. AUR was a honor system and since some people are total basement losers, you can't rely on that.

We have locks on our doors for a reason. Any software that allows updates and relies on the honor system of "someone else must have checked this" will get hacked. Every day there's yet another certificate or secret stealing infection that is in some random upstream dependency in your dev tools or shell scripts or whatever.

Yes, my point being this isn't some 'Desktop Linux security' hole. This was a known and intentional model of how the AUR operated for decades. Unfortunately it was bound to get exploited like this and so it did.

> Any software that allows updates and relies on the honor system of "someone else must have checked this"

That is never how the AUR was supposed to work. Updates were intended to be a manual process where the user reviewed changes to the PKGBUILD.

Yes but realistically trust is necessary, as users can’t audit all source code. The fact the source code is even audited is, in it of itself, a blessing. Google Play and the App Store don’t do that, and those are trust based systems as well. And naturally, malware slips through, as it always will.

The AUR is not like Google Play. Arch has https://archlinux.org/packages for that. The AUR is like an APK from a Reddit post.

Castles made of sand slips into the sea, eventually

Better than the commercial alternatives

More so than, say, Windows? Really?

And no, "people using one Linux distro can opt in to possibly getting pwned by each other by making use of a third-party software depot" does not reflect upon the entirety of the Linux world.

It's funny how these people say Linux security is bad because random people can upload arbitrary files to AUR, but won't say Windows security is bad because random people can upload arbitrary files to Microsoft GitHub.

I think the wrongful notion comes from the fact that the vast majority of Arch users use and speak about AUR as if it were a part of arch proper, only paying lip service to reviewing PKGBUILDS, etc. They wrap the default package manager in one that supports AUR and never touch it directly again. It feels closer to if all of GitHub was available in one click through the Microsoft store or windows update.

And unfortunately that’s how arch is mainly marketed by its users. “Arch has the latest everything, if it’s not in the repos it’s on AUR” is one of the standard selling points.

Of course that speaks to how people use linux insecurely not how Linux is insecure.

Most AUR "helpers" show you the PKGBUILD and/or a diff thereof and ask you to confirm that it looks ok before continuing the install. At least by default.

Maybe most users just ignore that and always answer yes without inspecting it. I don't know. But the wiki for the AUR and Readmes for many of these tools have warning banners telling you not to blindly trust AUR packages.

There are subtle things like abusing how github handles forks which can make malicious PKGBUILD a matter of just changing the rev with no hint in the file itself.

Perhaps, but it would be pretty unusual to use a commit/hash id instead of a version tag, or the main development branch.

There is much stuff which isn't in the AUR at all, or if so in versions similar to debian default, and/or orphaned.

Nonetheless, the full tray is just one yay away, which also speaks git.

How you use such tools is totally up to you.

So far I've been unaffected by the AUR hickups, running Cachy for about 2 years now.

But I've been always wary about the AUR, trying to minimize its use. Even in the phase where I used pure Arch for several years. It tends to get messy. So less AUR is less mess.

MS-Windows gets attacked by the hardware vendors, too.

>More so than, say, Windows? Really?

significantly so. Windows has a coherent story when it comes to permissions and access. Differentiated out access controls, least privilege, UAC, mandatory integrity control and all configured out of the box.

Without AppArmor or SElinux correctly configured, which it isn't on most desktop distributions in the linux world most of your apps can still read anything, there's little sandboxing. The NT Kernel was designed with an object model in mind so you always had the abilities to have rich descriptions and policies for whatever you're handling where all of that is bolted on unix systems after the fact.

>Windows has a coherent story when it comes to permissions and access.

Yet that doesn't seem to matter much for stealer malware.

it does matter, things like the Data Protection API do meaningfully reduce what you can extract from a windows system.

Of course Windows regardless has taken the brunt of the attacks because it ran virtually every desktop machine in the world so people go after users anyway. Desktop Linux systems where never economically interesting for malware. But now that they have gained a modicum of traction they're going to get the exact same treatment, hence this thread.

Microsoft doesn't advertise it much but they do have the advantage of controlling their build environments, software is signed etc. A system like the AUR where you pull in unsigned packages from anonymous people with so many arch users relying on it is not going to be easy to address. It lived on security through obscurity.

>Data Protection API do meaningfully reduce what you can extract from a windows system

It's not meaningfully reduced. The stealer just has to call CryptUnprotectData before uploading it. It's not even like it will show a suspicious prompt to the user, without having to do anything extra the stealer can silently decrypt it.

I agree with the rest of the post though.

I would say most Linux desktops users are aggressively sandboxing everything. All my dev envs are sandboxed, trivially, Claude is sandboxed, and all my apps are flatpak. And I do actually revoke permissions for flatpaks often, although most are real good about it - using xdg-directory and such.

Maybe I’m a minority, but the tools are very mature and easy to use IMO. In windows land people are still installing random EXEs, that’s the reality.

I never claimed that and in fact Windows has had a lot of malware written for it proving it too has bad security.

There are more ways to attack people than third party software depos.

Yes. Windows has had a built in antivirus for 14 years

I disagree. Maintainers for the major distributions take their roles very seriously, and do a very good job generally of filtering out malicious packages. The AUR is an outlier, being essentially an unmaintained wild west.

The AUR is also not really comparable to official distribution package repositories either. Yes, it's hosted by the same people as the official repos that are comparable to what you'd get by default on other Linux distros, but it's intentionally not something that works with official package management tooling. The equivalent would be if Debian or Ubuntu hosted a repo that anyone could upload of unbuilt debian packages while explicitly not offering any tooling other than the usual tools for building a .deb from source files that you manually downloaded from anywhere else or defined yourself.

It's definitely an outlier, but more in terms of being something that doesn't really exist anywhere else, so of course the security model for it will also be an outlier. That's not an excuse for any security issues, but it's not like Arch doesn't have official repos with maintainers who are just as diligent as any other distro. They just also happen to provide a public git server that people can publish packages to with a UI for seeing some of the package metadata; people could just as easily write toolling to automate package management where it looks for a GitHub repo instead of an AUR one to fetch the build files.

The Ubuntu equivalent is PPAs.

It's the closest thing, and what gets used in practice for the same purpose, but I'd argue it's not quite equivalent. The equivalent to PPAs in Arch would be putting a custom repository in `/etc/pacman.conf`, which is a thing that is done sometimes (e.g. on SteamOS to provide specific versions of certain software).