top 46 comments

sorted by: hot top controversial new old
[–] 20 points 4 months ago

At least some level of human review is going to be needed.

So... completely negating the point of a User Repository??? Introduce some kind of authoritative oversight, and it's essentially just another regular repository, erasing all the benefits of the AUR. The whole point of the distro slapping a huge disclaimer of "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk." at the top of the homepage is because these kind of compromises are the trade-off one makes

  • source
  • [–] 35 points 4 months ago (1 child)

    What an annoyingly uninformative title. Better title: a lot more compromised AUR packages have been found since our last update.

    "A lot worse" is intentionally vague to get people to click.

  • source
  • hideshow 1 child comment
  • [–] 41 points 4 months ago (5 children)

    The command pacman -Qm will display every package from the AUR on your system. You can then search the list of compromised packages.

  • source
  • hideshow 5 child comments
  • [–] 4 points 4 months ago* (last edited 4 months ago)

    To be clear, -Qm displays installed packages not currently in the repositories. This will include AUR packages, but I avoid the AUR (except for davmail years ago) every once in a while I'll run it just to check and sometimes it finds packages.

    When you install things from the main repos the dependencies get installed too, and if those dependencies are no longer needed they'll be removed from the repositories. (I also have a bad habit of forgetting --asdeps when installing optional dependencies.) Sometimes they'll conflict with a new dependency and pacman will ask to remove and replace them, but other times the functionality has become a part of an existing package, so with no conflict to prompt removal they'll just sit unused on your install. If you haven't tried -Qm in a long while you'll probably find a few harmless currently-unused packages that were installed through the normal repos. (-Qdt will cover the other cases where dependencies remain in the repos but are now only needed for packages you don't have installed.)

    Obviously -Qm will also show removed packages that aren't dependencies, a few years back my preferred pdf viewer was removed from the repositories.

    -Qm will also find manually installed packages that aren't in the AUR if you ever do that.

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

    Here are some scripts that can help too

    (Edit: apparently i need to say to read and understand what these scripts are doing before running them. If you don't understand what you're running then don't run them) https://gist.github.com/Kidev/85756c3dcad3623ca5604a8135bafd14

  • source
  • parent
  • hideshow 1 child comment
  • [–] 86 points 4 months ago* (last edited 4 months ago) (5 children)

    TLDR: Open package repositories without some approval and oversight system, like AUR, will have even more problems in the future due to advanced coding AI and malicious foreign hackers.

    Edit: Please normalize TLDR's on bot posts with just a link.

    Edit 2: I have been rightfully informed that this is not a bot post. I still think links should not be posted without a tiny abstract, one might say: a TLDR.

    I have also been informed that the text does not spell out "foreign". This is correct. The text does say

    Not all of the packaging issues are as bad as the initial wave of trying to steal credentials, some are just adding ridiculous messages in Russian.

    This implies but does not establish the nationality of attackers. While Arch has contributors from all over the world, it is commonly cited as being a Canadian distribution (example, see below). https://distrowatch.com/table-mobile.php?distribution=arch

  • source
  • hideshow 5 child comments
  • [–] 22 points 4 months ago* (1 child)

    I remember the good ole days when nobody cared enough about Linux to spread malware to it. Sigh. All these techbros that need to j their d to their power trips, dystopian surveillance, and shitty AI companies have probably started this. I even noticed a Linux hate sub on Lemmy. Imagine there being enough people forced to use Linux to create a hate community where they favor Microslop. Such strange times we live in.

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

    AUR is still working as intended. It’s basically a public wiki of shell scripts, it was never intended to be secure in the first place. It has always been the user’s responsibility to review everything or avoid using it.

  • source
  • parent
  • [–] 11 points 4 months ago* (last edited 4 months ago) (2 children)

    I think I'd be satisfied with just not allowing people to take over orphaned packages. That seems like a glaring attack vector and closing it would not harm the AUR in any way.

    And yea, arch (and its derivatives) probably should not ship with AUR helpers pre-installed.

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

    Now's our chance, it's time for a hostile takeover from my fellow "i use nix btw"s!

  • source
  • hideshow 1 child comment
  • [–] 12 points 4 months ago* (last edited 4 months ago) (3 children)

    AUR has never been a good idea. I don't use it and this news proved me right.

    Does that mean a distro official package manager would be immune to infections? Of course not, but they do offer a more secure distribution system and build greater trust. Minimizing the chance of malware being spread through their means.

    Edit: If you have the knowledge and time to inspect the AUR packages you install, AUR might be good for you. I have none of these, that's why I stick to my official distro packages (and sometimes also some flatpak but from official sources)

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

    It's just a repository of user-contributed packages. It's no different malware-ability-wise to, say, GitHub. If you are running code you found from a stranger on the internet then you are liable for it, and you need to do your due diligence in checking that you are not running malware. It is a good thing that the AUR exists because it means Arch user packages are all in one centralised repository instead of scattered across GitHub, Sourceforge, Codeberg, Pastebin, forums, whatever. If you are just installing random AUR packages then that's on you. It's basic internet safety to not automatically trust random scripts you find on the internet.

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

    I never said that GitHub was better. I just don't feel like using a package maintained by a stranger with no tied to neither the software I want to install nor the distribution packages repository.

    Of course installing random code from stranger is never great advice regardless of the distribution source. But AUR is simply not for me, and many users don't understand the risk or let's say responsabilities it involves while installing packages from that source.

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

    I agree about the risks in terms of the way some sources present the AUR as just extra packages. But I don't think you can object to the AUR more than any other place on the internet where anyone can upload software; unfortunately, the onus is going to be on the user to verify what they install. The AUR is moderated by volunteers and it wouldn't be fair to expect them to vet all of the high volume of commits to the AUR. Possibly they could vet new maintainers or new packages or newly adopted packages, but nothing would stop someone from initially uploading a genuine package and then replacing it with something malicious. Or they could require identity verification to be an AUR maintainer but then far fewer genuine packages would be on there because people don't want to give their real identity to contribute (I maintain some AUR packages, and would stop if required to verify my IRL identity).

    I can totally understand if the AUR is not for you; it's more time-consuming as you have to read PKGBUILDs (I always do). But that doesn't make it bad that it exists at all. I think there should be more warnings about it for new users, and possibly some more moderation, though like I said above there's no perfect moderation solution that would simultaneously forgo users' responsibility to check and keep the AUR as large as it is today. Ultimately the option should still exist for users who want it. If it didn't exist, I'd have to hand-package every program that's not in the official repos, and that's even more time-consuming than pulling and reading through a PKGBUILD that someone else already wrote and shared.

  • source
  • parent
  • [–] 14 points 4 months ago (17 children)

    Me, a Debian user, watching that shitshow 😎

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

    Debian users should receive their news 6-12 months after everyone else, change my mind

    /s

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

    Some people likes tested and stable software. It's weird.

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

    Huh, you really feel schadenfreude over another reputable project being hit by/having to deal with malware? And all the people who might be affected by it?

    That is not something that would ever cross my mind.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 4 months ago*

    Whoa, this is blowing up. Chill, guys. I really think that sucks. If anything, with Arch being bleeding edge and all of that, at least you're showing early the tough wake up the other distros will have to do in relation to malware after Linux' increasing popularity. Time to brush those SELinux and apparmor bits, even.

    But, now, we Debian users are okay, (btw, 😎).

  • source
  • parent
  • [+] 3 points 4 months ago (4 children)
  • [–] 1 point 4 months ago (1 child)

    More like: Upside to Debian, you never have to worry about the latest malware and bugs! Downside to Debian, you have to use yesterday's everything…

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

    I use Debian for everything, and the only thing I've updated to the current (non Debian distribution) version is Docker, which I use for a game. But this isn't a problem, because it's Debian, so the Docker people make packages for several recent Debian releases.

    I don't miss the bleeding edge. That issue a while back where someone infiltrated a basic library didn't affect me. The software I use might have bugs (what software doesn't?), but by the time I get it, it has been well tested for security issues.

    I'm pretty happy with my switch to Debian. I'll admit I'm curious about Bazzite for my gaming computer, but even then, it's like, "Why? Debian is doing just fine."

    But I'm not laughing at anyone. This is a scary new variety of attacks we're seeing, and there's no real reason one couldn't end up in my computer. Reminds me of the old one where someone slipped a backdoor into a compiler.

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

    Is the Chaotic-AUR a viable alternative? As I understand, there is some level of review.

  • source
  • [–] 4 points 4 months ago (1 child)

    But why? Arch isn't a server distro and their users usually know how to keep their secrets save. A FUD campaign?

  • source
  • hideshow 1 child comment
  • load more comments (1 reply)
    [–] 1 point 4 months ago (1 child)

    Where at "I use Arch btw" now?

  • source
  • hideshow 1 child comment
  • [–] 12 points 4 months ago

    I use arch btw, it's only effecting the arch user repository, which lives separately from the maintained repositories, it's not even possible to download stuff from there with pacman. Really it's just a community space, I also have packages there. You can download pre-packaged apps, so if you install them, you will be able to remove them with pacman. I think it's a great concept.

    it's like a forum where some jerk writes "use 'sudo rm -rf /' to speed up the computer". Except you don't have to read it to execute their plan.

    Flathub is also concerning btw. But at least those apps are containers (with too much permissions)

  • source
  • parent
  • 29 comments in c/linux@programming.dev view that post
    [–] 74 points 4 months ago* (4 children)

    I know everyone say “use at your own risk,” but in practice that’s not how regular users are using npm, PyPi, AUR, Cargo and such. They’re not manually reviewing every little update to a deluge of dependencies.

    …I’m guilty of this.

    I don’t know a perfect solution, but it feels like this can’t go on, as package hijacking is en vogue now.

    Containerization to contain damage is good, I guess, but still.

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

    Some of this can be alleviated by not using the latest version of everything. Granted that's not always possible, say if updating to fix a vulnerability or bug fix. Stable distros will have some insulation from this at least since there will be more time to discover the issue.

  • source
  • parent
  • [–] 5 points 4 months ago* (last edited 4 months ago) (2 children)

    That's a failed analogy. The AUR is an end-user build-script repo, not a source/binary/source+binary repo for both devs and sometimes users.

    If you e.g. install a CLI tool via cargo, there is at least an implicit tree of trust, with each dependant in a dependency tree doing at least some minimal vetting of dependencies. And the source is all there anyway (barring exceptions like build.rs pulling code, or the indirection of proc macros).

    The same applies to npm and pypi, although there is no distinction between "code" and "binary", given the scripting nature of the languages. But some pypi packages do actually distribute binaries (e.g. C/C++ compiled libraries). Don't know about npm.

    But, if I'm not mistaken, the py/js tooling wasn't always there for stuff like full pinning of dep versions like cargo, and that's a very important technical detail.

    With the AUR, there is no trust tree. And often no fixed code (or binaries) to look at (e.g. *-git packages). So the feasibility of doing any sort of global in-tree checking/vetting is not there. On the other hand, source repos are responsible for removing, or at least flagging, malware or otherwise harmful packages once that becomes known.

    Incidentally, I commented on both AUR security and cargo trust here and here. So, I will stop blabbing.

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

    there is at least an implicit tree of trust, with each dependant in a dependency tree doing at least some minimal vetting of dependencies.

    Depends.

    Unless every single dependency is version locked, one update or maintainer change can silently compromise the whole chain. Obviously this is a problem for AUR (as Arch is a single rolling release), but it can hit Rust and PyPi in a similar way.

    And a strict “version locking” ethos can lead to security problems down the line, too.

    Also, in this case, they exploited PKGBuild an npm, yes. But I think that was just out of convenience. It’s easy to sneak some malware downloader into a long Rust dependency chain, even if it’s technically all open code.

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

    Unless every single dependency is version locked

    Which is the case with Cargo.lock. You can even lock the toolchain itself with rust-toolchain.toml. There a reason why uv developers knew what good practices to implement in their quest to fix python tooling 😉.

    one update or maintainer change can silently compromise the whole chain.

    That's another failed analogy. There is no orphaning and total randos taking over in crates.io (same for npm/pypi I would assume). The owner himself must hand over or give permissions to a specific person/account. That's another implicit chain of trust that doesn't exist in AUR.

    Nothing is fail-proof of course, as the xz incident showed.

    I don't follow npm incidents closely, but the cases I saw involved the legit owners/maintainers themselves, who were either compromised, or genuinely doing the compromising themselves 🤣.

    Arch is a single rolling release

    This is largely irrelevant to the discussion.

    hit Rust and PyPi in a similar way.

    It won't be similar for the all the reasons stated.

    And a strict “version locking” ethos can lead to security problems down the line, too.

    That's where language implementation compat guarantees, audit tooling (cargo audit et al) and good tooling in general, together with a good semver story in the ecosystem itself, ALL come together to make this largely not a problem.

    This works well enough in the crates.io ecosystem.

    From what I hear, npm has the audit tooling part covered. But it's failure in all the other aspects that's making the situation unattainable.

    As with pypi, there is the pain point of python minor release updates breaking shit all the time. But beyond that, I don't know enough to give an informed take (other than that uv is a blessing for those who don't want to get their hands really dirty in that ecosystem).

    And again, these details and differences are very relevant.

    It’s easy to sneak some malware downloader into a long Rust dependency chain, even if it’s technically all open code.

    As of now, the number of successful supply chain attacks (where a chain of real dependants exists) in the crates.io system is ZERO.

  • source
  • parent
  • [–] 28 points 4 months ago (9 children)

    The article mentions the potential need for human review. I have no idea how that could be feasible for something as massive as the AUR. Maybe it could work like Nix, where every package goes through a PR/MR process, and then after it gets approved, the submitter is added to the list of contributors. It's definitely not a perfect process, but it's better than the zero-review process that the AUR has.

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

    I've noticed some installers have at least a voting system (e.g. Octopi) which helps... slightly. At least in knowing what the right package name probably is. Crowd source reviewing is probably the only option for such a vast and open system, even if it can be gamed sometimes.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 8 points 4 months ago (1 child)

    imo, there should be automatic tags like "active", "abandoned", "maintainer changed recently", "updated after hiatus" and a few more.

    The arch devs and community can decide on the time frames. It's not going to be perfect, but it may help warn users of the changes and so they can do a double take.

    Anything other than the "active" ones should show what changed (paru already does this) and users should make a conscious choice to install it anyway. (y/N) instead of going through the installation spamming the return key.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 4 months ago* (3 children)

    It is my speculation based on experience and direct invitations to review stuff that Google effectively does ranked crowd-sourcing for Google Maps, etc., in which Google secretly tracks and gives heftier vote power to veteran accounts with longer histories of competence and reliability (especially, say, accounts that are a decade old and still regularly contributing and proposing corrections), unbeknownst to said account holders themselves. Perhaps their lead could be the way out of such messes.

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

    This is kind of funny, because in the "reviews" part of Google Maps, a "Local Guide" giving a restaurant ⭐⭐⭐⭐⭐ is usually a strong indicator that you shouldn't eat from there 😉. That has been my experience, at least.

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

    Huh, well, I can tell you that Google classifies me as a local guide just because I try to regularly review places I go to, and I'm always honest with my reviews... I've left some scathing ones (not without reason, I hope) here and there as well 🤷🏻‍♂

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

    just because I try to regularly review places I go to

    That's what appears to be the problem. Quantity over some definition of quality makes it easy, and even creates the incentive, for some hustlers to go around soliciting money for positive reviews.

    Pay and your shit is marvelous, the best in town. Don't pay and you get 3/5 at best (I would presume smart hustlers don't go for 1/5 often to avoid getting too deep into blackmail territory).

  • source
  • parent
  • [–] 73 points 4 months ago (1 child)
  • [–] 15 points 4 months ago

    I have 1825 packages installed, 15 of which are from the AUR, and I use for very specific stuff, like VR. I personally know the mantainer of two of them. The AUR is cool, but should always be used with the same care as manual downloads.

  • source
  • parent
  • [–] 19 points 4 months ago

    As I understand it, the attack vector went after orphaned packages primarily. Several of the affected packages would only run the malicious code if it was a fresh install not an update only. So it would have had to be a clean install of an affected package or a newly installed dependency called to invoke this during the approximately 2 day window.

    Yes, this is bad, but it’s clearly testing for weaknesses in the chain through AUR.

    Yes, I know it’s contributed code by the community and a random actor can cause havoc. Yes, I know how to manually build packages and check for changes. Yes, I am guilty of using helpers. No, I wouldn’t catch everything on my own.

    I do limit what I do use from the AUR, because those installs and updates require more scrutiny.

    I am reassessing my own threat model as there’s a couple of packages where I’m dependent on the AUR - most notably displaylink drivers.

    I do wish communication was better around the event. I found out first through being subscribed to the mailing list. An announcement on the main page would have gone a long way.

  • source
  • [–] 17 points 4 months ago (1 child)

    Maybe this is a good time to try and get the top 10% of aur into official repos or 3rd party repos

  • source
  • hideshow 1 child comment
  • [–] 27 points 4 months ago (1 child)

    I'd love to know what's going on with this. Arch has its haters but someone's putting a lot of effort into this

  • source
  • hideshow 1 child comment
  • [–] 16 points 4 months ago

    It seems like some person with a bot just asked to maintain a bunch of orphaned packages, abusing the 2-week waiting period. Right?

    Thats why they used npm; off the shelf, almost “standard practice” credential harvesting malware. Nothing too fancy.

  • source
  • parent
  • [–] 8 points 4 months ago* (last edited 4 months ago) (2 children)

    People wanting to use AUR helper, you're better off using aurutils on aurto than yay or paru. Aurto, even with auto update already remove packages when the maintainer changes because aurto trust models was always to check the maintainer first and not the package itself

    https://github.com/alexheretic/aurto

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

    Edit: Sorry I realize my rambling didn't answer your question. My suggestion is to not use aura. I do not see anywhere on their repo about their trust model or if they just do it like yay/paru. This is also why I recommend aurto and not aurutils. People would just skip the diff with aurutils.

    The thing is, aurto is not the helper. The helper is aurutils. aurto is just the local repo manager that adds timer to auto-update and some QoL features. But to add packages to that local repo, you need to add the maintainer to the trust list. That means the current attack of adopting orphaned / unmaintaned packages is moot. The maintainer change means the package are kicked out and not tracked anymore by aurto. You can still re-add them after you've confirmed that they're safe.

    That being said, aurto do have issue. They trust the PKGBUILD of the author/maintainer so if the maintainer got hacked or gone rogue, it will not protect you. Same as with every other package manager in that case.

  • source
  • parent
  • [+] 8 points 4 months ago* (1 child)
  • [–] 1 point 4 months ago

    Do you have any tips on how to set up a python environment using nix?

    I also use NixOS (btw) but have so far sidestepped this by the expedient of giving up on any project not in nixpkgs whose install process is a pypi script.

  • source
  • parent
  • [–] 3 points 4 months ago

    I think the AUR isn't possible to keep using as-is so hopefully they come up with some sort of vetting process. Invite system like a private torrent tracker? Idk really.

    I try not to use AUR. A few exceptions being the actual program developer maintaining the AUR repo and recommending that method for Arch users on their github page or whatever.

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

    ok, time to completely stop using AUR.

    I'll only manually git clone packages

  • source
  • hideshow 1 child comment