7 ms·

Now install every AUR package. Bonus points for heuristically looking for cryptominers after it's done.

by no_time 5y ago

RealStickman_ 5y ago
What would be the order of preference for conflicting packages (compiling, binary, git)?
- no_time 5y ago
  I'd start with binary packages in the order of ascending popularity https://aur.archlinux.org/packages/?O=0&SeB=nd&K=bin&SB=p&SO=a&PP=50&do_Search=Go https://aur.archlinux.org/packages/?O=0&SeB=nd&K=bin&SB=p&SO...
  - grapescheesee 5y ago
    Agree.
brightball 5y ago
Is this a real problem?
- Qub3d 5y ago
  While there have been malicious packages found in the AUR before[0], I haven't heard of a cryptominer sneaking in... yet. One was found in the Ubuntu Snap store at one point though[1] [0]:https://www.bleepingcomputer.com/news/security/malware-found-in-arch-linux-aur-package-repository/ https://www.bleepingcomputer.com/news/security/malware-found... [1]:https://www.bleepingcomputer.com/news/linux/malicious-package-found-on-the-ubuntu-snap-store/ https://www.bleepingcomputer.com/news/linux/malicious-packag...
- seanw444 5y ago
  It's only a matter of time. Linux really only has a good malware track record due to lack of popularity.
  - brightball 5y ago
    It seems like the popularity on servers would increase the likelihood.
    - seanw444 5y ago
      Yeah I'd think so too. I should clarify: lack of popularity as a desktop OS means less desktop/amateur viruses. I'd assume most server attacks are more targeted and curated. It's basically unnecessary to run any sort of anti-malware program on Linux, because not enough people use it for writing viruses for it to be profitable. And because the people who use it as a desktop are generally more knowledgeable and safe with their habits.
  - xyproto 5y ago
    All official Arch Linux packages are curated, and the unofficial ones are ~40 lines of shell script, with a voting system on top. These mechanisms for filtering packages are normally not present on systems that are plagued with malware.
    - akerl_ 5y ago
      The unofficial ones are ~40 lines of shell script that generally start by pulling down a VCS repo or tarball from somewhere. They check the checksum of tarballs, but if you’re pulling from the AUR you’re trusting not just the ~40 lines but also the much larger body of code that’s getting fetched.
      - sudosysgen 5y ago
        No package maintainer is verifying the code of every update of the software they're packaging. Those 40 lines of shell script are the only relevant difference between packages and the AUR, security wise.
        akerl_ 5y ago
        In the core repos, those 40 lines still exist. The AUR and core repos use the same PKGBUILD scripts. So the shell script isn’t a difference between core and AUR packages. As for the security review, I’d agree that no maintainer is verifying the code in every update of the software they’re packaging. This doesn’t mean that, as implied in the comment I replied to, you only have to review the 40 lines. It means that you’re accepting risk or accepting workload in either case (or both!), depending on how deep you look into the supply chain.
grapescheesee 5y ago
Better yet! Test the different tools for installing AUR. By installing all of them with each! Also, how much time do you have? Going to bet, it won't take too long before something breaks. Most of the AUR admins do a great job, however dependence issues can happen and compound quickly. I know AUR package managers are bad juju. Still it sounds fun.
Abishek_Muthian 5y ago
I recently found that brltty/orca package on Arch conflicted with CH340 driver[1] and prevented nodemcu from being detected over USB(tty). I uninstalled those packages, But it might not be an option for visually impaired. Installing every Arch/AUR package could break some hardware compatibility which we've taken for granted(Story link is not opening as of writing, So not sure whether this case has been covered in it). [1] https://unix.stackexchange.com/questions/670636/unable-to-use-usb-dongle-based-on-usb-serial-converter-chip https://unix.stackexchange.com/questions/670636/unable-to-us...

Now install every AUR package. Bonus points for heuristically looking for cryptominers after it's done.

RealStickman_ 5y ago

What would be the order of preference for conflicting packages (compiling, binary, git)?

no_time 5y ago
I'd start with binary packages in the order of ascending popularity https://aur.archlinux.org/packages/?O=0&SeB=nd&K=bin&SB=p&SO=a&PP=50&do_Search=Go https://aur.archlinux.org/packages/?O=0&SeB=nd&K=bin&SB=p&SO...
- grapescheesee 5y ago
  Agree.

brightball 5y ago

Is this a real problem?

Qub3d 5y ago
While there have been malicious packages found in the AUR before[0], I haven't heard of a cryptominer sneaking in... yet. One was found in the Ubuntu Snap store at one point though[1] [0]:https://www.bleepingcomputer.com/news/security/malware-found-in-arch-linux-aur-package-repository/ https://www.bleepingcomputer.com/news/security/malware-found... [1]:https://www.bleepingcomputer.com/news/linux/malicious-package-found-on-the-ubuntu-snap-store/ https://www.bleepingcomputer.com/news/linux/malicious-packag...
seanw444 5y ago
It's only a matter of time. Linux really only has a good malware track record due to lack of popularity.
- brightball 5y ago
  It seems like the popularity on servers would increase the likelihood.
  - seanw444 5y ago
    Yeah I'd think so too. I should clarify: lack of popularity as a desktop OS means less desktop/amateur viruses. I'd assume most server attacks are more targeted and curated. It's basically unnecessary to run any sort of anti-malware program on Linux, because not enough people use it for writing viruses for it to be profitable. And because the people who use it as a desktop are generally more knowledgeable and safe with their habits.
- xyproto 5y ago
  All official Arch Linux packages are curated, and the unofficial ones are ~40 lines of shell script, with a voting system on top. These mechanisms for filtering packages are normally not present on systems that are plagued with malware.
  - akerl_ 5y ago
    The unofficial ones are ~40 lines of shell script that generally start by pulling down a VCS repo or tarball from somewhere. They check the checksum of tarballs, but if you’re pulling from the AUR you’re trusting not just the ~40 lines but also the much larger body of code that’s getting fetched.
    - sudosysgen 5y ago
      No package maintainer is verifying the code of every update of the software they're packaging. Those 40 lines of shell script are the only relevant difference between packages and the AUR, security wise.
      - akerl_ 5y ago
        In the core repos, those 40 lines still exist. The AUR and core repos use the same PKGBUILD scripts. So the shell script isn’t a difference between core and AUR packages. As for the security review, I’d agree that no maintainer is verifying the code in every update of the software they’re packaging. This doesn’t mean that, as implied in the comment I replied to, you only have to review the 40 lines. It means that you’re accepting risk or accepting workload in either case (or both!), depending on how deep you look into the supply chain.

grapescheesee 5y ago

Better yet! Test the different tools for installing AUR. By installing all of them with each! Also, how much time do you have? Going to bet, it won't take too long before something breaks. Most of the AUR admins do a great job, however dependence issues can happen and compound quickly. I know AUR package managers are bad juju. Still it sounds fun.

Abishek_Muthian 5y ago

I recently found that brltty/orca package on Arch conflicted with CH340 driver[1] and prevented nodemcu from being detected over USB(tty). I uninstalled those packages, But it might not be an option for visually impaired. Installing every Arch/AUR package could break some hardware compatibility which we've taken for granted(Story link is not opening as of writing, So not sure whether this case has been covered in it). [1] https://unix.stackexchange.com/questions/670636/unable-to-use-usb-dongle-based-on-usb-serial-converter-chip https://unix.stackexchange.com/questions/670636/unable-to-us...