4 ms·

AUR packages are user-produced content i.e. packages built on their own machines. They have to be installed via "pacman -U package_file" Arch developers can c

AUR packages are user-produced content i.e. packages built on their own machines. They have to be installed via "pacman -U package_file" Arch developers can code "pacman -U" such that it performs a VirusTotal scan before installation for each package. VirusTotal's API is free. - https://docs.virustotal.com/docs/api-scripts-and-client-libraries https://docs.virustotal.com/docs/api-scripts-and-client-libr... - https://docs.virustotal.com/docs/please-give-me-an-api-key https://docs.virustotal.com/docs/please-give-me-an-api-key - https://docs.virustotal.com/docs/consumption-quotas-handled https://docs.virustotal.com/docs/consumption-quotas-handled Since it is end users who are doing the upload and virus scan check, there won't be a consumption quota issue with VirusToal. Lastly, "pacman -U" should flag failed VirusTotal scans to Arch Security. Arch's pacman and Flathub's flatpak package managers should be the last line of defence when installing untrusted packages by end users.

akerl_ 1y ago
Is this accurate? My understanding is that the AUR does not host binary packages. It hosts pkgbuild files, which contain config and scripts that a user has to build on their own machine in order to install. The malicious code here is fetched as part of those scripts.
- johnisgood 1y ago
  No, it is NOT accurate. Pacman cannot be used to download, compile, or install AUR packages. You need the PKGBUILD file and use "makepkg -si" at the very least. If you want AUR packages, you'd install a package manager (in this context referred to as AUR helper) like "yay" that supports both official and unofficial (i.e. AUR) packages. FWIW AUR helpers are not even official packages, not even "yay" which is a popular one. You need to go out of your way to install "yay" (although it is one command away before, i.e. very easy). TL;DR: Pacman does not download, compile, or install packages from the AUR, nor does it resolve their dependencies. "makepkg -si" builds and installs a package based on the PKGBUILD file, or use an AUR helper that overcomes the limitations of "makepkg". AUR helpers make it easy to install AUR (i.e. unofficial) packages.
  - akerl_ 1y ago
    And even with 3rd party package managers like yay, the package manager is pulling the pkgbuild definition locally, running makepkg for you, and then installing that.
    - johnisgood 1y ago
      Yeah, it is called an "AUR helper" officially because it just automates these processes for you.
    - BearOso 1y ago
      And yay warns you before anything happens and prompts you to review the PKGBUILD files and any patches for this very reason. So there are at least two "are you sure?" confirmations needed before even building anything. This is a situation where you have to go out of your way and be naive to be affected. You simply can't protect the user from everything.
      - deleted 1y ago
        [deleted]
OsrsNeedsf2P 1y ago
Between false positives, high QPS, and the fact malware devs would then test against Virus Total, is this useful?
Tharre 1y ago
First of all, this is incorrect, the checking would have to happen _before_ even building the package since malware is already being executed at that point. But more importantly this is a terrible idea in regards to privacy/infosec. I do not want packages I build and install myself to be uploaded to a 3rd party website. And for what benefit? 99% of new malware won't be detected anyway, and once it is known it is way more effective to just remove the offending package from the AUR.
- jchoksi 1y ago
  > malware is already being executed at that point To ensure reproducible / clean builds, I thought makepkg would always be run in a sandbox/chroot environment. The damage done would be localised to that sandbox. > this is a terrible idea in regards to privacy/infosec. Ok. Devs could setup an option to pacman -U which allows it to bypass VT for privacy sensitive people. This just puts the onus on you to not ensure you aren't installing malware. The default Arch user should still be protected while allowing for your privacy needs. > 99% of new malware won't be detected anyway, and once it is known it is way more effective to just remove the offending package from the AUR Its too late then. People are already affected.
  - akerl_ 1y ago
    It seems like you may not be familiar with Arch? No, makepkg doesn’t run in a sandbox. The system tries to stop you from running it as root, but otherwise all validation of the trustworthiness of the pkgbuild and any sandboxing of the build process are left up to the user. This is part of why pacman, the 1st party package manager, does not fetch from the AUR. Likewise, it would be generally against the Arch ethos to have the default behavior of the package manager interact with a 3rd party service. If a user wants that action, they’d need to perform it themselves.
  - Tharre 1y ago
    > To ensure reproducible / clean builds, I thought makepkg would always be run in a sandbox/chroot environment. The damage done would be localised to that sandbox. makepkg runs in a fakeroot environment, but this is not a security barrier. There is also support for building inside systemd containers, offering at least limited security, but most AUR helpers don't use that yet. > Ok. Devs could setup an option to pacman -U which allows it to bypass VT for privacy sensitive people. This just puts the onus on you to not ensure you aren't installing malware. The default Arch user should still be protected while allowing for your privacy needs. You mistake the target group of Arch Linux. Users are expected to read the documentation and to know what they're doing. Protecting users from themselves at the expense of those who know what they're doing is not what Arch is about. > Its too late then. People are already affected. That doesn't make sense, it's too late for people if new malware isn't detected by VirusTotal as well.
