[blcknight]

"Review" them how? Read every single line of code before installing something? If it's a binary package, how do you do that? Make reproducible builds for everything you install? Move to from source distro? Putting this on users is not a tenable solution. There's room for common sense, but blaming the users for this is ridiculous

[yowo]

This is like saying a user who clone a random git repo is not to blame and git-scm should do more to prevent cloning of malicious repos. If it is not official, it is your job to review, if you dont like it, use iOS instead of Arch Linux.

If you crash your car, you are liable for the accident. If you aren't ready for that, take the bus.

More power = more responsibility

[badgersnake]

> If you crash your car, you are liable for the accident.

Because I didn’t go through all the blueprints and find the flaw that led to the crash. This is a dumb argument. It’s also the one the AUR appears to be making.

[homebrewer]

No, it's completely valid. The arch home page warns you that you're the one responsible for your system, and get to keep both pieces when something breaks. Everything is assembled with this philosophy in mind. This message is reinforced ten times more before the system is even installed and is up and running.

If this is not for you, that's fine, but it's been working very well for some of us for... decades, at this point? I'm not amused by the amount of people here wanting to turn arch into another Ubuntu, most of them having zero familiarity with how the AUR works, or arch more generally.

[Barrin92]

>but it's been working very well for some of us for... decades, at this point?

but it's worth asking why it's been working well. Has it been working well simply because it's been a niche ecosystem, or even because you wouldn't have known if it didn't because nobody did security audits?

The Arch distribution model, which operates like the Javascript ecosystem, as in having a barebones core and then a zoo of unregulated third party community packages does not seem fine these days. As it became more popular it has naturally drawn attention and from that moment on you're just screwed because you have no security infrastructure. Arch pretty much lived off security through obscurity.

And in particular with the popularity of these spin offs, I forgot what the name of the tiling wm thing is that got very popular, I think a lot of users are not aware that they're doing the software equivalent of buying medicine off craigslist

[embedding-shape]

> The Arch distribution model, which operates like the Javascript ecosystem, as in having a barebones core and then a zoo of unregulated third party community packages does not seem fine these days

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.

[Barrin92]

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

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.

[naturalmovement]

Uh but this isn't random git repos these are packages available through the OS's repos. Why does the AUR even exist if not for malware distribution?

It's an uncontrolled free-for-all disguised as a watering hole. If they can't do the most basic of housekeeping it should not exist full stop.

[zeta0134]

They *are* doing the basic housekeeping. What do you think this announcement is, if not exactly that? AUR is very clearly documented as user-submitted, and automatic installs from it are heavily discouraged by the maintainers for this reason. Malware aside, there is very little quality control, and a poorly made AUR has the potential to break the system pretty badly. (Though, in my experience, most of the useful AUR packages are trivial to remove if something goes wrong.)

The officially maintained repositories (which are part of a default installation) were not affected. Users need to go somewhat out of their way to use an AUR.

The definition files are all plain text and not especially complicated. It's not too difficult to glance at the file before doing an install to get a basic idea of what it's about to do, just like you should do when running a random shell script or cloning a random git repo. Indeed, most AURs are implemented by cloning an upstream git repo and configuring it so it can be built. The same basic threat model applies: Do you trust the install script? Do you trust the upstream URL whose code it is about to compile?

[a-dub]

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 reasonable security posture.

[embedding-shape]

> 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, and this principle might be applied here too.

> i read all the pkgbuild diffs, still doesn't give me a good sense. sure,

Do you have an example of a diff that doesn't give a good sense? I review all my diffs too, but I feel like all of them give me a good sense if it's safe to install or not. I mean, why would I otherwise, what's the point in reviewing if you don't use it to make a decision if to install it or not?

[a-dub]

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

[zyuiop]

Well ArchLinux has a product for you if you want packages that were vetted: the official repositories. AUR is just a centralized place to put user created packages, like npm is a place to put user created node packages.

[matheusmoreira]

Nothing is "disguised" here. Arch Linux makes an enormous effort to warn that due dilligence is required before installing things, and to dissuade users from using the User Repository at all, to the point of not offering package manager support for it. The wiki even cites previous instances where malware was discovered in the AUR packages.

The only way you could possibly not be aware of the AUR's nature as an "uncontrolled free-for-all" is if you didn't read the Arch Wiki, and anyone who doesn't read the Arch Wiki should not be using Arch Linux to begin with.

"Uncontrolled free-for-all" is exactly the status quo of programming language package managers such as npm and pip. It's just as easy for total randoms to sign up for an account and push packages on those services as it is to push a package to the AUR. Only the AUR made the lack of trust explicit and part of the culture.

[Hackbraten]

> these are packages

PKGBUILDs are not packages. They’re (user-contributed) instructions on how to build packages.

> available through the OS's repos.

No. The AUR is a platform, similarly to NPM or PyPI, that allows users to upload PKGBUILDs. It is not part of “the OS’s repos,” and it says that loud and clear, multiple times, including on the front page.

[kcyb]

As an arch user, I would always skim the PKGBUILD file of AUR packages to see if they install the software they claim to install from official sources and if there's something obviously fishy.

[naturalmovement]

The BSDs prevent this by never having allowed random jamokes to upload Makefiles into the ports system.

[embedding-shape]

Yeah, I've prevented this locally too by never building such a platform in the first place, always the best solution!

Jokes aside and just in case, you do realize ports and AUR have two very different models? Ports is more similar to the official Arch repositories, which obviously doesn't suffer from the same problem, and AFAIK, there is no BSD-equivalent of AUR.

