TranscriptImage of a man pointing a gun at his own foot.

Caption: Installing an AUR package without reading it's PKGBUILD.

top 68 comments

sorted by: hot top controversial new old
[–] 127 points 2 months ago (14 children)
  • [–] 27 points 2 months ago (7 children)

    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.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 13 points 2 months ago (5 children)

    Yes, but is it good, neutral, or evil?

  • source
  • parent
  • hideshow 5 child comments
  • [–] 16 points 2 months ago* (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 2 months ago

    Rarely, to be sure. I tried Arch for a bit, but I need a computer that I can actually use to get shit done, that isn't a constant project itself. Even Qubes doesn't require as much effort to keep operational.

  • source
  • parent
  • [–] 76 points 2 months ago (2 children)

    STABLE IS FOR HORSES I LOVE GAMBLING

    /s

  • source
  • hideshow 2 child comments
  • [–] 33 points 2 months ago (7 children)

    I usually do, but I don't really know what I should be looking for. What are some red flags?

  • source
  • hideshow 7 child comments
  • [–] 42 points 2 months ago* (last edited 2 months ago) (1 child)

    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?

    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%-*}"  
    }  
    

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 2 months ago* (last edited 2 months ago)

    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.

  • source
  • parent
  • [–] 25 points 2 months ago*

    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.

  • source
  • parent
  • [–] -4 points 2 months ago (2 children)

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

  • source
  • parent
  • hideshow 2 child comments
  • [–] 13 points 2 months ago (7 children)

    I'm running Arch daily since 2015, was on Debian before. I install and try a lot of stuff. Never had anything bad happened to me once. Worst case scenario the shit I just installed didn't work so I have to debug it.
    Not endorsing this apparently dangerous lifestyle, but also a little bit maybe

  • source
  • hideshow 7 child comments
  • [–] 2 points 2 months ago (3 children)

    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.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 2 months ago (2 children)

    You really don't need to be a programmer to check for obvious bullshitery, you just need to read like four pages explaining what part means what there.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 2 months ago (1 child)

    I disagree.

    Picture.. I dunno, a plumber. Hates computers but he knows to click the thing to update.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 2 months ago

    Now picture a different, more computer-curious plumber. He doesn't hate computers, so he reads two pages on a wiki and now can at least spot when the url has changed or when the diff added some new step that wasn't there before. You don't need computer science degree to see that there is a new command that weren't previously, and google that command.

  • source
  • parent
  • load more comments (1 reply)
    [–] 11 points 2 months ago*

    Nah, if you really want to live on the bleeding edge you gotta make blindly installing vibecoded junk from shady parts of the AUR part of your workflow

  • source
  • [–] 20 points 2 months ago (3 children)
  • [–] 10 points 2 months ago (4 children)

    just use nix instead

    we have super secure mechanisms in place to prevent supply chain attacks

    /s (nix just hasn't been targeted yet (as far as we know πŸ’€πŸ’€))

  • source
  • hideshow 4 child comments
  • [–] 9 points 2 months ago (2 children)

    All pointing with fingers to AUR, but the issue was (yet again) with NPM.

  • source
  • hideshow 2 child comments
  • [–] 8 points 2 months ago

    Someone put my WM on the AUR. I am thus proud to be authoring malware :)

  • source
  • [–] 8 points 2 months ago (6 children)

    If possible do it in a distrobox and down networking before running, yes that won't stop the curl | sh in the install, but at least you can blow it away without hurting your main install and it will likely infect only the distrobox. Bonus points for an immutable main OS.

    As the whole supply chain attack vector gets more sophisticated, and probably subtler in effect, these are going to be harder and harder to spot and likely start making it into main repos. Keep sharp people.

    Not real fun for a linuxmemes post, but I think it needs saying.

  • source
  • hideshow 6 child comments
  • [–] 6 points 2 months ago (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 2 months ago (1 child)

    Would Firejail fall for the same/similar sandbox vulnerabilities that Docker containers do?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 2 months ago*

    Things sandboxed by Firejail share the same host kernel. Therefore, kernel vulnerabilities could allow for privilege escalation.

    Firejail itself is a security-hole. It is a massive root SetUID binary which can and has been used for privilege escalation. I avoid it entirely. Unprivileged sandboxes are better, but lack the built-in profiles provided by Firejail.

    If I was trying to sandbox malware, I would use sydbox. It is memory safe (unlike Firejail or Bubblewrap), unprivileged (unlike Firejail), secure sandbox by default (unlike Bubblewrap), extensively uses all relevant Linux security features/modules (more than any other), and actually helps to stop LPE by re-implementing or denying dangerous syscalls like in the case of many of the recent vulnerabilities. Biggest caveat is that it's not for beginners, even though it abstracts a lot of the complexity. I'd also neverbrun malware in just a sandbox, but use that alongside a proper VM.

    TL;DR No sandbox will save you from good malware. Firejail might be enough for script kiddies, but could make your system more vulnerable to privilege escalation attacks. Avoid installing things you don't need.

  • source
  • parent
  • [–] 1 point 2 months ago* (last edited 2 months ago) (1 child)

    Distrobox is not an isolated environment

    True, you'll note I didn't say it is sandboxed or isolated, but it is a different environment. Paths that point to normal things like /usr etc. will be in the distrobox environment. That said, unless you use a custom home for the distrobox (you should anyway), your home directory is hosed. At this point I expect the malware to not be distrobox aware and use things like distrobox-host-exec, that may change.

    A VM is absolutely a better approach, if significantly more frictional.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 2 months ago* (last edited 2 months ago)

    You don't need to say the words "sandboxed" or "isolated" to say effectively the same thing. Your goal with distrobox was to keep the AUR malware separate from your normal system, no?

    Security through obscurity is not security. The malware can do the same data exfiltration regardless of root access because the AUR malware has been about stealing secrets in user-readable directories. Setting a custom home for distrobox does not disallow access to the normal one.

    Say for example that your default user home is /home/user and you set the distrobox home to /tmp/home

    If you run ls $HOME inside distrobox it will list files in /tmp/home, but just as easily you could run ls /home/$USER and it would list in your default home. Or alternatively just use the find command and steal secrets without targeting the user home.

    This is because changing the user home through distrobox doesn't do anything about preventing directory traversal to your default home.

    If your goal is to create a different environment and you don't care that it won't stop malware, use Incus or Podman directly. Distrobox is the wrong choice.

    My point was simple: when dealing with malware, distrobox is not an effective method of creating a "different environment" because that is antithetical to its stated goals.

    You can do whatever you want, I am not here to police your choice on your personal system. I only take issue with recommending this strategy to others.

  • source
  • parent
  • [–] 6 points 2 months ago

    If it's endorsed by the project team I might as well. At that point it's the same as downloading from GitHub and if I am in AUR I've probably not found it in standard repos nor flathub.

  • source
  • [–] 4 points 2 months ago

    I don't even read the nix files I install from lol

  • source
  • [–] 4 points 2 months ago (3 children)

    I use Arch without touching this AUR in my latest install. Just use what's in the main package repos or flathub

  • source
  • hideshow 3 child comments
  • [–] 6 points 2 months ago

    AUR Arch UrGettingMalware Repository

  • source
  • [–] 3 points 2 months ago* (last edited 2 months ago) (2 children)

    I once found a Rust program that streamlined the PKGBUILD reviewing process a lot by, first of all, giving you a really neat list of patterns and behaviours that would make a PKGBUILD suspicios or even plain dangerous, then having a scriptable rule-based engine that would either abort that operation, or show warns and workarounds to you.

    I forgot its name, unfortunately, and I installed it on my previous installation (Garuda, now I'm on CachyOS).

    Very dumb of my part not to try to write that down before the OS change lol.

  • source
  • hideshow 2 child comments
  • [–] 4 points 2 months ago (1 child)
  • [–] 3 points 2 months ago

    without reading [it is] pkgbuild

    I didn't know it was.

  • source
  • [–] 2 points 2 months ago

    I was contemplating moving to NixOS, but then another fiasco just happened, masse me question what would one have to lose by switching to Qubes instead, considering the increasingly surveiling internet.

  • source
  • [–] 2 points 2 months ago

    Update your desktop only all one or two weeks, get basic protection (adblocker, hosts file), read the news.

    It's a peaceful life.

  • source
  • [–] 1 point 2 months ago (1 child)

    I just don’t understand the process of I don’t have two minutes to read what I’m installing. It’s fucking batshit crazy that all these retards want to come use Linux which is fine but then when they get solid advice they tell us they can’t be bothered.

  • source
  • hideshow 1 child comment
  • [–] 3 points 2 months ago

    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.

  • source
  • parent
  • [–] -1 points 2 months ago

    Without reading its PKGBUILD fixed it for you. The AUR is toast, we have to say goodbye to it now.

  • source