> GitHub doesn't allow me to put up my old repos for adoption by any old rando, or to allow randos to request to take over my repos if I don't respond for 2 weeks.
Changing your username would let anyone reuse the old username for whatever they want. Probably still today there are bots squatting any renamed accounts. Also, you bet Microsoft would hand over your GitHub username if it was reported by someone who holds a registered trademark in the US over that username, regardless of impact.
> The utility of AUR is also really based around being able to reuse the same repo without having to re-vet every single time.
I don't think they promise that anywhere, nor should you have that expectation. That would be like since you got legit copy from random-website.com/bin.exe today, you'd get that tomorrow too, clearly not true unless you know the owner of the domain or otherwise trust it.
> go has a software package manager that heavily uses GH for distribution, and is arguably more VCS decentralized, but isn't vulnerable to this kind of attack
Unless Golang suddenly have peer-reviewed packages, Golang has exactly the same problem as AUR in that anyone can create packages, and it's up to users to decide what to trust or not. Fair that the whole "orphaned packages" thing doesn't exists in Golang, but I think Arch probably favors stability more than people expect/think, that's why people can continue to maintain packages even though original maintainer disappears. Ultimately it's a trade-off, I don't think there is some absolute truth what is correct or incorrect.
Regardless of who maintains the package, if you use AUR as intended, it seems you'll avoid most security issues. It's when your expectations aren't aligned with what AUR actually promise, that people start getting hacked.
I don't know how it works these days, but a few years ago GitHub was happy to give away usernames from users who haven't touched their accounts in a long time to anyone who asked. Several people I know got vanity usernames that way. All you had (have?) to do is drop an email to GitHub's support.
Only thing I can find on requesting to take over an inactive account is here:
> We do not accept requests to release, transfer, or reclaim usernames on the basis that they appear inactive or unused. If the username you want has already been claimed, you will need to select a different available name unless you are submitting a trademark complaint as described below.
Also even the original user renames or deletes their account any popular repos they have will get tombstoned, so the new owner can't recreate them:
> GitHub uses a tombstoning algorithm to reduce the risk of repo-jacking by permanently retiring specific owner name, repository name combinations. The github/cmark-gfm example above is purely hypothetical, because, in that scenario, the old name would get automatically tombstoned. For example, even if an attacker managed to register the username github, they would still be prevented from creating a new repository with the name cmark-gfm because that owner name, repository name combination (github/cmark-gfm) would be permanently retired. Therefore, repo-jacking is only a risk for repositories that fall below a certain usage threshold. We don’t tombstone all renamed repositories because there’s a tradeoff between usability and security: a tombstone is a potential inconvenience for our users which we don’t want to impose unless there’s a genuine security-related reason to do so. That’s why our tombstoning policy only kicks in after the repository has met certain criteria, such as exceeding a specific number of clones.
Before that it was possible to contact support to reclaim any username provided that they had no meaningful public repos and they were inactive for a long time. It was at the staff's discretion, there wasn't an elaborate policy of what constitutes inactive, but I've successfully reclaimed a username inactive for 2 years myself.
The old policy was:
GitHub account names are provided on a first-come, first-served basis, and are intended for immediate and active use. Account names may not be inactively held for future use. GitHub account name squatting is prohibited. Inactive accounts may be renamed or removed by GitHub staff at their discretion. Keep in mind that not all activity on GitHub is publicly visible. Staff will not remove or rename any active account.
Attempts to sell, buy, or solicit other forms of payment in exchange for account names are prohibited and may result in permanent account suspension.
Meanwhile sometime around there I changed my GitHub username, and not reading up on the suggested process before doing so. The idea was to rename my account, then create a new account with the previous username, so no one else could squat it, as it's my firstname + lastname and the combination seems unique in the world, so it's basically just me. But a few seconds after renaming the account, it got squatted and even requesting to GitHub to reclaim it somehow, has fallen on deaf ears.
Lesson learned, create new accounts and never rename usernames, regardless of what rules the platform might share publicly.
Changing your username would let anyone reuse the old username for whatever they want. Probably still today there are bots squatting any renamed accounts. Also, you bet Microsoft would hand over your GitHub username if it was reported by someone who holds a registered trademark in the US over that username, regardless of impact.
> The utility of AUR is also really based around being able to reuse the same repo without having to re-vet every single time.
I don't think they promise that anywhere, nor should you have that expectation. That would be like since you got legit copy from random-website.com/bin.exe today, you'd get that tomorrow too, clearly not true unless you know the owner of the domain or otherwise trust it.
> go has a software package manager that heavily uses GH for distribution, and is arguably more VCS decentralized, but isn't vulnerable to this kind of attack
Unless Golang suddenly have peer-reviewed packages, Golang has exactly the same problem as AUR in that anyone can create packages, and it's up to users to decide what to trust or not. Fair that the whole "orphaned packages" thing doesn't exists in Golang, but I think Arch probably favors stability more than people expect/think, that's why people can continue to maintain packages even though original maintainer disappears. Ultimately it's a trade-off, I don't think there is some absolute truth what is correct or incorrect.
Regardless of who maintains the package, if you use AUR as intended, it seems you'll avoid most security issues. It's when your expectations aren't aligned with what AUR actually promise, that people start getting hacked.