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.
Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
211–220 of 227 posts
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#212Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#213Earlier 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 `…
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
#214I 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…
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
#215Earlier 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,…
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#216I 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…
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#217Earlier 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.
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#218Earlier 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…
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
#219Earlier 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
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#220Earlier 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…
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.