Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

It's hard to take the rest of your comment seriously when you don't seem to have a basic understanding of the parts involved here. Arch's distribution model isn't at all like npm (which I guess is what you're actually talking about here), but the AUR specifically is pretty similar to npm. But the AUR isn't Arch's main distribution model, and the official Arch repositories contain a ton of packages in the core, so not even the "barebones core" is correct here.

Arch has pretty much lived off the experience of its users, which is the entire purpose and value-proposition of the OS. You want someone else to be responsible, you're welcome to use the countless of other distributions, Arch is quite literally not the OS for a "Don't read anything and press Update, hope for the best" experience, and I hope the core team continues to push back against that, which they've done for decades at this point.

It's sad, because overall you have a point somewhere there but the big misconceptions kind of hide that message though.

Why not? I agree some limits should be added, but also shouldn't be too limited, then lots of things that could be properly maintained, won't. Maybe limit adoption to one package a month or something, to users registered since some date. But no one has automatic (& unreviewed) updates applied to their locally installed AUR packages (that'd be utterly bananas) so the attack vector is already pretty small here.

I don't think that narrative is supported by the numbers. Arch's repositories are about a magnitude smaller than either the AUR or "batteries included" distributions like Debian. (about 10k to 100k packages), there are more people using Arch derivatives than arch, and according to some community polls, granted I can't verify their methodology, something north of 90% of arch users use the AUR.

If you look at the most popular packages in the AUR, it's the most popular web browsers, virtually every VPN client, popular professional software like davinci, incredibly popular messaging clients, Spotify, Zoom, billion+ userbase software and the vast majority of password managers.

And if you look at who maintains those, it isn't the company, in many cases it's a random pseudonymous user who doesn't show up on Google. And I don't get this strange aggressive tone of suggesting I use something else. I do already, because as should be obvious I think that's a bonkers security model, but it deserves to be pointed out.

I do not think that the majority of people running arch today in practice realizes that their password manager they installed from that repo everyone uses is managed by an absolutely random person on the internet.

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

https://docs.github.com/en/site-policy/other-site-policies/g...

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.

https://github.blog/security/supply-chain-security/how-to-st...

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.