Transcript

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

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

    • Azzu@leminal.space
      link
      fedilink
      arrow-up
      10
      ·
      2 months ago

      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.

      • Baŝto@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        2
        ·
        2 months ago

        I need a better wrapper that shows me diffs since last build. I’m too lazy for this

        Also pulling in release messages from git etc would be nice

      • HereIAm@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        2 months ago

        But wasn’t the latest AUR attack from a dependancy in the pkgbuild? Going out of your way to review all the dependencies as well is not really possible by just skimming through the script.

    • Jesus_666@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      2 months ago

      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.

    • printf("%s", name);@piefed.blahaj.zone
      link
      fedilink
      English
      arrow-up
      35
      ·
      edit-2
      2 months ago

      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%-*}"  
      }  
      
    • Malix@sopuli.xyz
      link
      fedilink
      arrow-up
      21
      ·
      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.

    • dwt@feddit.org
      link
      fedilink
      Deutsch
      arrow-up
      8
      ·
      2 months ago

      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.

      • massive_bereavement@fedia.io
        link
        fedilink
        arrow-up
        3
        ·
        2 months ago

        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.

  • Nalivai@lemmy.world
    link
    fedilink
    arrow-up
    8
    ·
    2 months ago

    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

    • Baŝto@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 months ago

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

    • yeehaw@lemmy.ca
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      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.

      • Nalivai@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        2 months ago

        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.

        • yeehaw@lemmy.ca
          link
          fedilink
          arrow-up
          1
          ·
          2 months ago

          I disagree.

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

          • Nalivai@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            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.

    • Funkt4st1c@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      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.

  • MalReynolds@slrpnk.net
    link
    fedilink
    English
    arrow-up
    6
    ·
    2 months ago

    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.

    • N.E.P.T.R@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 months ago

      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.

  • Digit@lemmy.today
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 months ago

    I realised…

    I wasn’t going to do that.

    And I was only using Artix for the AUR.

    So I stopped using Artix.

    Not responsible enough.

    Responsible enough to stop.

  • zitrone 🍋@europe.pub
    link
    fedilink
    arrow-up
    2
    ·
    2 months ago

    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 💀💀))