Comment by qwery
4 hours ago
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.
> AUR registration was reopened on July 13 after the DevOps team added some minor, and apparently ineffective, restrictions on creating new accounts.
This - they tried this first even though it’s pretty obvious this is an ineffective mechanism to fight security issues around adopting orphaned packages.
“Security headspace” means treating security seriously and acting appropriately and correctly with appropriate urgency. This whole saga they were slow to respond, they took days to actually stop the ongoing attack, and have tried everything else other than stopping adoption of orphaned packages. This should have been the FIRST thing done and only once you have a solid idea on how to reenable then you allow it. And even then I’m not sure orphaned packages are ever suitable for adoption - if you want to take over for an abandoned project, you start your own alias and try to convince all downstream dependencies to change where they point. This makes it adoption by the community which is slow and takes time and won’t be as trivial to convert into a mass scale cyber attack.
That everyone here is “but adoption is required for AUR” makes it clear there’s very limited experience and research on how other package managers don’t have this embarrassing failure (both OS and language ones like node and Cargo which have to deal with far more sophisticated attacks) and this is the way - you don’t allow identity laundering. They are all susceptible to identity laundering by just buying the project (assuming the maintainer is open to selling their keys) but that’s harder to scale by a script kiddie and requires a more sophisticated form of action.