The AUR is maintained by Arch's Package Maintainers
So, firstly it is their responsibility. The consequences are a direct result of their policies.
Example of changes:
* orphaned packages don’t need to be adoptable.
* doesn’t have to be a flat global namespace
* they could have offered the cooldown capability a long time. This isn’t an area they focus on until they’re absolutely forced into it through sheer embarrassment of the scale of the attack.
* they could be running scanning tools on every change to try to catch low effort attacks like this
But sure, if you throw up your hands and say “we’ve tried nothing and nothing works” then you shirk all responsibility. And maybe shutting down the AUR is the right move if the current incarnation is so bad and the people running it don’t know how to secure it.
Think of it this way - the NPM and cargo registries handle way more traffic and visibility and doesn’t have any issues like this. There they have to deal with more complicated supply chain attacks. Ubuntu and Fedora take a completely different tack with user-contributed packages that are namespaced and better sealed.
And part of this of course is that yay and ilk don’t do proper sandboxing. But that’s just more shirking of responsibility by the AUR maintainers to force the community to try to do this and failing to treat this as an end to end problem they need to own
orphaned packages don’t need to be adoptable - doesn’t have to be a flat global namespace
Those things sound worse for us who actually use the AUR the way it's meant to be used, being able to "orphan" packages for new maintainers to pick up bring us long-term stability. And since we review random 3rd party software we install from the internet, who does the actual edits doesn't really matter, as long as it's the right, simple little changes that updates usually are.
It's easy to complain about other volunteers to non-profit projects are not doing enough, but truth is that there is always a lot of stuff to do as an volunteer, and while you try to fight fire X, people scream about fire Y, and vice-versa, depending on which one made the news most recently. Sure they should be scanning things, sure the official repository should be super fast and always available, sure every package should always be problem free, but it's a human project driven by humans essentially for the love of the project itself, in one way or another.
Cargo in general have the benefit of being new (shoulders on giants and so on), and being made by people who knew what they were doing. NPM has had a long struggle with a lot of stuff though, and is today maintained by one of the largest companies in the world. I'm not sure they're really comparable here.
I do agree the process for which orphaned packages get new maintainers needs to change, obviously shouldn't be possible launch such automated attack. I don't agree with that the feature as a whole should go away, I do have my own packages that depend on other AUR packages, surely many of them have through the years changed maintainer, but shouldn't mean I need to suddenly start using a different package, as long as I continue reviewing the updates.
Those things sound worse for us who actually use the AUR the way it's meant to be used, being able to "orphan" packages for new maintainers to pick up bring us long-term stability. And since we review random 3rd party software we install from the internet, who does the actual edits doesn't really matter, as long as it's the right, simple little changes that updates usually are.
This is the problem - the AUR has outgrown this mindset and this resistance to recognize this fact is precisely why this problem will keep coming up. You’re essentially there in some ways without admitting it because of new account creation is disabled. The next attack vector will be taking over existing accounts that aren’t used.
Think of it this way - Arch is a niche distro within a niche desktop OS and still it was cheap enough of an attack that it was worth it. It’s a cultural problem and your mindset is precisely why this will keep happening. As an Arch user I’m honestly embarrassed and I’m going to be looking at distros that aren’t user hostile like this.
the AUR has outgrown this mindset and this resistance to recognize this fact is precisely why this problem will keep coming up.
It has outgrown the mindset that AUR is for people who use and follow the advice of Arch Linux? Or what do you mean? What I'm describing is a workflow you can apply today, apply it equally to all packages, and it stops 99% of the hacking attempts and the remaining 1% wouldn't matter if it's via AUR, NPM or Cargo, same issues remain.
It’s a cultural problem and your mindset is precisely why this will keep happening
I agree that "Anyone can automatically take over 100s/1000s of packages as a maintainer" is a problem, I don't agree that it's a deeper problem than that. Limit each user to be able to take over one package per month, and suddenly we get all the same benefits we have already, + we fix the current issue.
No need to trash the entire AUR when there is one specific feature broken, just fix that feature, then continue your pragmatic life as before.
As an Arch user I’m honestly embarrassed and I’m going to be looking at distros that aren’t user hostile like this.
To be fair, if I ended up misunderstand something so deeply that I didn't realize how to actually use it, I'd be embarrassed myself as well, strong of you to at least state so publicly. I'm happy you at least figured out that Arch Linux isn't for you, and you start trying to find a distribution that fits you better, rather than going through a tough period of time trying to change something into a direction it isn't even aiming for.
Installing anything from the AUR, it has always been the user's responsibility to check whatever they are installing. Has always been this way, and they have always been abundantly clear about this. It is also the reason why archlinux does not provide an official installer like yaourt or yay, they could've even built support for the AUR into pacman.
The AUR is just as safe as installing through a random shell script from github - that is to say: not safe at all.
Comments
So, firstly it is their responsibility. The consequences are a direct result of their policies.
Example of changes:
* orphaned packages don’t need to be adoptable.
* doesn’t have to be a flat global namespace
* they could have offered the cooldown capability a long time. This isn’t an area they focus on until they’re absolutely forced into it through sheer embarrassment of the scale of the attack.
* they could be running scanning tools on every change to try to catch low effort attacks like this
But sure, if you throw up your hands and say “we’ve tried nothing and nothing works” then you shirk all responsibility. And maybe shutting down the AUR is the right move if the current incarnation is so bad and the people running it don’t know how to secure it.
Think of it this way - the NPM and cargo registries handle way more traffic and visibility and doesn’t have any issues like this. There they have to deal with more complicated supply chain attacks. Ubuntu and Fedora take a completely different tack with user-contributed packages that are namespaced and better sealed.
And part of this of course is that yay and ilk don’t do proper sandboxing. But that’s just more shirking of responsibility by the AUR maintainers to force the community to try to do this and failing to treat this as an end to end problem they need to own
Those things sound worse for us who actually use the AUR the way it's meant to be used, being able to "orphan" packages for new maintainers to pick up bring us long-term stability. And since we review random 3rd party software we install from the internet, who does the actual edits doesn't really matter, as long as it's the right, simple little changes that updates usually are.
It's easy to complain about other volunteers to non-profit projects are not doing enough, but truth is that there is always a lot of stuff to do as an volunteer, and while you try to fight fire X, people scream about fire Y, and vice-versa, depending on which one made the news most recently. Sure they should be scanning things, sure the official repository should be super fast and always available, sure every package should always be problem free, but it's a human project driven by humans essentially for the love of the project itself, in one way or another.
Cargo in general have the benefit of being new (shoulders on giants and so on), and being made by people who knew what they were doing. NPM has had a long struggle with a lot of stuff though, and is today maintained by one of the largest companies in the world. I'm not sure they're really comparable here.
I do agree the process for which orphaned packages get new maintainers needs to change, obviously shouldn't be possible launch such automated attack. I don't agree with that the feature as a whole should go away, I do have my own packages that depend on other AUR packages, surely many of them have through the years changed maintainer, but shouldn't mean I need to suddenly start using a different package, as long as I continue reviewing the updates.
This is the problem - the AUR has outgrown this mindset and this resistance to recognize this fact is precisely why this problem will keep coming up. You’re essentially there in some ways without admitting it because of new account creation is disabled. The next attack vector will be taking over existing accounts that aren’t used.
Think of it this way - Arch is a niche distro within a niche desktop OS and still it was cheap enough of an attack that it was worth it. It’s a cultural problem and your mindset is precisely why this will keep happening. As an Arch user I’m honestly embarrassed and I’m going to be looking at distros that aren’t user hostile like this.
It has outgrown the mindset that AUR is for people who use and follow the advice of Arch Linux? Or what do you mean? What I'm describing is a workflow you can apply today, apply it equally to all packages, and it stops 99% of the hacking attempts and the remaining 1% wouldn't matter if it's via AUR, NPM or Cargo, same issues remain.
I agree that "Anyone can automatically take over 100s/1000s of packages as a maintainer" is a problem, I don't agree that it's a deeper problem than that. Limit each user to be able to take over one package per month, and suddenly we get all the same benefits we have already, + we fix the current issue.
No need to trash the entire AUR when there is one specific feature broken, just fix that feature, then continue your pragmatic life as before.
To be fair, if I ended up misunderstand something so deeply that I didn't realize how to actually use it, I'd be embarrassed myself as well, strong of you to at least state so publicly. I'm happy you at least figured out that Arch Linux isn't for you, and you start trying to find a distribution that fits you better, rather than going through a tough period of time trying to change something into a direction it isn't even aiming for.
Installing anything from the AUR, it has always been the user's responsibility to check whatever they are installing. Has always been this way, and they have always been abundantly clear about this. It is also the reason why archlinux does not provide an official installer like yaourt or yay, they could've even built support for the AUR into pacman.
The AUR is just as safe as installing through a random shell script from github - that is to say: not safe at all.