191
Arch Linux AUR Under Another Wave Of Malicious Packages, Package Adoptions Halted (www.phoronix.com)
submitted 2 months ago by to c/linux@lemmy.ml
67 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 42 points 2 months ago (13 children)

Adoption of unmaintained packages to maintain them is not a mistake. The problem is the current implementation, not the idea behind it. It's like saying the AUR is a mistake, because some people do malicious stuff.

They should find a better solution, like adoption shouldn't be granted to everyone without question, especially new accounts who didn't maintain anything before. Mass adoption shouldn't be granted automatically (limit rate), in example 1 package adoption per day and if someone wants more, admins or moderators need to approve. And updates of newly adopted packages should wait a day.

Also the AUR helpers should do a better job. Always ask if a new adopted package should be updated and give a warning the maintainer changed.

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

    The problem is the current implementation

    Yes, exactly this! I am not surprised it happens. I’m surprised it didn’t happen before.

    especially new accounts

    Weren’t there “sleeper accounts” registered years ago that became active in the current wave?

    Also the AUR helpers should do a better job.

    Even experienced people will just update as if nothing could happen. Adopted packages should have to use a different name and the current name being blocked so it WILL get attention when some tries to update their system.

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

    Weren’t there “sleeper accounts” registered years ago that became active in the current wave?

    Which does not invalidate my point about new accounts, but yes. Its important for new accounts, so once a sleeper account is banned, its not that easy to just create thousands of new accounts while everyone is focusing on the current active ones. And if, as I suggested, mass adoption per account is not possible, then the attacker has less to attack.

    Edit: They need to make sure that sudden editing many packages in short time, with probably the same or similar lines should be automatically reported. They need some automated checks in place, at the very least. This would be a very suspicious behavior if many accounts are not active, and then suddenly all of them do something.

    Even experienced people will just update as if nothing could happen.

    Then you can't fault the system, if you are this reckless.

    Adopted packages should have to use a different name and the current name being blocked so it WILL get attention when some tries to update their system.

    This would break all dependencies of this package. The point of adoption is to keep it working and stable. I'm highly against force changing the name, that is not a solution (at least not one I am happy about).

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

    [Changing a package’s name] would break all dependencies of this package.

    Yes, that is correct. But that should not be a big deal for packages that are actively maintained. The maintainer can simply change the dependency to the new name after making sure the new package is legit.

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

    OK, that's a good point. It would prevent auto updating. However any package that is NOT updated, should stay with same name in my opinion. So that everything (with the old secure code) stays intact and working. The name change should be part of the the update process. So it only breaks if you want to update, which would ensure compatibility if you choose not to (as it is safe). Something along the likes like this. I agree with your suggestion now, because that seems to be sensible idea.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 2 months ago (7 children)

    They should find a better solution

    Who's "they"? Because it's not Arch. Arch doesn't want to have anything to do with AUR, and neither does any of the Arch-derived distros. They're all perfectly happy taking advantage of it, of course, but not the responsibility.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 10 points 2 months ago* (6 children)

    Who’s “they”? Because it’s not Arch. Arch doesn’t want to have anything to do with AUR, and neither does any of the Arch-derived distros. They’re all perfectly happy taking advantage of it, of course, but not the responsibility.

    Where did you got this nonsense from? What do you mean "they are not Arch"? The AUR is managed and operated by the Archlinux team. As the packages are community-driven content, they cannot guarantee and give support, because it is not their package. But they are still managing and supporting the AUR itself.

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

    it's not managing, as you seem to imply, it's just hosting.

    Arch hosts the AUR repository, the maintenance of the packages is on the developers who developed the package.

    If someone sneaks in spyware or malware inside the makepkg, that isn't arch's fault, that's the maintainers fault of the makepkg.

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

    If someone sneaks in spyware or malware inside the makepkg, that isn’t arch’s fault, that’s the maintainers fault of the makepkg.

    I don't think that anyone argued otherwise.

    I even said it in the very reply you are replying:

    The AUR is managed and operated by the Archlinux team. As the packages are community-driven content, they cannot guarantee and give support, because it is not their package.

  • permalink
  • fedilink
  • source
  • parent
  • [+] -9 points 2 months ago (3 children)

    And you're gonna see the Arch team wash their hands of the whole thing, like they did in the past whenever the AUR was in trouble.

    That's not real ownership.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 8 points 2 months ago (2 children)

    Do you have any sources, links or evidence for your statements?

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

    Is the current state of the AUR, despite the previous waves of attacks, and its troubled history, not evidence enough? The Arch team has never made the AUR a priority and I don't see why they would start now.

    The way I see it there are three possibilities:

    • They do nothing.
    • They shut it down.
    • They give it up for adoption.

    What is not going to happen is the Arch team putting time and effort into overhauling the AUR.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •