6 ms·
Arch Linux disables AUR package adoption
- shevy-java 2mo agoAI is killing linux distributions now. This is another example.
- stock_toaster 2mo agoMaybe just poorly run ones?
- bionade24 2mo agoFlatpak, Snap Store & PPA malware has been a thing for a long time already.
- nobody42 2mo agoIt's just entropy. Favorable environment of Linux distros is an initial phase of technology. This state is gone for years now, AI is just making it evident. Adapt or become obsolete.
- einsteinx2 2mo agoThis kind of hyperbole isn’t helpful. Security concerns about supply chain attacks in the AUR (well known to be extremely insecure well before LLMs got popular) isn’t “killing” Arch let alone “killing Linux distributions”, plural.
- delecti 2mo agoThat 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.
- OJFord 2mo agoI've used it (not for abuse). It's simply volunteering to maintain the package after previous maintainer(s) have explicitly disowned it, knowing they no longer have time for it or don't care because they stopped using it, etc.
- gchamonlive 2mo agoProblem is that there is no KYC process before someone can adopt any orphaned package
- OJFord 2mo agoYeah, I don't disagree there should be more of a barrier, I remember being surprised I could just adopt things. Just explaining the intended use.
- yjftsjthsd-h 2mo agoThere's also no KYC process for creating one.
- OJFord 2mo agoThere is more risk in someone adopting something with established users though. Some people (cough) might be a bit less careful if they see something has tonnes of users, votes, comments; people actively using and liking the package.
- ameliaquining 2mo agoYeah, the security problems with unilateral adoption of orphaned packages by unprivileged users are fundamental and unfixable; the only remedy is to remove the feature. Whether it has legitimate use cases (which it sounds like it does) is irrelevant. I'm not sure why it took them so long to realize this and act accordingly, but I'm glad they now have.
- jolmg 2mo ago> 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.
- Sleaker 2mo agoI don't think any form of automated adoption of orphaned packages will ever work, it's just too easy to introduce malicious code into an otherwise functional but no longer maintained source.
- WD-42 2mo agoI’ve been using arch for nearly 2 decades at this point. It’s amazing that the AUR went this long without any serious attacks. It’s a different world now. I can’t help but feel there used to be honor among hackers. You didn’t go after your own. What kind of jerk would attack Arch Linux?
- charcircuit 2mo agoDesktop Linux has always been a house of cards in regards to security. I agree it's amazing that it went on for so long, but this was inevitable.
- tempfile 2mo agoI 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.
- saghm 2mo agoThe 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.
- charcircuit 2mo agoAUR should be scanning new uploads for malware before allowing them to be published.
- tempfile 2mo agoWhat does "scanning for malware" mean? As far as I know this is a totally open question, and the only credible answers (install in a sandbox) are too inconvenient for widespread adoption.
- charcircuit 2mo ago>are too inconvenient for widespread adoption. The owners of AUR would do this for all packages they host so the inconvenience does not fall on other people. AUR has to take responsibility over the security of what they offer.
- tempfile 2mo agoThe inconvenience is always with the person writing the package. When you restrict the build to a sandbox, if it fails, it's because the package actually depends on the thing the sandbox is limiting (usually network requests during the build). To fix this problem, the package has to change. This is why e.g. NPM does not roll out sandboxing.
- cube00 2mo agoYou can only scan for known malware. Plenty of ways to write new apps to do bad things that scanners won't detect.
- charcircuit 2mo agoJust because it's impossible to catch 100% that doesn't mean it is not worth doing.
- gh02t 2mo agoA 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.
- dandersch 2mo agoI think Arch has to rethink what the AUR really is for in the age of AI. If users aren't supposed to trust anything from the AUR, then they will start to use LLMs to scan PKGBUILDs for them. But at that point, why not let the LLM loose directly on the upstream repo and build+install the package from source?
- nvme0n1p1 2mo agoYou 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"?
- warkdarrior 2mo agoYes, 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.
- Matl 2mo agoArch is famously x64 only?
- tyfon 2mo agoI 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 :)
- Matl 2mo agoI 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.
- 2mo ago
- tim-projects 2mo agoI added a git repo to AUR last year. It was super easy with basically no checks of any kind. Once these reports came out recently, I went through and deleted every AUR package that I could.
- uticus 2mo agoFrom the actual announcement: > ...package adoption is currently disabled while we are handling the situation. Sounds much more like the temporary pause, than the much less temporary-sounding "has been disabled" from the OP.
- pessimizer 2mo agoSounds like it has been disabled, which is exactly what was said.
- uticus 2mo agoWRT package vulns, I'm surprised there's not more technical theory out there. We have plenty of theory around algorithm design, but so far I haven't heard much about inspecting and improving control of dependencies in source - apart from conflict and version management. Seems like instead of big-O notation, we could have a "reach index" - how far does the top-level code need to reach, to be effective? Top-level -> Userland lib 1 -> Userland lib 2 -> Kernel, would be a reach level "4" - not the simplest, but much simpler to inspect and securely build than reach level "20".
- zache6 2mo agoI haven't been updating AUR packages since the initial incident. Thankfully hadn't updated for a week prior to it. Tonight I'll be uninstalling all the AUR packages I possibly can.
- catuscubitus 2mo ago> I haven't been updating AUR packages since the initial incident. The world of exploits and malware thanks you for your service. > Thankfully hadn't updated for a week prior to it. Chances are this started more than a week before it was discovered. > Tonight I'll be uninstalling all the AUR packages I possibly can. Instead, you could just use the AUR mindfully in terms of which packages you install and review the code.
- deleted 2mo ago[deleted]
- vlovich123 2mo ago> 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 adoptions has been like the #1 thing recommended. While it's a positive step, it's not good news they literally tried everything else first. This doesn't speak well to the security headspace of the Arch maintainers.
- Matl 2mo agoWell, this kills a very useful feature of the AUR. It's like Wikipedia disabling editing. So I can see trying other things first before resorting to removing features, but I do agree it should have happened faster.
- datakan 2mo agoThe 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.
- qwery 2mo agoI'm sure the team are having a rough time with all this, but I don't understand the path you followed to go from the maintainers have not taken this action until now to "This doesn't speak well to the security headspace of the Arch maintainers". Or what "security headspace" means exactly. Yes, lots of people thought disabling package adoption is/was a good idea. It seems quite likely that the Arch DevOps team also could have come up with that one, and they certainly wouldn't have missed all of the people telling them to do so. It seems to me that disabling package adoption is not a desirable thing to do in general, and can only be used as a stopgap response to an emergency, which seems to be what is happening right now. "just disable adoption" certainly can't be a long-term solution: Without adoption, the AUR will slowly fade away as orphaning a package would be permanent. Maybe the idea is to have some sort of approval process to filter adoption requests? In that case the AUR just dies instantly as that would effectively be another official repo with all of the issues that that would bring.
- simonask 2mo agoThe 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?
- slowin 2mo ago> 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.
- inigyou 2mo agoFor example, Bitchat is illegal in India right now, PGP is probably going to become illegal in the EU and UK, and Hypothetical Child Porn Organizer is probably illegal in most places. Tornado Cash is illegal everywhere the US has power, which is almost everywhere.
- inigyou 2mo agoor not so hypothetical. I did once stumble across an open source project to organise your child porn, hosted on GitHub! I don't remember what it was called.
- antibarbarus 2mo agoEver 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.
- weinzierl 2mo agoThe other favourite besides Arch is NixOS. How does it compare when it comes to supply chain security?
- deleted 2mo ago[deleted]
- Gud 2mo agoThe problem is that there is a LOT of missing stuff in the Arch repos. I use FresBSD, where I rarely run in to this problem, that something is missing from ports. However, it is a common occurrence in Arch. Which is a shame, because it’s otherwise a fine operating system.