Arch has evidently stopped new AUR registrations for the time being while maintainers scrub malware and users debate how to harden the popular community repository.
We’ve been telling you since Friday about an ongoing saga at Arch Linux over malware packages showing up in AUR, a user software repository that’s pretty much unique to Arch. Since the repo contains mostly user-contributed software packages, it’s been collectively considered to be a security event waiting to happen. The oracle was right.
Although things seem to be quieting down a bit — we’ve heard no new reports of newly discovered poisoned packages since early Sunday — there is news to report. It appears that AUR maintainers who’ve been working overtime to remove malware-laden packages and delete their committers’ accounts, have now blocked new AUR registrations.
As far as we know, there’s been no public mention that this has been done, but the AUR registration page now returns a “this site can’t be reached” error while the rest of the site appears to be working as normal. At the very least, this move will give maintainers time to catch up on their cleanup work before eventually and inevitably turning their attention to tightening security.
Users Weigh In
Similar moves to this have been being suggested on AUR’s mailing list since the malware issue began, with many users suggesting that AUR maintainers make the site “read only,” as a temporary solution. On an r/linux subreddit post linked to our coverage, there was no shortage of solutions being expressed, some of them worth repeating:
- AUR needs to be rebuilt from the ground up. Move popular packages into a community repo. Have a group of trusted users vet every time a package gets an update, some of this can be automated if only the hash from the source tarball changes in the updated PKGBUILD and I wouldn’t be surprised if there are ways some packages could be automated so a human doesn’t need to check it each time. Nixpkgs has over 140k packages in their official repo and it has been working well so far.
–adamkex
- I completely agree, this is basically what I was saying the other day. I really think they should move towards making it an official repo with CI-built binary packages, and require auditing based on user trust scores.
Not a trivial change, and it will slow things down, but it would be miles better for everyone.
I figure some combination of time served, packages maintained, and/or endorsements by other users could dictate your user’s trust score.
–nullptr777
Can you elaborate on the user trust score system?
–adamkex
A user’s score would then determine how their endorsement of packages is weighted. So a user with a very high trust score might be able to endorse a PKGBUILD all on their own, or it might take 10 users with a lesser trust score.
Something like that anyway. Obviously simple source/hash bumps could be automated as you said.
–nullptr777
Anatomy of the Intrusion
At this point, there’s as much that we don’t know as we do know, and that’s quite all right from where I sit. Suffice it to say: we know enough.
Initial reports were that 400 packages were affected, that AUR’s maintainers went into high gear, and took care of the problem. By the end of the story’s first chapter, the total number of affected packages sat at 1,500 packages. Case closed.
After that, we heard about another round, this time more sophisticated and harder to detect. There were obviously additional packages involved, but not much emphasis on keeping a running count, although there were some numbers floating around.
Meanwhile, we’re keeping an eye on this and will let you know something when we know something.
Christine Hall has been a journalist since 1971. In 2001, she began writing a weekly consumer computer column and started covering Linux and FOSS in 2002 after making the switch to GNU/Linux. Follow her on Twitter: @BrideOfLinux
Be First to Comment