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.
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?
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"; domv"${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%-*}"
}
Yeah. There’s also some others behaviours to look at. Like, does the PKGBUILD install the package on some non-standard location? That’s a suspicious behaviour, although it’s not an automatic red flag by itself.
Does it execute arbitrary code or any external script (worse if it’s Python, Lua or JS)? That’s a HUGE red flag in most of cases.
Does it (ab)uses of AWK, sed and the like? That’s also suspicious in a variety of cases.
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.
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.
That might work until they realize people are doing it and then just add the right circumventions. After all I can test my exploit and see if Claude or Gemini can find it, and polish it until they don’t.
I usually do, but I don’t really know what I should be looking for. What are some red flags?
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.
To be clear, I have like… three? extremely popular AURs installed - I’m definitely not in the habit of grabbing random stuff.
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(oryayor whatever) is going to pull some of the data. Is the URL legit?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%-*}" }Yeah. There’s also some others behaviours to look at. Like, does the PKGBUILD install the package on some non-standard location? That’s a suspicious behaviour, although it’s not an automatic red flag by itself. Does it execute arbitrary code or any external script (worse if it’s Python, Lua or JS)? That’s a HUGE red flag in most of cases. Does it (ab)uses of AWK, sed and the like? That’s also suspicious in a variety of cases.
as the other commenter said, but worth echoing:
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.
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.
Suddenly an npm command to some random package appearing in an update
Get AI to read it, it’ll be 90% good enough
That might work until they realize people are doing it and then just add the right circumventions. After all I can test my exploit and see if Claude or Gemini can find it, and polish it until they don’t.
Ask ai how to hide it from ai