Avoid this very common mistake

If you want a bunch of stuff that's not in core or extra and you don't want to intensely babysit the AUR, you could try Chaotic-AUR. It hosts prebuilt packages for a bunch of AUR packages which are actively maintained by the Chaotic team.

I consider it to be more secure than the AUR proper since they actually care for their packages and review nontrivial changes. For instance, the recent takeover attacks didn't hit Chaotic-AUR builds since the changed packages didn't make it past the review.

It's still an unofficial third-party repository and closer to the AUR than to extra but I consider it a major step up.

I mean how often do you install AUR packages? Usually takes like a minute or so to skim through PKGbuild and the pkg comments and look for obvious issues. And most updates are just a sha hash and version change, taking like 5s to check.

I wish I could give you a second upvote, that's hilarious 😂

Well earned upvote, sir/ma'am.

This video taught me a lot.

Check the list of dependencies. If you really want to vet the package, look through all of the dependencies listed and read their package descriptions on their source page (github, gitlab, codeberg, whathaveyou). Check also the URL, from which makepkg (or yay or whatever) is going to pull some of the data. Is the URL legit?

::: spoiler PKGBUILD of localsend

# Maintainer: NourEddineX  
# Contributor: Nixuge  
# Contributor: Noah Vogt <noah@noahvogt.com>  
# Contributor: SpieringsAE (aarch64 addition)  

# Note: 
# using the .deb instead of the .tar.gz as it already contains the icons as well as the .desktop file.  

pkgname=localsend-bin  
pkgver=1.18.0  
pkgrel=1  
pkgdesc='An open source cross-platform alternative to AirDrop'  

LOOK HERE  
url=https://github.com/localsend/LOCALSEND  
LOOK HERE  

arch=('x86_64' 'aarch64')  
license=(Apache-2.0)  

LOOK HERE  
depends=(fuse2 xdg-user-dirs libayatana-appindicator)  
LOOK HERE  

conflicts=('localsend')  
provides=('localsend')  
options=(!debug)  
source_x86_64=("${url}/releases/download/v${pkgver}/LocalSend-${pkgver}-linux-x86-64.deb")  
source_aarch64=("${url}/releases/download/v${pkgver}/LocalSend-${pkgver}-linux-arm-64.deb")  
sha256sums_x86_64=('dae68192ad43a59a68df06454eb5fa4e9a9f86a343fe430165efd8b18863d0f4')  
sha256sums_aarch64=('eb24e724fbdf830c8fb07dfc66b76b8a649923d083278305a63d5d539db4b606')  
_pkgdesktop="localsend_app.desktop"  


prepare() {  
	tar -xf data.tar.zst  
}  

build() {  
	sed -i -E \  
		"s|Exec=localsend_app|Exec=localsend|" \  
		"${srcdir}/usr/share/applications/${_pkgdesktop}"  

	# Adjust .desktop to have it point to the correct icon  
	sed -i -E 's/^Icon=.+/Icon=localsend/' "${srcdir}/usr/share/applications/${_pkgdesktop}"  
}  

package() {  
	# Desktop  
	install -Dm644 "${srcdir}/usr/share/applications/${_pkgdesktop}" "${pkgdir}/usr/share/applications/${pkgname%-*}.desktop" 
	

	# Icons  
	install -dm644 "${pkgdir}/usr/share/icons/"  
	cp -a "${srcdir}/usr/share/icons" "${pkgdir}/usr/share"  
	# Dirty - rename icons to localsend  
	for res in "128x128" "256x256"; do  
		mv "${pkgdir}/usr/share/icons/hicolor/${res}/apps/localsend_app.png" "${pkgdir}/usr/share/icons/hicolor/${res}/apps/localsend.png"  
	done  


	# Executable  
	install -dm755 "${pkgdir}/opt/${pkgname%-*}/"  
	cp -a "${srcdir}/opt/localsend_app/." "${pkgdir}/opt/${pkgname%-*}"  
	# Same as icons - rename to localsend  
	mv "${pkgdir}/opt/${pkgname%-*}/localsend_app" "${pkgdir}/opt/${pkgname%-*}/localsend"  

	# Symlink executable  
	install -dm755 "${pkgdir}/usr/bin"  
	ln -s \  
		"/opt/${pkgname%-*}/${pkgname%-*}" \  
		"${pkgdir}/usr/bin/${pkgname%-*}"  
}  

