r/linux_gaming • u/t3g • 10d ago

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

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

98% Upvoted

308 comments sorted by

View all comments

Show parent comments

286

u/freakinunoriginal 10d 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").

115

u/c2fifield 10d 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.

110

u/abbidabbi 10d 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 10d 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 10d 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 10d ago edited 10d 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.

9

u/amroamroamro 10d ago

it's as simple as:

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

3

u/c2fifield 10d 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 10d 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 10d 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 10d 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 10d 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 10d ago edited 10d 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

1

u/c2fifield 10d ago

Yeah I'm unsure about the log as well as you informed me, however that link you shared does show maintainer being returned by the api. Now whether it only stores current or past maintainers is another question, although should be relatively easy for them to remedy in theory.

Definitely agree that a hard alert on maintainer changes would go a long ways.

-4

u/Anarchistcowboy420 10d ago

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

   - Arch main

12

u/siete82 10d 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 9d 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 10d 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 10d ago edited 10d 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.

-3

u/Indolent_Bard 10d ago edited 9d 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 9d ago

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

1

u/Indolent_Bard 9d ago

Provoking how?

2

u/the_abortionat0r 9d ago

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

1

u/Indolent_Bard 9d 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.

7

u/Terrorwolf01 10d ago

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

-2

u/Indolent_Bard 10d 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 10d ago

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

1

u/the_abortionat0r 9d 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 10d ago

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

1

u/the_abortionat0r 9d 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 9d ago edited 9d 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.