• placebo@lemmy.zipEnglish
      10·
      4 days ago

      Tbf most major attacks we saw recently are cross-platform thanks to npm. AUR has always been a security risk.

    • Alaknár@sopuli.xyz
      4·
      4 days ago

      Wasn’t that long ago when I was downvoted to oblivion for saying that. Glad to see the community is maturing.

  • macniel@feddit.org
    1003·
    5 days ago

    Linux Users: haha those silly windows users, always searching the web for their software and getting viruses.
    Linux Users: oh no I got malware by searching the AUR!

    • rtxn@lemmy.worldM
      431·
      5 days ago

      The AUR is still safer. One, it is at least minimally moderated. If a malicious package is detected, it can be reported and removed. Two, the installer is usually not just a black box executable. Three, most of the build and runtime dependencies are from the official Arch repos, which provides some protection against supply chain attacks. For Windows installers, you have to trust the distributor to bundle clean DLLs (for that matter, the same applies to AppImages).

      But if it starts downloading anything from NPM… ^C and run.

      • Lucy :3@feddit.org
        23·
        5 days ago

        The most unsafe factor of the AUR is aur helpers and their goal to dumb everything down and streamline the process as if the AUR where an official repo

        • CubitOom@infosec.pubEnglish
          81·
          5 days ago

          I’m not entirely sure I agree, I think the issue is with default settings.

          Like you could use both yay and paru to diff the PKGBUILD of the most recent updat and then read it, and then approve each. And I think that’s pretty helpful. But you could also just blindly accept the update with the right config or flag and that is not a good practice.

          • bitfucker@programming.dev
            3·
            4 days ago

            Yeah, use and promote aurto instead. They require you to trust the maintainer and would remove the package from the local repo if the maintainer is changed

            • CubitOom@infosec.pubEnglish
              2·
              4 days ago

              I’m not sure if loosing the maintainer is to only thing we should be going off of here, but I like the name.

              • bitfucker@programming.dev
                1·
                4 days ago

                Well, it is just like a distro maintainer account anyway. If the maintainer account is compromised then gg for the whole distro. That’s what happens with other supply chain attacks as well and yes, I do think we need a way to fix that without compromising on ease of usability

                • CubitOom@infosec.pubEnglish
                  1·
                  4 days ago

                  We arnt talking about a distro maintainer, but an aur package maintainer, which can be anyone.

    • Lucy :3@feddit.org
      9·
      5 days ago

      By misusing the AUR and ignoring every warning telling you to read and understand the pkgbuild or don’t do it.

      • TerHu@lemmy.dbzer0.com
        16·
        5 days ago

        as much as i love nvim and understand people who love emacs, there are people who want that big gui thing. for those i’d recommend VSCodium if they feel like they really can’t live without VSCode or Gram for those who got to like Zed.

        • Thorry@feddit.org
          4·
          5 days ago

          I was anti GUI for years. Having learnt to program on a tiny green and black 40x24 CRT on my old MSX back in the 80s. I remember being made fun of by fellow students and co workers alike for doing almost everything in the terminal. This included huge projects with complex file trees and lots of files.

          But as time went on, I started to appreciate the GUI more and more. And these days I’m all for using a GUI for a lot of things.

          Especially in IDEs that can do a lot of things with short keyboard shortcuts. I now have multiple monitors, including a large 32" primary. I always have stacks upon stacks of windows open and manage them efficiently. There’s always at least a couple of terminals hanging out and of course most IDEs also have terminal windows baked in. But all of the extra visual tools help me out a lot.

          • voodooattack@lemmy.world
            2·
            5 days ago

            Almost the exact opposite for me. Used to hog GUIs and hated keyboard shortcuts with a passion, but then I came across Niri, fell in love with the idea, and the whole scrolling window manager thing made my productivity explode. I can’t use traditional desktop environments anymore. Tried to go back and literally can’t.

            Tmux wasn’t that far behind.

            • tal@lemmy.todayEnglish
              1·
              3 days ago

              and the whole scrolling window manager thing…tmux wasn’t that far behnd

              I remember one time reflecting on how many layers I have at which one can expand workspace.

              1. Linux virtual terminals. By default, Debian runs 7 login sessions on seven virtual terminals and sticks the GUI (Wayland/Xorg) on the eighth. So Control-Alt-F1 through Control-Alt-F7 will get me a Linux terminal. I can stick more programs on more virtual terminals with openvt. That’s the first layer.

              2. Okay, so on virtual terminal 8, I’ve got Wayland running. On that, I’m running Sway. That has an infinite number of workspaces that can be created. Currently, I only have bindings set up for 10 (and I use nonstandard bindings for them, Super-q N to switch to the Nth workspace) because I didn’t find myself actually using named workspaces. This is the second layer.

              3. Within a workspace, I can have Wayland windows. Say I can have two or three windows reasonably visible. This can be expanded whenever opening a window; for example, Super-t to open a new virtual terminal emulator window. This is the third layer.

              4. One of the most common windows I use is a virtual terminal emulator, foot. That can run a program. I typically have it running tmux, which can have its own list of concurrently-running terminal programs (I use Control-O as the tmux meta key). This is the fourth layer.

              5. I often use emacs. Emacs has multiple “frames”; one can “clone” the current frame with C-x 5 c. When run in a terminal, this basically acts like another tmux-like layer where one shows one frame at a time. This is the fifth layer.

              6. Inside an emacs frame, one can have multiple emacs windows (analogous to what is typically called “panes” in other software) showing various things at the same time. One can open a new window with C-x 2 or C-x 3, cycle with C-x o. This is the sixth layer.

              7. Emacs has a list of buffers, any one of which can be shown in a given emacs window. A “buffer” is vaguely analogous to “an open file” in some other programs, but could also be showing a terminal emulator or similar. One can switch with C-x b. This is the seventh layer.

              8. Say I’m running a terminal emulator in one running bash (M-x term RET RET). bash has its own job control; one can suspend a running program and bring bash to the fore with Control-Z, list running jobs with jobs, then resume a suspended job in the background with $ bg %1 to background the first or bring a job to the foreground with $ fg %1. This isn’t quite the same thing as the other layers, since the screen state isn’t maintained for separate programs and restored, but it can reasonably allow one to run simultaneous things and follow each. This is the eighth layer.

              • voodooattack@lemmy.world
                1·
                3 days ago

                Noping the heck outta that. All I want is better top-level organisation, you just described what I’d call an anti-pattern in my book.

                I wouldn’t nest things that deep through so many different tools/framework/layers that can’t talk to one another. That’s just asking for trouble. You’d waste one of two things: time searching or focus for memorising and recall, you lose something either way. And in the case of the latter you’re bound to forget and start wasting time to search over time anyway.

    • Siegfried@lemmy.world
      4·
      4 days ago

      Did clamav work with AUR affected packages? Sorry if the question is idiotic, cause im ignorant when it comes to security

    • Crozekiel@lemmy.zipEnglish
      2·
      3 days ago

      I am really curious about this. If someone had ClamAV and updated any of these packages from the AUR during the attack, would ClamAV have “solved” that problem? I would love to know the effectiveness of that.

    • helpImTrappedOnline@lemmy.world
      4·
      3 days ago

      Well that’s fun. Odd someone named Campbell asking was for a tomato soup recipe, you’d think that would just be built into their bloodline or something.

      While I’m glad no JS package managers were hurt to make the soup, I do wish the recipe didn’t waste so much water.

    • magnolia_mayhem@lemmy.world
      2·
      3 days ago

      Just keep sending requests and use as many tokens as possible. My wife spent 30 minutes on the phone with a bot the other day, just getting it to dump huge sets of instructions to waste tokens.

      • CubitOom@infosec.pubEnglish
        7·
        5 days ago

        Good question, I guess I might be using the wrong word when i say “orphan” because I see the arch wiki uses that term differently

        Orphans are packages that were installed as a dependency and are no longer required by any package.

        https://wiki.archlinux.org/title/Pacman/Tips_and_tricks

        You can remove these manually or if using an aur helper like yay there are flags/settings you can use to delete them after the desired package was installed.

        However what I was talking about aur packages that are unmaintained or do not have a maintainer anymore.

        I’m researching more at the moment.

        • Eager Eagle@lemmy.worldEnglish
          6·
          5 days ago

          shit, I had 150 orphaned packages

          pacman -Qdtq | pacman -Rns -

          I made an alias for this, but IMO this cleanup should be automatic. The user didn’t install it themselves after all.

    • littleomid@feddit.orgEnglish
      93·
      5 days ago

      Waiting for updating doesn’t make any difference. The packages could be infected at any point.

      • CubitOom@infosec.pubEnglish
        6·
        5 days ago

        The packages could be infected at any point.

        I guess the same could be said for literally any open source or freely distributed project.

        The difference is that this was a supply chain attack and, to my knowledge, required the package to be listed as orphaned unmaintained first so that the PKGBUILD could be modified to install malicious NPM packages.

        The community caught it quickly because it is possible to read both the PKGBUILD and the output of the update and, I think, it is fully resolved as of now.

        Basically, if one were to delete or replace orphaned packages then they wouldn’t have been infected.

        It is also possible to add a CVE scanner for AUR packages if reading the PKGBUILD is too much, I’m looking into how to do that now.

        All this is to say that you should check if you had an infected package but I personally don’t think using the aur is more risky than using a flatpak.

      • 87Six@lemmy.zip
        21·
        5 days ago

        Waiting for updating doesn’t make any difference.

        Are linux users allowed to juat lie like that? I thought if you do that you need to use Windows.

    • Albbi@piefed.caEnglish
      3·
      5 days ago

      They also wait until they get off the rollercoaster and back on solid ground before yelling yay!