:::

as the other commenter said, but worth echoing:

• is it suddenly using npm to install/run something? (iirc this was the attack vector for most packages that were infected)
• suddenly added some weird extra wget/curl/whatever to packaging methods to fetch something weird?
• are the package's sources (eg. github urls) legit?

Generally you should be aware of who'se software you're installing -> check if it's downloading the stuff from right place, and nothing extra. The PKGBUILD changes in the aur website are pretty good indicator if something has changed and how.

edit: npm itself, or it's usage isn't bad - but it is quite suspicious if the AUR package isn't for some webapp or so.

Suddenly an npm command to some random package appearing in an update

I think that the whole concept of sharing user repos to install packages is sadly not really good anymore. Because now it suddenly exposes that there is usually neither a trust anchor to that repo, nor an established review and fix process for such things.

I‘d say, just use the community maintained official package sources for now.

I don't mean this in any mean way, but if you don't know what you should be looking for, you probably shouldn't install AUR packages. Just as I wouldn't recommend someone who has never climbed a mountain to try mt everest.

You need to be able to understand the build process before you install anything from the AUR. Everything else is the equivalent of installing random exe's you found on a forum on windows.

Luckily, there's a lot of different videos online regarding the AUR build process, and the archwiki has an excellent article aswell.

Get AI to read it, it'll be 90% good enough

My dumb ass

Yeah same. Aur has been significantly less virus prone than the windows norm (inb4 wut abut winget >;ppp) of "Googling some shit you want and clicking the first website to roll the dice on predatory ads or malware or maybe the thing you wanted"

...not to mention if you have btrfs you can just rollback a month or two and call it a day.

This is more important after the recent news of malware on AUR

Not updating AUR packages saved me from the last incedent 🙃I had 6 or sth packages installed who were in the list

I get why we need to do this but most people are not programmers either and probably don't understand wtf they're looking at.

While I understand some of what um looking at, when in just trying to get the updates over with its super annoying to review each aur pkgbuild.

Yeah, I just update all 20 flakes that I sourced from github and pray that none of them were hacked

just use nix instead

Maslow, is this your hammer?

/s (nix just hasn’t been targeted yet (as far as we know 💀💀))

Isn't the real security through obscurity just being such a fringe market no one bothers? 🤔

Sorry I missed something, how so?

Distrobox is not an isolated environment, it is quite the opposite. They say so themselves on their page:

Security implications

Isolation and sandboxing are not the main aims of the project, on the contrary it aims to tightly integrate the container with the host. The container will have complete access to your home, pen drive, and so on, so do not expect it to be highly sandboxed like a plain docker/podman container or a Flatpak.

I would argue that Docker isn't a good way to stop malware either, since it is highly vulnerable to sandbox escape leveraging the shared host-guest kernel, like the many of LPEs that have been found in the last few months (example using copy-fail).

Docker is not a secure sandbox, Podman is not a secure sandbox, Flatpak is not a secure sandbox. Use a VM, or better yet, don't use the AUR.

Btw, login uses /bin/sh (or respective), script headers also, all fixed paths; would anything break, if you do alias sh=echo in your session setup script?

I use arch just to be able to use AUR lol

pkgwatch maybe?

Yeah, when something isn't in the official repos, NixOS exists, Flatpak exists, and they're all vetted.

Wanting a super clean system where everything is managed by pacman is purely about taste, so if you want it, you clearly can be bothered to put in the 2 minutes of work.