19
Is it safe to use the AUR again? (leminal.space)
submitted 1 month ago by to c/archlinux@lemmy.ml
25 comments fedilink hide all child comments
 

I haven't heard a peep about the security status of AUR since the headlines about malware injections into thousands of packages. I've ensured that none of my installed software is affected by the attack (to the best of my ability), but I've held off on my regular yay -Syu since then. What has you all done to keep your machine updated but clean?

And is there any update from AUR maintainers that the situation is under control? Most of my installed AUR packages simply don't exist in the official Arch repos, so if not I'd have to look for other sources.

you are viewing a single comment's thread
view the rest of the comments
[–] 10 points 1 month ago (6 children)

The situation was under control within the day it was reported. The window where you could've been affected was only a few hours. It was not a case of them "uncovering" thousands of infected packages that were lying around for months. They were noticing an automated attack of hijacking and infecting orphaned packages as it was happening and rushing to keep up while warning the public.

That's not to say the AUR is "safe". Its as safe as its always been. Continue to read your PKGBUILD diff's as you always should have.

  • permalink
  • fedilink
  • source
  • hideshow 6 child comments
    •
  • [–] 3 points 1 month ago (5 children)

    What is it you look for in the diffs more specifically?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 4 points 1 month ago (2 children)

    The first thing to check is that the software is being downloaded from the correct place. Look for additional downloads and make sure they're legit. Look for obfuscated code. If you're not sure, ask.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 month ago

    You have to have some expectations and understandings of what the PKGBUILD for the package should be doing and look for something out of the ordinary. The upstream repo will usually have packaging instructions in its readme or wiki which should be reflected in the PKGBUILD.

    In the case of the last incident, the attacker was adding npm as a dependency so they could execute npm install atomic-lockfile, which was the actual attack. That was a huge red flag because most of the packages had nothing to do with JavaScript.

  • permalink
  • fedilink
  • source
  • parent