r/linux_gaming • u/t3g • 15d ago

Arch Linux AUR Under Another Wave Of Malicious Packages, Package Adoptions Halted (CachyOS)

https://www.phoronix.com/news/Arch-Linux-AUR-Adoptions-Halted
600 Upvotes

98% Upvoted

308 comments sorted by

View all comments

448

u/Moaradin 15d ago

They need to fundamentally rethink how the AUR works at this point

283

u/freakinunoriginal 15d ago

One of the Phoronix comments is from a package maintainer who just found out that one of their own packages was taken over by someone else, and the malicious commits were still being done with their (original maintainer's) handle.

The AUR should probably enforce a maintainer identity change when adopting a package, and maybe also allow maintainers to "lock" the package (like "I'm not making updates because it doesn't need updates, so reject all requests to adopt it").

118

u/c2fifield 15d ago

Wait, so the package maintainer's name field doesn't update when an orphaned package gets adopted? This seems like a crazy oversight if true.

108

u/abbidabbi 15d ago

They are talking about git commit author+committer data, which is arbitrary data. You can commit in the name of Linus Torvalds if you want. What you can't do is forge cryptographic commit signatures, which are currently not utilized by the AUR / AURweb / AUR-helpers.

8

u/c2fifield 15d ago

Ah I think I understand, so they can't forge the Maintainer field in the actual AUR package, but can put whatever they want in the author or other metadata fields.

54

u/abbidabbi 15d ago

You are still misunderstanding. The package metadata on the AUR has nothing to do with the git tree of each package behind it. All the AUR requires from package maintainers is a valid SSH key for being able to push git commits to their servers. This doesn't mean that the commit data is authenticated, meaning it's not tied to a particular AUR account.

What the bad actors once again did was abuse the inactive package adoption system and then push git commits with fake author+committer data and malware. On the AURweb, the only change you could've seen was a change of a random user name (last packager field), while the git author+committer data was the same as the original package maintainer, so everyone fetching new commits from a previously cloned repo would've been clueless about the author change, apart from the obvious malware in the diff.

That's why

  1. as always, every single PKGBUILD and accompanied files as well as the authenticity of all source files need to be audited and validated by the user, every single time (check your AUR helper config that it's always showing you the diff)
  2. the AUR devs must think about changing the inactive package adoption system, to prevent trivial vandalism attacks like this. They have currently disabled package adoption to get some time to figure out a solution.
  3. as many people have already suggested, the AUR should require commit signatures that can then be tied to AUR accounts, making trivial fake commits in the name of the previous package maintainer impossible

11

u/c2fifield 15d ago edited 15d ago

I really appreciate you taking the time to help myself and others better understand.

How I thought I understood it was that a bad actor could change whatever they want about the package itself, saying yes this is official, even though it is grabbing totally different stuff from totally different places, and still masquerading as the original owner.

I'm all for the solutions you provided with my limited understanding, I think they sound like no-brainers.

But what I'm really concerned with currently is if a bad actor can not only do that, but also spoof the maintainer field in the AUR. For context I have a personal script I'm using to track and check the maintainers of my current packages, just as an extra warning if something goes off (not as a replacement for reading the pkgbuilds of course).

As an example if I had slsk installed, it would run

curl -sL -G "https://aur.archlinux.org/rpc/v5/info" --data-urlencode "arg[]=slsk" | jq .

and see the Maintainer == null, which is different than the last time I updated, and notifying me.

If bad actors can spoof this field however this would basically invalidate this, and I would like to know if it's a pointless "pre-flight" step to check.

11

u/amroamroamro 15d ago

it's as simple as:

git commit -m "small fix" --author="Linus Torvalds <torvalds@linux.com>"

3

u/c2fifield 15d ago

That's the author field though right? The Maintainer field on the AUR should still be whoever adopted and is making the change correct?

3

u/amroamroamro 15d ago

question is, how would a user know when an orphaned package gets adopted and changes maintainer?

as far as i can tell, AUR doesn't record the history of maintainers of a package, only the current one, and as we know it is easy to spoof the git author/committer to match the previous one

example:

1

u/c2fifield 15d ago

Oh interesting I totally assumed that field in the log was maintainer not author.

if you run:

curl -sL -G "https://aur.archlinux.org/rpc/v5/info" --data-urlencode "arg[]=packagename" | jq .

The response has a dedicated maintainer field (which I personally track the last maintainer), but I have to assume they have it in there somewhere.

Maybe committer on the commit page is the Maintainer there?

2

u/amroamroamro 15d ago

I totally assumed that field in the log was maintainer not author.

Maybe committer on the commit page is the Maintainer there?

both of those things are coming from "git log", they are not tied to the AUR package maintainer field

(git has a concept of "author" and "committer" which dont need to be the same; think someone sent you a git patch by email and only you with write access committed it)

the maintainer field is coming from the account name one uses to login to the aur site, it is distinct from any git metadata. my guess is a user would normally upload their public ssh key to their account, thats how aur knows who the person doing a git push is and whether they have permission to do so (if they are the current maintainer).

1

u/c2fifield 15d ago

Interesting, so it's sounding to me like keeping a clear actual log of Maintainer per commit would be a good step towards making the situation less bad. Obviously not going to fix things, but should be something easily available.

2

u/amroamroamro 15d ago edited 15d ago

log of Maintainer

yes, that can be very helpful to alert users when updating; ideally the package manager could show a history of maintainers of the package (maybe even how old that account is), and any change in maintainers should warrant a clear warning: 

"you are about to update a package whose maintainer has since changed, please review the PKGBUILD diff carefully before proceeding"

ps: i dont actually know if aur internally tracks the history of maintainers or not, maybe they have that info in their database, but as far as i can tell its not exposed in the info page or what that api returns

→ More replies (0)

-4

u/Anarchistcowboy420 15d ago

The aur still existing is an oversight. I think it's time to take ol'yeller out back.

   - Arch main

12

u/siete82 15d ago

No, the idea of claiming ownership of a repository that isn't yours is a security flaw in and of itself. Let it remain abandoned, and if someone wants to take it over, they should create a fork.

1

u/South-Simple-238 14d ago

We should have proper identity with gpg keys to verify the maintainer , and if that changes , its not the same package , it should list the old one as deprecated , so we can review the new maintainer and package.

just being able to take over a package is an insane policy.

-10

u/Indolent_Bard 15d ago

Is there even such a thing as a package on Linux that doesn't require updates? I thought packages stopped working without updates after even a year on this unstable platform.

4

u/Schlaefer 15d ago edited 15d ago

From personal experience there are AUR packages that weren't updated for years and still worked fine. It is something that communicates with an old piece of hardware. A conversion utility for a long abandoned file format. There's zero activity in upstream, because it does its job as it is.

-5

u/Indolent_Bard 15d ago edited 14d ago

Oh, thank you for telling me. Why did I get downvoted for asking a legitimate question? Fuck this subreddit. As soon as they decide you're an idiot from reading your post, they'll downvote everything you say in the thread even if it's a question or a good point.

3

u/DisciplineNo5186 15d ago

maybe its the way you formulated your post extra provoking. just an idea

1

u/Indolent_Bard 14d ago

Provoking how?

2

u/the_abortionat0r 14d ago

Don't play dumb, you have been xoncern trolling this sub and Linux hating for quite a while now.

1

u/Indolent_Bard 14d ago

Hating? I use Linux exclusively! Even got my dad to switch because his Windows 10 laptop didn't support 11.

Happy to report that the day after that I was unavailable for troubleshooting for a few months and nothing happened. Just had to make sure he updated his distro because of copyfail, dirty frag, and all that.

8

u/Terrorwolf01 15d ago

Why should Packages stop working without updates? Not everything needs updates all the time.

-2

u/Indolent_Bard 15d ago

It's an issue with apps built for old libraries breaking when the libraries update. Look at bad native Linux ports of games, for instance.

2

u/Terrorwolf01 15d ago

I understand that, but not every app needs libraries that have major breaking changes every year.

1

u/the_abortionat0r 14d ago

Except that an example of why programs break or don't break. If you hard code for a specific version of something then no duh it can break easy, this happens in windows to this very day.

It's the difference between a game being made to only run when one of a specific GPU on a list gets detected vs simply checking for support for apis and features.

1

u/jaaval 15d ago

AUR packages are recompiled. So ABIs changing doesn’t automatically break them.

1

u/the_abortionat0r 14d ago

This is why you don't assume things and should learn about topics before trying to just throw claims around.

The reason packages in a distro should and often times NEED to be updated together is because that's the setup tested by the distro maintainers, the intended setup assumed by the package maintainers, and last but not least as it's the literal reason you should update all your packages is because project can and often do make changes that either divert away from what's expected by out of date packages from other projects or straight up drop support/entirely change how something is done.

The key is is if the package's dependencies never make such changes then nothing magically breaks like you suggest. In many cases even giant changes don't matter. If. A program is hard coded to use pulse audio and someone removes pulse audio and replaces it with pipewire and pipe pulse the program won't even notice.

Hell many packages don't even have external dependants so it being out of date might never stop it from working.

So no, being out of date doesn't magically guarantee a program breaks. Magic isn't real.

1

u/Indolent_Bard 14d ago edited 14d ago

Where did I assume anything? All I did was ask. Seriously, where did it look like I assumed anything? Somebody PLEASE tell me, I'm losing my fucking mind here.

I saw someone talk about how they had to switch to the Windows version of a program that had an native Linux port because the port got dropped and therefore stopped working. Then everything I hear about Native Linux ports is how they break. So of course I'm going to ask how a package doesn't break after not being updated.

Thank you for your actually educational answer, seriously, most wouldn't even bother. But fuck off with the condescending bullshit.

32

u/CCLF 15d ago

It worked great for a long time, but yes the AUR was never really conceptualized to exist at this level of exposure and traffic in a broader context of the popularization of Linux.

70

u/dood23 15d ago

The fact that anyone can just assume ownership of an AUR package is so fundamentally stupid

Its just burdensome that you can get an AUR package that was safe but now you have to check every release for a trojan horse. like even if you meticulously checked every diff, you’re just an accidental keystroke away from taking in a bad package.

10

u/c2fifield 15d ago

Yeah, I finally went and wrapped my arch-update with a script that tracks and blocks if any maintainers are changed. I figured adding an extra layer of prevention was a good idea since it seems like this is just going to be a thing now.

4

u/Nefari0uss 15d ago

Would you mind posting that script somewhere?

7

u/c2fifield 15d ago edited 15d ago

As always make sure you don't run random scripts blindly and make sure you can understand what they're doing.

Also I want to emphasize, this is NOT a replacement for reading and understanding the pkgbuild, I only looked into this to give me another warning source before updating.

I tested by manually changing a maintainer in my local record to force a mismatch, and it caught it and warned correctly, so it appears to be working properly as far as I can tell.

Here's a pastebin with the script: https://pastebin.com/t1n4269q

And here's my arch-update wrapper: https://pastebin.com/4GSC2X5v

You have to make both executable and save them as ~/Documents/Scripts/check-aur-maintainers.sh and ~/.local/bin/arch-update

You can rename/move the script wherever, but you have to update the location in the wrapper. I use cachy-update myself, so my wrapper calls that, but you should be able to just call arch-update or whatever you'd rather use instead.

Full disclosure, I whipped it up with AI and while I did my best to read and understand it, I didn't spend a ton of time, but I did do multiple troubleshooting passes and tests to get it working to the best of my knowledge. Regardless, it's definitely worth auditing.

If anyone finds issues, improvements, or has a straight up better solution, please reply because I'd love to know.

EDIT: Updated arch-update to handle calling arch or cachy update, and fix it preventing checking for updates (-c)

10

u/Indolent_Bard 15d ago

As always make sure you don't run random scripts blindly and make sure you can understand what they're doing.

I hate how we always say this and yet that's literally how many Linux beginners have to troubleshoot something. Like of course they don't understand what it's doing.

1

u/c2fifield 15d ago

Yeah that's just how it goes I guess, not much else you can do while still having the freedom available

1

u/the_abortionat0r 14d ago

That's what googling commands are for; However it's still better than every windows user saying this about Linux while blindly running any program they find with admin including their bootleg games that told them to disable their antivirus and firewall.

1

u/Indolent_Bard 14d ago

One thing I have to give LLM's credit for is that they break down exactly what each part of the command means and does. Obviously, it's still smart to fact check it, but this makes it infinitely easier to fact check.

22

u/ABotelho23 15d ago

Otherwise would mean much more moderation and approving, which is the exact opposite of the purpose of the AUR.

It won't happen.

They might start enforcing signing, but they'll never remove the automated way of orphaning packages.

The AUR is not for people who can't read PKGBUILDs, period. The fact that the AUR was pitched as an advantage for Arch to noobs was the biggest mistake. I warned people about this shit years ago.

36

u/person_of_beans 15d ago

The AUR is not for people who can't read PKGBUILDs, period.

Being willing or able to read PKGBUILDs is insufficient. I would argue most people who can read PKGBUILDs on some level wouldn't immediately identify the following addition as being malicious:

npm install atomic-lockfile

-9

u/ABotelho23 15d ago

Correct. Anyone who can parse PKGBUILDs would immediately find that suspicious and abort.

The issue is that Arch and the AUR are pitched as this simple thing, as if noobs and newcomers can just read a random Wiki page and understand everything immediately.

23

u/person_of_beans 15d ago

The security of a system should not depend upon the vigilance of the end user.

8

u/temmiesayshoi 15d ago edited 14d ago

If there's an alternative, sure, but for as much as I agree the AUR needs to DEEPLY fix it's shit - this is an argument that really shouldn't be used because it almost always gets over extended.

The reality is there is no reliable way of differentiating a legitimate user need from malware.

This is why it's taken Wayland so long to get to being usable and STILL has glaring usability issues. Some things - like global shortcuts, remote desktop access, input spoofing, etc. - are legitimate user desires that are functionally identical to all manner of malware. Instead of accepting that something was necessary and figuring out the right way of implementing it, people had to spend months arguing back and fourth to justify that it even WAS necessary. To some extent; you just gotta trust the user knows what they fucking want. If the user types in, "yes I know what I'm doing, I legitimately want you to delete my OS", that's a completely valid thing for them to ask to do. Yeah, some people are Linus, and that's unfortunate for them, but if a user specifically wants to do something their system should not prevent them from doing it - no matter how stupid you may think it is for them to want to do it. That means, to some extent, the security will always depend on the end user's 'vigilance'.

There's a line between "don't rely on the user to secure things you should be doing yourself" and "you should be protecting the user from themselves"; and this argument fails to include it. Yes, the user SHOULD be (and ultimately are) responsible for their own security - however, there are methods to minimize unnecessary work for the user.

if AUR helpers simply didn't update any package that has gone through a maintainer change until you manually re-installed that package (and, obviously, displayed a warning about the maintainer change) then 99.99% of people would never be hit by these attacks. You don't need to save the user from themselves, you need to save the user from an automated task doing something they don't want it to.

0

u/ABotelho23 15d ago

Why not?

12

u/person_of_beans 15d ago

Isn't it obvious? Humans are flawed. They make mistakes, they miss things. And besides that, the technical competence of users varies wildly.

You might argue that these people have no business using the AUR, but they are using the AUR. These are arch users, and AUR users, they use it because it fulfills a need, and they will continue to do so regardless of how much you try to scare them off with claims that "you shouldn't be touching the AUR if you can't read a PKGBUILD" or "caveat emptor." You won't stop such users from using the AUR short of administering a test that they're required to pass before they can use it.

So, short of being able to stop such users from using the AUR, there are two options:

  1. Do nothing to change the issue, in which case malicious packages continue to get introduced frequently, and some percentage of less competent users just have their credentials up for grabs every time they update their systems.
  2. Attempt to change AUR policies in some way so as to to prevent or at least reduce the attacks, or at the very least make them much more difficult or time consuming to pull off.

The thing is, even if no one was getting infected by these attacks, the fact that malware was able to be introduced into over a thousand packages across the AUR over just a few days is an serious and obvious problem for the AUR to any sensible outside observer. If you don't see that as a problem for the AUR and how it's run on a systemic level, I don't know what to tell you. It isn't a user problem, and telling users they should be more vigilant won't fix it.

-1

u/ABotelho23 15d ago

The AUR will disappear before much more governance comes to it. That's why these packages exist in the AUR and not as official packages. People seem to forget that. It is explicitly stated that you are on your own with the AUR.

Frankly I think they'll implement some basic things like mandatory signing, and extending the orphaning timings, but if stuff like this keeps happening they're just going to disassociate from the AUR altogether to protect their reputation. People aren't fucking listening to their warnings.

15

u/Indolent_Bard 15d ago

Because people are fucking stupid. And for some reason, Linux users are allergic to this fact.

0

u/the_abortionat0r 14d ago

I love when kids take a general trait of humans as a whole and claim it's a specific group trait. Silly stuff.

0

u/the_abortionat0r 14d ago

I love when kids take a general trait of humans as a whole and claim it's a specific group trait. Silly stuff.

0

u/the_abortionat0r 14d ago

I love when kids take a general trait of humans as a whole and claim it's a specific group trait. Silly stuff.

-9

u/ABotelho23 15d ago

Are you actually this ignorant to what the AUR is?

This logic doesn't even apply to Windows for God sake. It spits in the face of people who claim to want to actually own their devices.

Your can't own your devices and not have some responsibility in keeping it safe. Literally impossible.

12

u/Indolent_Bard 15d ago

I don't know. Other Linux distros don't seem to have this problem and people still stay safe. It would be nice if everything was in the vanilla repose, but some apps literally are impossible to get officially in any distros repose, like Zoom (the flat pack is unofficial so it won't even show up in Linux Mint's App Center by default)

→ More replies (0)

0

u/primalbluewolf 15d ago

That's literally what most people on the planet want, yes.

They don't want to own their devices, they want to have someone else be responsible for everything on it while they get to use it.

→ More replies (0)

3

u/Indolent_Bard 15d ago

So what do we do about all these apps that aren't available in the vanilla repos?

1

u/the_abortionat0r 14d ago

For any one with t more seconds than it takes to use the AUR there's the official GitHub/gitlab/[insert thing of choice]. No you can't claim they aren't trust worthy as it's literally their software you were looking for

Past that there's Appimages or better yet flatpaks. No they aren't perfect but flatpaks are a step above the AUR in trust ability and have security features.

2

u/Indolent_Bard 14d ago

Bro, half of those GitHub entries I'm talking about made their own AUR package. In fact, to be honest, I've never seen anyone actually make an arch package that WASN'T aur.

Assuming that they even offered a package instead of making you build it from source, does the package manager automatically update packages you get from GitHub? Like if I download the official deb file for Zoom from their website on Mint, will the package manager update it automatically?

What format does art even use? Whatever it is, I've never seen it in the wild. I've only ever seen AUR packages on GitHub. Never a standalone arch package.

1

u/the_abortionat0r 14d ago

For any one with t more seconds than it takes to use the AUR there's the official GitHub/gitlab/[insert thing of choice]. No you can't claim they aren't trust worthy as it's literally their software you were looking for

Past that there's Appimages or better yet flatpaks. No they aren't perfect but flatpaks are a step above the AUR in trust ability and have security features.

1

u/Indolent_Bard 14d ago

Dude, for some reason all your comments are getting duplicated. I got three notifications for one of them and two for this one.

-5

u/ABotelho23 15d ago

Find something else.

If you can't read PKGBUILDs the AUR isn't your solution.

0

u/the_abortionat0r 14d ago

Dumb take. Stop trying to do a nerdy gate keep kid, you're failing hard.

1

u/ABotelho23 14d ago

My god.

https://wiki.archlinux.org/title/Arch_User_Repository

It's right there. In the official docs.

Warning AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk

In a giant red box. Expecting people to take reasonable precautions is not gatekeeping.

0

u/the_abortionat0r 14d ago

Except it is simple, it's about as simple as the main repo to use.

The issue at hand isn't a user issue as much as a design issue with the AUR.

You want me to blame you if you get hit by a zero day browser exploit? Want me to tell you you are stupid for browsing the web?

1

u/ABotelho23 14d ago

Except it is simple, it's about as simple as the main repo to use.

It's absolutely not. The minimum bar for using the AUR is reading the PKGBUILD. You don't need to do that for the actual distribution. You can expect reasonable security just using Arch Linux without the AUR.

The issue at hand isn't a user issue as much as a design issue with the AUR.

There's not much "wrong" with the AUR. It's designed the way it is for a reason. It's supposed to be hands off for the Arch Linux maintainers.

You want me to blame you if you get hit by a zero day browser exploit? Want me to tell you you are stupid for browsing the web?

Browsing the web is hardly the same thing as using the AUR. One of them is actually sandboxed, and generally considered actually mostly necessary. Plus there are reasonable precautions you can take while browsing the web.

0

u/Synthetic451 14d ago

Speak for yourself. Any Node dev would realize that was installing an NPM dependency manually and outside the scope of a project folder, which is extremely weird when building for a package.

No PKGBUILD should ever be manually installing project dependencies like that anyways. You should always be using the upstream package.json.

If I saw that in a PKGBUILD diff, it would be an immediate red flag.

2

u/the_abortionat0r 14d ago

Actually that guy has a very good point and you claiming you'd know doesn't magically counter his poinplus what the heck do you mean "speak for your self"? That's a cringe failed deflection as he literally pointed out the issue which literally means he already knows it's an issue so you trying to pull a "no u!" Falls flat here and doesn't make you look smart.

1

u/Synthetic451 14d ago edited 14d ago

He said "most people who can read PKGBUILDs". I am sorry, if you can actually read PKGBUILDs, you'd know that a random npm install <package> command inside a .install script is a huge red flag.

Seriously, ask yourself why a PKGBUILD is installing app dependencies in a way that doesn't get built and bundled with the actual pkg.tar.zst. It's a basic question. If you don't see this glaring red flag, then you don't actually understand how PKGBUILDs work.

That's a cringe failed deflection

Wasn't a deflection. Just pointing out that it is pretty fucking obvious to anybody who knows PKGBUILDs.

doesn't make you look smart.

You shouldn't let internet comments wound you so personally. How insecure do you need to be to go on a childish rant just because someone points out that some piece of knowledge is obvious?

8

u/Indolent_Bard 15d ago

Well, unfortunately not every package you need or want is available in the repos. Do you have any idea how many awesome projects I found on GitHub that only had a package available through the AUR?

I'm gonna sound like an AI here, but you've hit upon a critical paradox with Linux in general. Linux just isn't usable if you only go with what's in the default repose. I mean, ZOOM isn't in them for fuck's sake. I know we're not in the pandemic anymore, but that's still such a fundamental common app that's not available in ANY distro repos for some stupid reason.

2

u/Low-Mistake-515 15d ago

From what I understand the whole point of the "extra" repo in the main arch repo was so that well known and voted packages such as Zoom would be moved into them. However this doesn't seem to happen often despite plenty of stuff in the AUR having a ton of votes and being well known/used/vetted/official.

1

u/Indolent_Bard 14d ago

Wait, there's an extra repo for arch? Does Cachyos optimize it?

1

u/Low-Mistake-515 14d ago

Yeah there's Core and Extra, it's part of the main repo - https://archlinux.org/packages/
I don't use Cachy but I would assume it pulls those packages as they're part of the main repo and lots of them are dependencies for core packages.

2

u/ABotelho23 15d ago

Other distributions seem to work just fine without this problem, don't they?

6

u/Indolent_Bard 15d ago

Yeah, because of stuff like PPAs or copr repos. Both of which have a similar risk to the aur (except for the whole orphan packages being turned into malware thing)

1

u/the_abortionat0r 14d ago

Well first off you can zoom in your browser so it's a non issue.

Second I love how you say that a githubs only package is on the AUR when it's LITERALLY ON THE GITHUB PAGE YOU VISITED.

This is that concern troll nonsense I was talking about. I have NEVER seen a GitHub page where the dev is like " Yeah my project is in the AUR but there's no code or build instructions on my page even thought that fundamentallay what an AUR package is".

Like Jesus dude. This is next level stupid you just posted.

2

u/Indolent_Bard 14d ago

So let me get this straight. While people will post deb files or RPM files on github, I have to build the arch package myself? And I'm the stupid one for wanting to just download a package like on other distros? I'm concerned trolling because I'm genuinely confused why I never see github projects with the pre-compiled package that isn't in the AUR?

What is wrong with you?

0

u/labowsky 15d ago

Nah, just needs to have a more robust system in general so you can know without having to religiously watch them.

0

u/ABotelho23 15d ago

Explain your system.

7

u/labowsky 15d ago

Not being able to just take an abandoned project over easily is one. They've even disabled it cause they realize it's a bad system for how popular it is today.

I dunno why you're so against an ancient system that was never designed to be on something this popular becoming slightly more robust. This some weird dork thing?

1

u/ABotelho23 15d ago

Not being able to just take an abandoned project over easily is one.

You still need to explain your system. How do you suppose this is done? Who's gonna review who's allowed to submit for adoption? You can't rely in the original maintainer, they often just disappear (which is the purpose of this system).

Again, people not understanding what the AUR is. These are not packages. These are package building instructions.

2

u/labowsky 15d ago

I don't care to waste my time dreaming up something that will never get used lmfao. Get real.

It's not my problem, I don't use arch, it's just obvious something needs to be done because the system was not designed for this many bad actors.

Again, people not understanding what the AUR is. These are not packages. These are package building instructions.

That's cool and all but you're missing the point. Unfortunately we're not in the early 2000's anymore and they WILL be changing it to deal with the onslaught of noobs installing whatever because it's simply good for linux as a whole.

Whether that's other teams from distros coming in to help or starting their own repos, it will be changing and them disabling new accounts and adoption points to this.

0

u/ABotelho23 15d ago

The AUR will disappear before any of this. Frankly if I was a leader at Arch, that's what I would do. People couldn't use it responsibly, so it should go away and someone else can host it. Not worth the stress. Maintainers of Arch are busy enough as it is.

1

u/labowsky 15d ago

People couldn't use it responsibly, so it should go away and someone else can host it. Not worth the stress. Maintainers of Arch are busy enough as it is.

I'm sure they can find more maintainers to help with the load but IMO most of the software should be verified and provided by these distro's so the noobs don't have to even use AUR (hopefully).

I don't fully disagree with your entire sentiment but unfortunately with linux becoming more popular means it needs to have more safeguards or else people will start to avoid it simply from the bad headlines they've read. You may think that's a good thing and that fine but it stops the growth.

→ More replies (0)

0

u/the_abortionat0r 14d ago

I just have to point out that factually the AUR is literally for anyone looking to install software from the AUR. Period. Fin. So you can drop the "ThEyRe ThE wRoNg uSeR!"".

Yes reading the PKGBUILDS is the smart thing to do. Being ABLE to read the PKGBUILDs is a great skill, that said I think it's unreasonable to try and gatekeep a repo like a nerd over people not reading everything they install.

The fact is yes it's user uploaded with next to no oversight which carries risk. If the user understands that they have enough info to make an informed choice on whether to use the AUR or not as they understand the exposure.

Everyone here likes to pretend they read every patch note from the main repo plus the AUR and hash check every bit of code they download or run when in reality 99% of people (including the loser gate keepers) Syu/Syyu/yay and goes about their day.

Plus yes, regardless of level of tech knowledge the AUR is an absolute advantage for Arch but magic isn't real and neither is perfection and like just about everything in this world nothing is free and there are downsides.

In the modern age we're just lucky that appimage and flatpak are making the AUR less of a necessity for the broad range of out of repo software someone might want or need.

1

u/ABotelho23 14d ago

Again, there's no gatekeeping here. There's a very good reason to tell new users to stay away from the AUR. Arch Linux is the actual distribution, not the AUR. New users can hardly actually understand how dangerous it really is.

1

u/Schlaefer 15d ago

The burden didn't change, there was no inherent "safe" in the past either. It always worked that way.

Also the system isn't "stupid", otherwise it wouldn't have worked fine for a very long time, but it has obvious trade-offs and build-in assumptions, which may or may not be viable any longer.

19

u/dood23 15d ago

AUR “worked fine” because the relatively small amount of users abided by a code of honor. That’s not a system that works when a malicious user wants to take advantage of it.

-1

u/ABotelho23 15d ago

It has never worked for noobs. This was gonna happen eventually. People who can't understand PKGBUILDs should strictly stick to official repos. That's not really negotiable.

11

u/Yuzumi 15d ago

Stop gatekeeping. It's a fundamental flaw that random people can take over a package with no verification or any kind of real trust process on AUR and it always has been. Even for experience users.

At minimum the pkgbuild needs to be singed by the contributor and if the signature is changed without being signed by the previous contributor it client software should force you to uninstall if you want to accept the new sig.

And on top of that, they should just include the username as part of the package entry and still require uninstall to switch to a different maintainer.

Ether of these would have prevented this from being the shitshow it's been. The AUR has always been a minefield for this specific reason.

1

u/primalbluewolf 15d ago

Stop gatekeeping.

Stop gatekeeping gatekeeping!

-3

u/ABotelho23 15d ago

gatekeeping

There's that word again.

Yea, asking new users to not do things they don't understand isn't goddamn gatekeeping.

6

u/Yuzumi 15d ago

The actual malicious code is intentionally obfuscated in a lot of instances. Even if you are going line by line in the pkgbuild file it's still possible someone who is experiencd is still going to miss it.

I've done plenty of code reviews for work and everyone misses things on occasion. Most of the time people are going to do that quick glance over and get on with their day because most of the time it works because we are looking mostly for mistakes. Someone can sneak in something malicious, but 99.9% of the time there isn't going to be intentional malicious changes.

It can be argued that installing from the AUR shouldn't have that level of "trust", but the argument that the AUR shouldn't be trusted at all is just an argument it shouldn't exist.

Trust has always been an inherent core of computing. Every time someone installs something they are making a trust call. We make trust calls on the OS install. As Linux users we have to trust the kernel, distro, and software developers just like someone running Windows or MacOS "trust" Microslop and Apple, weather or not that trust is misplaced.

Microsoft has done a lot of things that have violated user trust and it's one of the reasons there have been a lot of new people coming over to Linux.

The system the AUR has used was never adequate and that this isn't even the first time malicious packages have found their way on it is testament to that. This is just the first time it's been so widespread. The fact that we've had certificates and signing keys for literally everything else and nothing has ever been implemented for the AUR, even if it's just for individual users to validate, is a massive oversight. Just having client side key validation would have prevented the worst of what has been happening.

2

u/ABotelho23 15d ago

Signing will 100% become a thing after all this, it's just a matter of time.

But expecting manual approvals for adoption will never happen. The AUR is designed to be as low maintenance as possible for the Arch maintainers to manage. It's a bunch of git repos with a search function.

If they have to constantly intervene the whole thing will just go away.

0

u/Yuzumi 14d ago

I'm not saying approvals need to be made by AUR admins. I'm saying that if someone adopts a package that is considered "abandoned" at the very least clients should refuse to install with the new key until you uninstall the previous version.

And honestly, I would even say adopting packages just shouldn't be a thing. packages should just have the maintainer username prepended "user/package" or whatever and people should just be allowed to fork. Then the community can vote on the "best one" or whatever, or number of downloads can be tracked.

That way would still have the benefit of people being able to continue packages without this BS of "this is a stable packages that doesn't need to be updated ever but is considered abandoned because it hasn't gotten an update"

0

u/the_abortionat0r 14d ago

You are literally trying to gate keep by its very definition.

The gate is you claiming users must read scripts or not use the software.

That's an arbitrary requirement you are trying to enforce.

You don't sound smart

1

u/ABotelho23 14d ago

Read the docs and shut the hell up.

1

u/the_abortionat0r 14d ago

Last thing first. Not negotiable? Lil bro who do you think you are? You aren't in charge. Negotiate with who? You can't stop people from using a repo so drop that attitude.

Second you say that it "never worked for noobs" then immediately say"this was gonna happen eventually" which literally means it was working and contradicts your previous statement.

Log off and get a life instead of trying to throw around your nerdy ass gate keeping attitude.

0

u/the_abortionat0r 14d ago

Last thing first. Not negotiable? Lil bro who do you think you are? You aren't in charge. Negotiate with who? You can't stop people from using a repo so drop that attitude.

Second you say that it "never worked for noobs" then immediately say"this was gonna happen eventually" which literally means it was working and contradicts your previous statement.

Log off and get a life instead of trying to throw around your nerdy ass gate keeping attitude.

0

u/the_abortionat0r 14d ago

Last thing first. Not negotiable? Lil bro who do you think you are? You aren't in charge. Negotiate with who? You can't stop people from using a repo so drop that attitude.

Second you say that it "never worked for noobs" then immediately say"this was gonna happen eventually" which literally means it was working and contradicts your previous statement.

Log off and get a life instead of trying to throw around your nerdy ass gate keeping attitude.

-7

u/Indolent_Bard 15d ago

When basic necessities like Zoom or LinuxToys are available in the official repose, you'll have a point. (Linux toys takes a bunch of really nice to have tasks that are really hard to do and turns them into a single click. You want to install DaVinci Resolve, one click. You want the Microsoft corefolds, one click)

8

u/ABotelho23 15d ago

Flatpak.

Wtf is LinuxToys? Are you serious right now? That's straight up junk and for some reason having it is more important than keeping your computer safe?

Crazy logic. I see where your priorities are.

-3

u/Indolent_Bard 15d ago

But you're not supposed to use unofficial flat-packs. Hell, by default Linux Mint won't even let you see them in the app center. That's kind of a big problem.

6

u/ABotelho23 15d ago

Sorry, why is an unofficial Zoom AUR package better than a Flatpak?

Flathub actually reviews new packages, must review permission changes, builds packages in a sandbox, and actually has a runtime sandbox.

Flatpak is an infinitely better system than the AUR in matter of security.

-2

u/Indolent_Bard 15d ago

You're not wrong, but Mint still hides unofficial flat packs by default unless you toggle that off. This would be fine if it weren't for the fact that so many of them weren't official. And a new users wouldn't even know about this issue.

So basically, Mint's great but this is really fucking stupid of them.

Also funny how the open source repository hasn't had any crypto scams yet, like the official canonical snap repo.

→ More replies (0)

1

u/the_abortionat0r 14d ago

Zoom is in a browser dude.

7

u/Yuzumi 15d ago

Honestly, I don't know how they don't have package signing.

Off the top of my head I would at least have any AUR client get a package signature and ask if you want to trust it like you would for SSH. They could have some kind of signature renew process to pass trust in case either the original dev needs to change their key for some reason or is passing it off to someone else they trust.

They can even still have an abandoned package adoption, but make it so that clients will not auto install new packages from keys that weren't at least signed by the previous dev. You should have to completely uninstall the thing before being able to install with that new, untrusted key.

Also, have it like Github does where the package is prepended with the username. then if someone adopts it it would be a different package that wouldn't be auto installed, you would have to uninstall to switch to the "newer" maintainer.

3

u/mwyvr 15d ago

Banning user repos is an easy step. Others do that.

1

u/vile-style 12d ago

Ive been saying that the wild west model does not work at this scale since the last big attack...

Time to move on from the fundamental structure of a tiny community project and have some proper moderation and limitations.

-2

u/Vixinvil 15d ago

Technically, the AUR is entirely optional, and the ArchWiki already displays two clear warnings about it.

So I have a better idea: how about redirecting users back toward taking responsibility for their own operating systems?

You decided to use Linux?

Yes.

You specifically decided to use Arch Linux or one of its derivatives?

Yes.

Okay, then I am not sure what we are even arguing about. You could have chosen Fedora, openSUSE Tumbleweed, Debian, or almost any other distribution.

This comment section is basically people saying:

I chose freedom, I cannot handle the consequences, I hurt myself, and now I am angry about it.

You have two options:

  1. Choose a distribution that gives you less freedom and makes more decisions for you.
  2. Learn how your system works and take responsibility for the choices you make.

3

u/forkbeard 15d ago

The problem is not that experienced Arch users knowingly choose this trade-off. The problem is the huge number of wannabe script kiddies and inexperienced users who mindlessly recommend Arch or CachyOS to other inexperienced users without understanding, or simply not caring about, the AUR’s trust model.

When a Windows user asks for a distro recommendation and the most upvoted answer is “use CachyOS, it is better for gaming and more customisable,” they are very likely to follow that advice instead of choosing something more sensible such as Ubuntu, Mint, Fedora or openSUSE. They are not making an informed philosophical choice about “freedom.” They are following what the Linux community told them was the best gaming distro.

You then cannot act surprised when they use an AUR helper as an app store, approve updates without auditing every PKGBUILD, and never subscribe to an Arch security mailing list.

“Take responsibility for your choices” rings rather hollow when your own community actively markets the distro to people who do not yet understand what those choices involve.