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.
Comments
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.