icar 1y ago
Just create a pacman hook before install that uploads the package there and aborts installation if necessary. Probably skipping repo packages is a good idea otherwise you're gonna spam the API each update.
diggan 1y ago
> Arch developers can code "pacman -U" such that it performs a VirusTotal scan before installation for each package. AFAIK, VirusTotal only flags known malware/viruses, any new/"looks-to-be-new" stuff wouldn't be flagged until they've picked it up, and once someone would have picked it up, it should be removed from the AUR anyways. So you'd have at least one user (most likely more) getting infected first, and once detected more users wouldn't be able to install it regardless.
- jchoksi 1y ago
  > So you'd have at least one user (most likely more) getting infected first, and once detected more users wouldn't be able to install it regardless. This is where your and my intentions differ. I don't want the average Arch user to be infected when it can be prevented because the malware is known about.
  - diggan 1y ago
    > I don't want the average Arch user to be infected when it can be prevented because the malware is known about. Me neither, my argument would be that VirusTotal won't stop the initial users from getting infected, so not good enough in my mind.

akerl_ 1y ago

Is this accurate? My understanding is that the AUR does not host binary packages. It hosts pkgbuild files, which contain config and scripts that a user has to build on their own machine in order to install. The malicious code here is fetched as part of those scripts.

johnisgood 1y ago
No, it is NOT accurate. Pacman cannot be used to download, compile, or install AUR packages. You need the PKGBUILD file and use "makepkg -si" at the very least. If you want AUR packages, you'd install a package manager (in this context referred to as AUR helper) like "yay" that supports both official and unofficial (i.e. AUR) packages. FWIW AUR helpers are not even official packages, not even "yay" which is a popular one. You need to go out of your way to install "yay" (although it is one command away before, i.e. very easy). TL;DR: Pacman does not download, compile, or install packages from the AUR, nor does it resolve their dependencies. "makepkg -si" builds and installs a package based on the PKGBUILD file, or use an AUR helper that overcomes the limitations of "makepkg". AUR helpers make it easy to install AUR (i.e. unofficial) packages.
- akerl_ 1y ago
  And even with 3rd party package managers like yay, the package manager is pulling the pkgbuild definition locally, running makepkg for you, and then installing that.
  - johnisgood 1y ago
    Yeah, it is called an "AUR helper" officially because it just automates these processes for you.
  - BearOso 1y ago
    And yay warns you before anything happens and prompts you to review the PKGBUILD files and any patches for this very reason. So there are at least two "are you sure?" confirmations needed before even building anything. This is a situation where you have to go out of your way and be naive to be affected. You simply can't protect the user from everything.
    - deleted 1y ago
      [deleted]

OsrsNeedsf2P 1y ago

Between false positives, high QPS, and the fact malware devs would then test against Virus Total, is this useful?

Tharre 1y ago

First of all, this is incorrect, the checking would have to happen _before_ even building the package since malware is already being executed at that point. But more importantly this is a terrible idea in regards to privacy/infosec. I do not want packages I build and install myself to be uploaded to a 3rd party website. And for what benefit? 99% of new malware won't be detected anyway, and once it is known it is way more effective to just remove the offending package from the AUR.

jchoksi 1y ago
> malware is already being executed at that point To ensure reproducible / clean builds, I thought makepkg would always be run in a sandbox/chroot environment. The damage done would be localised to that sandbox. > this is a terrible idea in regards to privacy/infosec. Ok. Devs could setup an option to pacman -U which allows it to bypass VT for privacy sensitive people. This just puts the onus on you to not ensure you aren't installing malware. The default Arch user should still be protected while allowing for your privacy needs. > 99% of new malware won't be detected anyway, and once it is known it is way more effective to just remove the offending package from the AUR Its too late then. People are already affected.
- akerl_ 1y ago
  It seems like you may not be familiar with Arch? No, makepkg doesn’t run in a sandbox. The system tries to stop you from running it as root, but otherwise all validation of the trustworthiness of the pkgbuild and any sandboxing of the build process are left up to the user. This is part of why pacman, the 1st party package manager, does not fetch from the AUR. Likewise, it would be generally against the Arch ethos to have the default behavior of the package manager interact with a 3rd party service. If a user wants that action, they’d need to perform it themselves.
- Tharre 1y ago
  > To ensure reproducible / clean builds, I thought makepkg would always be run in a sandbox/chroot environment. The damage done would be localised to that sandbox. makepkg runs in a fakeroot environment, but this is not a security barrier. There is also support for building inside systemd containers, offering at least limited security, but most AUR helpers don't use that yet. > Ok. Devs could setup an option to pacman -U which allows it to bypass VT for privacy sensitive people. This just puts the onus on you to not ensure you aren't installing malware. The default Arch user should still be protected while allowing for your privacy needs. You mistake the target group of Arch Linux. Users are expected to read the documentation and to know what they're doing. Protecting users from themselves at the expense of those who know what they're doing is not what Arch is about. > Its too late then. People are already affected. That doesn't make sense, it's too late for people if new malware isn't detected by VirusTotal as well.

icar 1y ago

Just create a pacman hook before install that uploads the package there and aborts installation if necessary. Probably skipping repo packages is a good idea otherwise you're gonna spam the API each update.

diggan 1y ago

> Arch developers can code "pacman -U" such that it performs a VirusTotal scan before installation for each package. AFAIK, VirusTotal only flags known malware/viruses, any new/"looks-to-be-new" stuff wouldn't be flagged until they've picked it up, and once someone would have picked it up, it should be removed from the AUR anyways. So you'd have at least one user (most likely more) getting infected first, and once detected more users wouldn't be able to install it regardless.

jchoksi 1y ago
> So you'd have at least one user (most likely more) getting infected first, and once detected more users wouldn't be able to install it regardless. This is where your and my intentions differ. I don't want the average Arch user to be infected when it can be prevented because the malware is known about.
- diggan 1y ago
  > I don't want the average Arch user to be infected when it can be prevented because the malware is known about. Me neither, my argument would be that VirusTotal won't stop the initial users from getting infected, so not good enough in my mind.