[naturalmovement]

Uh but this isn't random git repos these are packages available through the OS's repos. Why does the AUR even exist if not for malware distribution?

It's an uncontrolled free-for-all disguised as a watering hole. If they can't do the most basic of housekeeping it should not exist full stop.

[zeta0134]

They *are* doing the basic housekeeping. What do you think this announcement is, if not exactly that? AUR is very clearly documented as user-submitted, and automatic installs from it are heavily discouraged by the maintainers for this reason. Malware aside, there is very little quality control, and a poorly made AUR has the potential to break the system pretty badly. (Though, in my experience, most of the useful AUR packages are trivial to remove if something goes wrong.)

The officially maintained repositories (which are part of a default installation) were not affected. Users need to go somewhat out of their way to use an AUR.

The definition files are all plain text and not especially complicated. It's not too difficult to glance at the file before doing an install to get a basic idea of what it's about to do, just like you should do when running a random shell script or cloning a random git repo. Indeed, most AURs are implemented by cloning an upstream git repo and configuring it so it can be built. The same basic threat model applies: Do you trust the install script? Do you trust the upstream URL whose code it is about to compile?

[a-dub]

i read all the pkgbuild diffs, still doesn't give me a good sense. sure, i can verify that it's coming from the official repo but even then there's no guarantee that there isn't junk in there or that the git ref is actually pointing at the right thing.

it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture.

[embedding-shape]

> it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture.

Ok, so instead of having a reasonable security posture yourself, you'd rather rely on a number of random strangers who've eyeballed the PKGBUILD instead?

Generally, I think Arch tries to prevent users from relying on bad signals, and this principle might be applied here too.

> i read all the pkgbuild diffs, still doesn't give me a good sense. sure,

Do you have an example of a diff that doesn't give a good sense? I review all my diffs too, but I feel like all of them give me a good sense if it's safe to install or not. I mean, why would I otherwise, what's the point in reviewing if you don't use it to make a decision if to install it or not?

[a-dub]

pretty much all of them. the diffs only really show that it's coming from the same source, the changed hash and maybe some urls for some patches. actually looking at what is in that changed hash is a much more complicated story. this gives end users a false sense of security ("i read the diffs" -- not really), and attackers a clean vector (all it takes is one bad commit that might not even be on a real branch, or linked patch or late download dependency in the package itself).

[embedding-shape]

> the diffs only really show that it's coming from the same source

What else do you have to review? Both in the cases of binaries and source, the idea is that you trust upstream already, otherwise you shouldn't install software from them. And since you trust upstream, the only thing you need to review in the PKGBUILD is quite literally: Where is this stuff coming from, is it the official domain/repository? Are there other non-official dependencies? Are there patches applied?

Once you've reviewed those, you're done, and as safe as if you installed straight from upstream, zero false sense of security here.

You're mixing concerns here, as what you describe is completely different issue.

[a-dub]

blindly trusting upstream is not really a reasonable posture. that is pretty much the source of all software supply chain attacks.

there is work involved in figuring out how to get the complete diff of the code and dependencies that are included in the change, plus review time. this could range anywhere from 5-10m to 1h per package updated- if not more.

[zyuiop]

Well ArchLinux has a product for you if you want packages that were vetted: the official repositories. AUR is just a centralized place to put user created packages, like npm is a place to put user created node packages.

[matheusmoreira]

Nothing is "disguised" here. Arch Linux makes an enormous effort to warn that due dilligence is required before installing things, and to dissuade users from using the User Repository at all, to the point of not offering package manager support for it. The wiki even cites previous instances where malware was discovered in the AUR packages.

The only way you could possibly not be aware of the AUR's nature as an "uncontrolled free-for-all" is if you didn't read the Arch Wiki, and anyone who doesn't read the Arch Wiki should not be using Arch Linux to begin with.

"Uncontrolled free-for-all" is exactly the status quo of programming language package managers such as npm and pip. It's just as easy for total randoms to sign up for an account and push packages on those services as it is to push a package to the AUR. Only the AUR made the lack of trust explicit and part of the culture.

[Hackbraten]

> these are packages

PKGBUILDs are not packages. They’re (user-contributed) instructions on how to build packages.

> available through the OS's repos.

No. The AUR is a platform, similarly to NPM or PyPI, that allows users to upload PKGBUILDs. It is not part of “the OS’s repos,” and it says that loud and clear, multiple times, including on the front page.