Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I 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.by Sleaker
- The 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.
by Gud - The other favourite besides Arch is NixOS. How does it compare when it comes to supply chain security?by weinzierl
- 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.
by antibarbarus - I 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.by tim-projects
- I 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.by zache6
- > 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.
by catuscubitus - WRT 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".
by uticus - From 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.
by uticus - Sounds like it has been disabled, which is exactly what was said.by pessimizer
- 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.
by delecti - Yeah, 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.
- > 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.
by jolmg - IMO allowing package adoption makes sense in the responsible/intended use-case: AUR packages aren’t trusted, you have to read the PKGBUILD anyway, so the reputation of the contributor doesn’t matter. Removing adoption is admitting that there’s no way to prevent some users from blindly trusting a PKGBUILD.
Which is probably the best choice, unfortunately.
by bee_rider - I'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.by OJFord
- > 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.
by vlovich123 - >Disabling AUR package adoptions has been like the #1 thing recommended.
Do you have a solution to ever reenabling package adoptions? It's pretty much a must have feature for this to exist long term, at least in the AUR's current state where its a repo your not supposed to auto install from but pretty much all users do.
Really disabling adoptions is probably step 1 to just EOLing the whole thing.
The AUR by definition isn't to be trusted. That's what the official repos are for, you're supposed to read what the package install scripts are doing.
- This just made me think: if Anthropic or OpenAI wanted to get some good will, and burn a bunch more investor funding, they'd provide security audits for the most popular N AUR packages for free as a good-will service.
- Well, 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.by Matl
- 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.
by datakan - I'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.
by qwery - I’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?
by WD-42 - Desktop 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.by charcircuit
- > I can’t help but feel there used to be honor among hackers.
My assumption is these aren't so much hackers, as modern day script kiddies armed with LLMs and too much free time.
by al_borland - Arch is simply getting popular enough to be targeted.by jolmg
- People are warned countless times that the AUR is unsafe, that any random person can make an account and push packages, that you need to audit what you're downloading and that malware has been discovered in it multiple times in the past.
- I think you've accidentally lumped together "people who work in tech in / around the field of information security" and "criminals".
There have been a variety of cultural elements to people doing security research / hacking on their own systems / etc.
There has never been "honor" among criminals looking to use technology to steal money or steal things that can be converted to money.
by akerl_ - The reason is popularity. SteamOS is Arch-based and in the hands of a ton of people who aren't necessarily that technical. CachyOS and EndeavourOS have become very popular with the increasing adoption of desktop Linux. The AUR thus becomes an enticing attack surface.
- > What kind of jerk would attack Arch Linux?
The answer is: Russians
Source: I'm the guy that built the antimiasma mitigation tool [1] and tracked their malware campaign iterations very closely.
Set LANG to ru_RU.* and the malware implant stops spreading itself, as with all APT28/29 malware.
[1] https://github.com/cookiengineer/antimiasma
[2] https://cookie.engineer/projects/cyber-defense/antimiasma.ht...
- > 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?
This has absolutely not ever been the case.
by sp0rk