BSD is cool and useful for lots of reasons, but comparisons based on misunderstandings helps no one :)

[joveian]

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/

[embedding-shape]

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.

[joveian]

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.

[Gigachad]

In this case even if you skimmed it you likely would have missed it since the malicious change was adding a new dependency called "atomic-lockfile".

[echelon_musk]

I'd be surprised if you did it as a Debian user!

[t-3]

An archlinux package build file is just a shell script. It's pretty easy to take a look and see if all the manifest info is right and it doesn't do more than ./configure; make; make install DESTDIR=$PKG or whatever. If you're building random software using random instructions from the internet and don't make sure they're not malicious, you only have yourself to blame when you catch something. Actually reading through the source files for vulns is something best left for automatic detection, checking the build script is basic.

[bethekidyouwant]

How is that relevant unless you read the make file?

[embedding-shape]

If you don't trust upstream, a PKGBUILD from AUR is the least of your problem.

[jolmg]

> If it's a binary package, how do you do that?

You find one that builds from source, or you still review PKGBUILD and friends and lean more on evaluating the reputation of upstream and its maintainers, or you simply decide never to install binary packages. Your policy is yours to decide.

> Putting this on users is not a tenable solution.

The alternative would be to not have an AUR. Archlinux has official package repos where packages are vetted. The AUR (Arch User Repository) is not that. The AUR is there to provide greater variety of software than the official repos can, and it does that by not incurring the cost of being individually maintained by volunteer Arch staff and developers. It needs to not incur that cost for it to exist, otherwise it'd just be the official repos. It's like github, but limited to repos with PKGBUILDs.

[embedding-shape]

> The alternative would be to not have an AUR

And in this alternative past/future, everyone is using GitHub to host their PKGBUILDs instead, then someone gets tired/lazy and builds one repository that indexes those, and we have ArchPacBrewRepository or something, and very same issue appears again, unless people change their approach to installing random 3rd party software.

[Gigachad]

The AUR being hosted by the Arch project on the same domain gives an air of authority and reputation to it which is misleading.

[gchamonlive]

Ask an LLM to assess the package and do a web search for you. Nobody is installing tens of packages a day, you can take a few minutes to consider what you are installing. This isn't blaming the user, it's basic digital hygiene.

[embedding-shape]

Lets take two real and random examples, and I'll share what I'd look for:

First, very easy one, we want to install Brave, so we find https://aur.archlinux.org/packages/brave-bin. All the dependencies are in the official repos already, so those we trust already, you open the downloaded PKGBUILD and you find it's downloading a binary from github.com/brave, you check to see it's the official GitHub profile/organization that you expect. Quickly scan prepare/package for anything out of place, like downloading more files not defined in "source" or whatever. In this case, "suid sandbox" stuff should make you investigate closer so you understand what that stuff does, many things related to Chrome has things like that. That AUR package also has a brave-bin.sh, so a look through that would make sense. AFAIK, everything checks out, this is literally just downloading the official release from GitHub, and extracts it into the right place, so if you trust the GitHub org/user, you can trust the PKGBUILD. The PKGBUILD also seems to be officially maintained by Brave themselves, so probably already there you can verify the AUR user and be done if you feel lax.

Second example is unofficial package, https://aur.archlinux.org/packages/lmstudio-bin, maintained by noureddinex and created by MadGoat, neither which seem official at a glance. Read through the comments to see if anyone else flagged anything, seems fine so again go read the source of the package and the PKGBUILD. PKGBUILD seems standard, downloads something from "installers.lmstudio.ai" so first thing to check is if that's actually the official website, so use search engine to find official website, copy the URL of the download, verify it's the same. In this case, lmstudio.ai is the real website, but download URL on website ends up being "https://lmstudio.ai/download/latest/linux/x64" in the HTML/DOM, so use "curl -v -L $URL" to see redirects, and then we've confirmed installers.lmstudio.ai is actually what they use for official releases. Read through "prepare" and "package", both seem standard and fine, then look through the rest of the files, all of them seem fine, mostly maintenance scripts for the AUR package itself. Package seems fine as a whole, and we could install it, if we're willing to review it again on upgrades in the future.

This is basically all you have to do. Writing what I did while doing it, made each "review" take maybe 5-10 minutes, and it isn't harder than that, regardless who the user is. You just need to know what to look for, and think how you'd "officially" install it anyways. And if what the PKGBUILD differs from what you'd imagine an "official install" would do, investigate if it makes sense and if not, don't install the package, maybe leave a comment for others in AUR to dive deeper.

[xnzakg]

Question is if this would be thorough enough for this attack? A package with a slightly more involved build process, maybe some patches because it was made to build on a different distro. Maybe you've already installed (and thoroughly inspected) it before, so you're only updating to a newer version, so you're not as thorough with your review. Or an xz-style backdoor.

[embedding-shape]

Yes, it'd be enough. If a package you're using suddenly adds new 3rd party dependencies, you confirm this is actually needed, and if not, you know something is up. When you install software from random strangers, you have to be vigilant and consider the implications of what you do.

I recall the same situation recently with yt-dlp, as they started to depend on a JS engine for some captcha stuff or related. So when you see that, you need to adjust the mindset of "ah whatever it's probably fine" to "Ok, why are these changes actually here?", and if it's not worth reviewing, you might want to reconsider the approach of installing random binaries from the internet that are flagged as unreviewed.

[clickety_clack]

It’s free lines of code on the internet that you are going out of your way to run on your own machine.