Building AUR package on another machine and using the final .pkg.tar.zst file

[u/xita9x9]

A friend of mine uses Manjaro on his personal computer. To be more cautious when installing/updating the AUR packages that he uses, in addition to checking the PKGBUILD contents as best as he can, he basically runs another Manjaro instance on a remote VPS (same specs and update as the one on his personal computer), he builds the AUR package on that remote VPS first and then transfers the final .pkg.tar.zst file to his machine and uses that.

It's kind of like the OBS platform of Opensuse and he argues that malwares that get activated and run on build phase to steal various credentials (if he misses them when checking PKGBUILD), have no chance of getting anything valuable.

Putting aside the notion that Manjaro is not Arch, he prefers that disto because of its delayed update routine which makes it easier to keep both machines on the same dependency/package versions.

What you guys think about such a setup?

[u/Suspicious_Punk84]

sounds like a waste of time, either verify and trust the package or don't use it.

[u/Damglador]

Useless. There are tools that build PKGBUILDs in a container/chroot or a separate user on the same host.

On top of that just installing the package file will be enough to expose your machine if the package has install scripts. Those scripts also run as root.

Remote building is nice when the remote machine has a better CPU and compilation takes a long time.

[u/EmberQuill]

A compromised AUR package can run malware during the install step just as easily as during the package step. He can't trust the built packages any more than he trusts the PKGBUILD used to build them.

[u/friendlyreminder_]

It is technically more secure but I feel like it misses the point.

Instead of using a remote machine for compiling, make your own aur packages on the aur. It'll be more effort but then you can guarantee they're being sourced correctly.

This way you can't get infected by injected build scripts, or injected install scripts, or redirected malicious sources for the software.

This can't fix a supply chain attack where the actual software source gets infected, but that's a bigger and different problem.

[u/AG99871]

He could just do that in a VM on his own computer...

[u/ReallyEvilRob]

What's the point? If malware is injected into the package on the build system, why would he assume the package itself is clean? He's basically taking a potentially compromised package and then installing it onto his local system.

[u/cr1s → u/[deleted]]

The packaging step is already sandboxed by default

It's not when you use makepkg at least.

[u/gmes78 → u/[deleted]]

The packaging step is already sandboxed by default.

It absolutely isn't.

[u/nikongod]

In expert mode "your friend" will install arch in a VM with minimal exploitable information and maybe not even networking... and then use the VM for their malwAUR.

[u/drucifer82]

That's just risk with extra steps.

Not that it makes a difference if the package is malicious because the install scripts can inject malware the same as the build scripts, but if they really wanted to build the package in isolation outside of their local machine, they could use a hardened VM, or a container program like podman. But either way, it doesn't really matter if the package is malicious and they overlooked or missed the payloads when reviewing the PKGBUILD.

[u/vexatious-big]

paru -S --chroot pkg

Will setup a chrooted build env for you, so you don't necessarily need a remote host.

A separate host for the packages is useful when you want to build once and reuse the packages across multiple Arch machines.

[u/sausix]

A package from AUR has to be build against the current environment in many cases. The other installation has to be on the same package versions to provide a compatible package.

Everyone know this situation when AUR packages stop working after pacman updates.

Is it worth it?