161–170 of 234 posts
Earlier quoted context omitted.
This is an "in addition to" problem though, not an "instead of" problem. Having code reviewed the PKGBUILD doesn't mean the upstream software is safe to use, having reviewed the upstream software and it's dependency tree doesn't mean the PKGBUILD is safe to use.
Also have realized at some point that reviewing the PKGBUILD and code in github repo still doesn't check whether the github release files are compromised.
This campaign is still ongoing. I just got an email that one of my old packages (which hasn't worked for years and was orphaned for a while) was adopted and immediately a malicious commit was pushed. They seem to be using bun instead of npm now, so any npm-based workaround likely isn't effective. https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...
Earlier quoted context omitted.
I have opencode review it for me. Works great. With the opencode-pty plugin it operates a terminal like a human would, runs yay, opens the pkgbuild in vim when yay asks it, reviews, etc etc. gives an `n` at the end cancelling the operation and gives me a report. I read that and then upgrade. For non-famous 3-4 aur packages I have, I have it read the code itself. It's enough to catch the non-jia-tan problems.
You know that prompt injection is a thing, right? Giving opencode access to bash and malicious input is not very far from piping it right into bash.
> Giving opencode access to bash and malicious input is not very far from piping it right into bash.
It is very far, obviously. If you have N AUR packages, it needs to send `e` and `:q` N times using the pty tool. You can have it ask you for permission everytime and approve (2N times) (note that when you use yay, you have to press enter N times anyway! so this is just N extra enters but in the opencode UI) or you can even automate an interceptor that checks that it only sends e and :q and no other strings.
Earlier quoted context omitted.
> You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. But isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package, etc? (Unless you are running them somewhere without internet access or without access to anything you don’t mind being public?) Maybe it’s not the case for aur, but the…
> isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package Yes, and all of those have supply chain hacks in them, and have happened within the last year? In this specific case, it's a malicious npm package being installed with official npm tooling in the PKGBUILD. The advantage to the AUR is just that you can reasonably review every PKGBUILD for w…
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.
Earlier quoted context omitted.
> For every single update, for all your AUR packages, all the time. Yes, that's what I used to do when I ran Arch. It's usually easy. The PKGBUILD is usually small to begin with and the difference for a new version should normally be something like the URL and the version number and not much else, so you can just diff it against the old version.
paru presents all pkgbuild diffs to you before installing, that's what I use to read them. I usually only use AUR to install trusted pre-compiled binary packages, the scripts are very simple and the only thing that should ever change is the url and the sha256
Also paru shows you coloured code syntax if you have `bat` installed, i think.
Here's an easy script to scan for compromised packages: https://cscs.pastes.sh/aurvulntest20260611.sh Not my script. It's easy to read/parse. Never pipe a script directly to bash.
A quicker alternative: comm -1 -2 It's never a bad time to learn about comm(1).
It seems like the AUR should change the orphan recovery process, and helpers should probably offer a minimum package age feature like pnpm.
Earlier quoted context omitted.
This is an "in addition to" problem though, not an "instead of" problem. Having code reviewed the PKGBUILD doesn't mean the upstream software is safe to use, having reviewed the upstream software and it's dependency tree doesn't mean the PKGBUILD is safe to use.
Also have realized at some point that reviewing the PKGBUILD and code in github repo still doesn't check whether the github release files are compromised.
Yup. Every time, I guess it's one of the most common attack vectors, can we do anything to secure NPM more against these supply chain attacks? I swear NPM is always involved in all sizable attack vectors these days.
Earlier quoted context omitted.
Yes, use a distro with good security posture such as Debian to reduce risk.
Are the packages in the repositories of arch also affected? No? Then it's not a problem. Every device in this household that isn't a smartphone runs on Arch. All my servers run on Arch. Never had a problem, because I don't blindly install stuff from the AUR.
People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs. You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. This really has always been the case; we've had discussion about this for well over a decade. People are always asking why there's no official AUR helper like yay - this is why. A lot of people complain abo…
> You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. But isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package, etc? (Unless you are running them somewhere without internet access or without access to anything you don’t mind being public?) Maybe it’s not the case for aur, but the…
It's also a good thing that Arch Linux has people hawking it, so if these things happen they get caught on insanely quickly. I wonder if there's sane ways to protect your dotfiles from rogue processes just touching them.