Live data from Hacker News

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

phoronix.com

211–220 of 227 posts

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

#211

Earlier quoted context omitted.

There is pkgsrc-wip which is similar but run by one person who does at least some checking up on new users. AUR is just gigantic in comparison; pkgsrc-wip has about as many total packages as AUR has updated in the past week. https://www.pkgsrc.org/wip/

But why check the user instead of the actual code? That's like asking people to checking the GitHub user before they install a program from GitHub, instead of the program itself! Ultimately, the PKGBUILD is the only thing that matters here, not the author or how many others reviewed it.

That isn't what I ment, I should have said that the person who runs pkgsrc-wip helps submitters get the package correct (which can be more challenging than PKGBUILD since it is a more strict system and unless it is a Linux only package is more likely to need patches). Thinking about it more it isn't really the same as AUR since as I understand it packages without issues are likely to get into pkgsrc proper in most cases so it is mostly WIP as the name suggests (although not entirely as I recall, at least last time I used it). So you might be correct that there isn't really anything similar in the BSD world.

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

#212
post #26

"linux has no malware, windows bad boooh"

"linux has a central package manager with every app that you need, so you don't need to install random apps from random websites like on windows"

> central

That will end badly at some point

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

#213
post #164

Earlier quoted context omitted.

Thank you for this! I only had two on my system, thank goodness. I have uninstalled both. libgdata 0.18.1-5 qt5-3d 5.15.18-1

Have you checked the install date? I'm not sure which are the compromised version numbers, but if they were installed before June 10 you're probably safe. (I think libgdata 0.18.1-5 used to be on the main repos in February, and has recently been downgraded to AUR, so you may be fine). Only packages from AUR have been compromised, meaning a normal update `pacman -Syu` won't install them, they'll only be installed by `…

These were installed before June 10th I am almost certain. I will read that link just to be safe!

Looking at my pacman cache both of these versions existed on my system before June of this year so I think I am okay.

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

#214
post #5

I cringed hard when some people started to make pacman wrappers that could install from AUR directly. I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.

People continue to criticize Arch for being elitist or gate-keeping to keep casuals out but there are clear benefits by not allowing dangerous things to be simple. This is true in many aspects of life. After using Void Linux I switched to `aurutils` to get a similar separation on Arch. I can easily maintain a local AUR repo by compiling/making my own binaries and can use `pacman` to install and manage them which impr…

> People continue to criticize Arch for being elitist or gate-keeping

I have the complete opposite experience. Arch makes it easy to get in and get hacking right away. Their beginner guide's on the wiki were a gem 10-15 years ago... made it super easy to get up and running. I don't have the time these days to tinker - but boy do I love some Arch.

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

#215
post #134

Earlier quoted context omitted.

i read all the pkgbuild diffs, still doesn't give me a good sense. sure, i can verify that it's coming from the official repo but even then there's no guarantee that there isn't junk in there or that the git ref is actually pointing at the right thing. it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonab…

> it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture. Ok, so instead of having a reasonable security posture yourself, you'd rather rely on a number of random strangers who've eyeballed the PKGBUILD instead? Generally, I think Arch tries to prevent users from relying on bad signals,…

pretty much all of them. the diffs only really show that it's coming from the same source, the changed hash and maybe some urls for some patches. actually looking at what is in that changed hash is a much more complicated story. this gives end users a false sense of security ("i read the diffs" -- not really), and attackers a clean vector (all it takes is one bad commit that might not even be on a real branch, or linked patch or late download dependency in the package itself).

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

#216
post #5

I cringed hard when some people started to make pacman wrappers that could install from AUR directly. I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.

AUR and similar repos for other distros scare the hell out of me. Tutorials using them are so widespread… Start feeling like a weirdo for not wanting to give an unknown rando full indefinite root access to the system, with virtually zero peer review… all to install one version of a package where updates are undesired or infrequent…

You don't have to. The AUR is just a bunch of PKGBUILD text files, which if you don't feel competent enough to read and understand and trust, you can create your own local versions of and install from. It's just a recipe file that says download a program from this github URL, make sure the hash matches and then extract it and move the files to system directories.

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

#217

Earlier quoted context omitted.

Min Release Age of 7-30 days covers the majority of potential issues with 0 effort. All major Node package managers should support it by now. Prom was the best IIRC, yarn second, but even npm is catching up

We’re using an internal package repository that acts as a gateway to the public package repositories, except it can have custom rules such as “min release age 30 days”, and can also give logs about which projects have actually downloaded a specific version. It’s so much overhead and auditing to enforce compliance across the thousands of node microservices though.

That’s a great idea. Maybe use Claude Code with some owasp knowledge to sweep through them and see if there’s anything obvious?

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

#218
post #215

Earlier quoted context omitted.

> it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture. Ok, so instead of having a reasonable security posture yourself, you'd rather rely on a number of random strangers who've eyeballed the PKGBUILD instead? Generally, I think Arch tries to prevent users from relying on bad signals,…

pretty much all of them. the diffs only really show that it's coming from the same source, the changed hash and maybe some urls for some patches. actually looking at what is in that changed hash is a much more complicated story. this gives end users a false sense of security ("i read the diffs" -- not really), and attackers a clean vector (all it takes is one bad commit that might not even be on a real branch, or lin…

> the diffs only really show that it's coming from the same source

What else do you have to review? Both in the cases of binaries and source, the idea is that you trust upstream already, otherwise you shouldn't install software from them. And since you trust upstream, the only thing you need to review in the PKGBUILD is quite literally: Where is this stuff coming from, is it the official domain/repository? Are there other non-official dependencies? Are there patches applied?

Once you've reviewed those, you're done, and as safe as if you installed straight from upstream, zero false sense of security here.

You're mixing concerns here, as what you describe is completely different issue.

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

#219
post #13

Earlier quoted context omitted.

`yay` (one such wrapper) shows me the PKGBUILD diff on every update. The first time I install something I verify the URL, and check any install script etc. seems sensible; the vast majority of subsequent updates are changes to just version number & checksum. A typosquat attack would be very obvious. (It's a bit vulnerable to it on first install, but so is 'just navigate to the project website [and click download]'.)

and how many of others do the same? At least I'm not.. Happily I have only a few aur packages

I'd recommend that you do – it's not very taxing, and if you only have a few then you won't even be doing it much. I'm not auditing the program code itself (where even available), literally just checking that the AUR package actually installs what it says it does/I expected.

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

#220
post #215

Earlier quoted context omitted.

pretty much all of them. the diffs only really show that it's coming from the same source, the changed hash and maybe some urls for some patches. actually looking at what is in that changed hash is a much more complicated story. this gives end users a false sense of security ("i read the diffs" -- not really), and attackers a clean vector (all it takes is one bad commit that might not even be on a real branch, or lin…

> the diffs only really show that it's coming from the same source What else do you have to review? Both in the cases of binaries and source, the idea is that you trust upstream already, otherwise you shouldn't install software from them. And since you trust upstream, the only thing you need to review in the PKGBUILD is quite literally: Where is this stuff coming from, is it the official domain/repository? Are there…

blindly trusting upstream is not really a reasonable posture. that is pretty much the source of all software supply chain attacks.

there is work involved in figuring out how to get the complete diff of the code and dependencies that are included in the change, plus review time. this could range anywhere from 5-10m to 1h per package updated- if not more.

Post reply on HN