Live data from Hacker News

Arch Linux disables AUR package adoption

lwn.net

41–50 of 134 posts

Re: Arch Linux disables AUR package adoption

#41

AUR should be scanning new uploads for malware before allowing them to be published.

A complication is that AUR doesn't publish packages, it's more like FreeBSD ports in that they are the build scripts for packages and the user builds the package on their local machine. Building an AUR PKGBUILD inherently runs arbitrary code on the user machine, and that code is controlled by the maintainer of the AUR package.

So you have to scan an arbitrary bash script and determine if it pulls malware, or build the package server side in a sandbox and scan it (and some AUR scripts wrap proprietary software blobs the user is supposed to provide e.g. MATLAB, which makes those impossible to build server side). It's a very big extra layer that malware deployments can hide in.

Re: Arch Linux disables AUR package adoption

#42

Earlier quoted context omitted.

You really don't see the difference between a deterministic script installing a tarball pinned by its hash, and "sudo chatgpt install master branch of this repo"?

Yes, the second option gives me an easily inspectable list of results (as I can see all the tool calls the model made). The deterministic script is probably overly complex and hard to read, maybe supports ten billion platform combinations.

Most PKGBUILDS are stupidly simple, they're probably easier to read than a set of tool calls. See this for a randomly picked recently updated example:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=batte...

(honestly I think the way that arch packages work is really nice compared to most other distros: you can almost copy and paste the README of a project into one and have a package)

Here's the most complicated one I found, building a browser:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=flowf...

The main risk, if you're reading them, is typosquatting and hiding the malicious code in what the project downloads.

Re: Arch Linux disables AUR package adoption

#43
post #39

Earlier quoted context omitted.

Yes, the second option gives me an easily inspectable list of results (as I can see all the tool calls the model made). The deterministic script is probably overly complex and hard to read, maybe supports ten billion platform combinations.

Arch is famously x64 only?

I run it on my milk-v duo s risk sbc. The risk-v version is maintained by a few dedicated people, and the milk-v specifics I had to fix myself. But it works :)

Re: Arch Linux disables AUR package adoption

#44
The older I get, the more critical I become of the culture of anonymity in OSS.

The obvious-but-hard solution to this, as well as certain other attacks like the xz incident, is a chain of trust. Every line of code in every package should be cryptographically attributable to an individual or an organization, ideally associated with a government-issued ID. Git commits without a real name and a cryptographic signature should be taboo. Nobody should be running or distributing software that they don't know who made.

It wouldn't be perfect - Russia could still attack the AUR, for whatever reason - but the current situation is extremely laissez-faire to the point of being untenable.

Every time Apple's App Store policies come up, it gets criticized by hackers for various good and bad reasons, but this is exactly the problem they're trying to solve, however imperfectly.

In Open Source, we're quite focused on copyright: the concern that someone's honest work gets stolen or appropriated without whatever recognition, attribution or compensation is laid out in the license. But this is the reverse problem: Lack of attribution, and therefore traceability.

So what would that take? What would we lose?

Re: Arch Linux disables AUR package adoption

#45
post #19
post #2

That title had me worried, but the reality seems quite reasonable. I assumed the goal was to reduce usage of AUR, they've actually remove the ability to adopt (take ownership of) orphaned packages. I'm sure there are legitimate uses of that functionality, but it also seems like a pretty big avenue for abuse.

> I'm sure there are legitimate uses of that functionality To avoid package name pollution, e.g. having package foo, foo-newpackage, foo-newpackage-updated, etc. each by a new maintainer as the priors get abandoned.

With a bit more structure, you could change that to: every package in AUR is actually registered as foo/maintainer under the hood, and installing the package without maintainer name pins it to the currently active version. Package adoption can then be formalized as a new maintainer publishing their own version of the package, and users of an already-installed package need to issue an explicit command to switch over to the new maintainer's version.

Re: Arch Linux disables AUR package adoption

#46

> The project had suspended new account registration in June. That followed a campaign in which an attacker or attackers created new accounts to adopt orphaned packages and push malicious updates to them that would install malware on user systems. AUR registration was reopened on July 13 after the DevOps team added some minor, and apparently ineffective, restrictions on creating new accounts. Disabling AUR package ad…

The Arch devs have only ever used the AUR as a toilet where everyone can piss and not contaminate the core distro.

Fedora Copr, FreeBSD Ports, are all of a similar idea. Where Arch screws up is in allowing people to take over abandoned PKGBUILDS instead of making them create new ones.

This can happen to Ubuntu with the PPA's too if someone were to gain control over, say, the Nvidia PPA for drivers. It's happening almost daily with NPM and Github. Supply chain attacks are serious and the Arch devs do warn people about this right off the bat. You don't go installing from the AUR without understanding the risks.

Re: Arch Linux disables AUR package adoption

#48
post #43
post #39

Earlier quoted context omitted.

Arch is famously x64 only?

I run it on my milk-v duo s risk sbc. The risk-v version is maintained by a few dedicated people, and the milk-v specifics I had to fix myself. But it works :)

I knew there's an unofficial version for ARM. I meant more that the vast majority of AUR packages target x64 only because that's what 'official' Arch supports.

That being said, didn't know there's a RISC V effort as well now, so TIL.

Re: Arch Linux disables AUR package adoption

#49

The older I get, the more critical I become of the culture of anonymity in OSS. The obvious-but-hard solution to this, as well as certain other attacks like the xz incident, is a chain of trust. Every line of code in every package should be cryptographically attributable to an individual or an organization, ideally associated with a government-issued ID. Git commits without a real name and a cryptographic signature s…

> What would we lose?

You'd lose the ability to work on and distribute software not approved by your and various other governments. For example, if the UK makes BitTorrent illegal, what happens to you when you've attached your identity to your torrent client when you try to enter the UK (or already live there)?

Security must be solved without removing anonymity.

Re: Arch Linux disables AUR package adoption

#50
Ever since the first wave of attacks it was clear this wasn’t a passing thing, and would return unless the AUR fundamentally changed. They introduced... email verification, then hoped for the best. In a sense it’s good that this has happened as I think it will help the team understand it can’t go on like this.

I’d hate to see an AUR that’s a walled garden, and I’m not sure what an Arch without the AUR would look like. But something in between will need to be invented.

Post reply on HN