7 ms·

I like Arch's package management model, where sources are split into the official repositories, which are manually approved, and the AUR, which everyone knows a

I like Arch's package management model, where sources are split into the official repositories, which are manually approved, and the AUR, which everyone knows are not officially endorsed or reviewed, and to check the sources and PKGBUILDS for anything sketchy before installing. The processes for installing from the two are also different enough that the user can't mistake one for the other: official packages are a pacman -S away, but installing from the AUR either requires a git clone and a makepkg -sri, or an AUR helper that bugs you to review the PKGBUILD.

zootboy 8y ago
Also, compare the wording on the snap store: > Safe to run - Not only are snaps kept separate, their data is kept separate too. Snaps communicate with each other only in ways that you approve. Versus the AUR: > DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk.
- pasbesoin 8y ago
  And then, a Snap doesn't behave as the user expects (e.g. like a "native" application). And the first solution on stack-whatever, is to install it using the "--classic" switch. Whereupon, there goes your sandboxing.
- cookiecaper 8y ago
  The difference being that Snaps always run in a semi-encapsulated environment (a container), whereas the AUR just executes in whatever security context you're issuing commands from. PKGBUILDs are arbitrary shell scripts and they can do anything that the user executing them can do. I'm not trying to defend the perception that Snaps are immune from malware, but there is a real difference in the default safety of a package off the Snap Store and the AUR.
  - pritambaral 8y ago
    > Snaps always run in a semi-encapsulated environment (a container) Even with the `--classic` switch?
    - cookiecaper 8y ago
      I wasn't aware of the "classic" switch, looks like they added it early last year. They appear to call this "classic confinement mode", and it sounds like it functions essentially like a normal package manager, though they insist on saying it's a "relaxed security model" instead of "no additional security model at all", which appears to be the truth of the matter. Their site claims that only pre-vetted Snaps can be distributed with "classic confinement", so that's something at least. If that's true, it would allow the comparison between Snaps and the AUR to hold -- Snaps would either be pre-vetted and akin to official package repositories, or unvetted but executed within containers (which is still not really an ironclad security guarantee, but better than nothing). It is deeply sad to see something that supposedly exists to facilitate and promote a sandboxed distribution model give up and cop out so blatantly though. They should've just named the flag "--make-snaps-worthless-you-should-be-using-apt-instead". Is there a technical reason to prefer "classic" snaps over packages from the official repos? It seems like the default install path may be different and the libraries/installed files possibly better segmented on the filesystem, but ultimately that's little consolation.
  - beojan 8y ago
    If the application is trustworthy, it doesn't matter. If not, you should think twice about running it even in a container.
    - cookiecaper 8y ago
      To be clear, I agree. Containers on Linux are very weak security boundaries and should not be considered safe sandboxes for untrusted or dangerous code. In fact, post-Spectre, only physically independent hardware unattached to the network should be considered a reasonably safe sandbox. However, something is better than nothing, and it's just not true that there's no difference between running something from the AUR and running something in a "confined" snap. There is some crap in the way at least.
      - beojan 8y ago
        Good point. Though the fact that you read your PKGBUILDs before running them (you do read your PKGBUILDs, right?) at least compensates for this.
dtx1 8y ago
Well as a lazy arch user i installed pacaur and just use official and AUR sources without much checking. It's just convenient that there's an AUR for everything
- AsyncAwait 8y ago
  For packages with many votes this is somewhat fine, but you should still skim the PKGBUILD as the maintainers of even popular packages may change in time.
  - ChristianBundy 8y ago
    I'd recommend checking both PKGBUILD and clicking "View Changes" to see who (and what) the last few authors have been up to. It's relatively common for people to be added as co-maintainers after posting even just one helpful comment (!) in an unpopular package, so it's worth double-checking to make sure a big change hasn't been made recently without the author's permission.
    - michaelmrose 8y ago
      If this is your means to secure your system you may be in for a rude awakening.
- matthewbauer 8y ago
  Be warned that malware like this is in the AUR all the time. It's so common it's not even newsworthy. They are usually pretty good at handling it though.
  - voltagex_ 8y ago
    Any sources/articles for this?
  - pierrec 8y ago
    I've never heard of this happening and I can't find a single occurrence of it. I mean, I agree with "don't blindly trust everything in the AUR", but this seems wrong.
HankB99 8y ago
> ... and the AUR, which everyone knows are not officially endorsed or reviewed ... Uh, not everyone. I ran Manjaro for a bit and found that many of the things I ran were available via AUR. The usual thing I'd find in a search was usually something like: sudo pacman -Sy sudo pacman -S yaourt base-devel yaourt -Sy yaourt -S gpodder (That's the entire reply, BTW.) At some point I started to wonder what the provenance of these packages was and what the security implications were. I might have looked for information on the security risks of these packages but this is the first concrete claim I recall seeing about the subject. Probably a good thing I'm not running Manjaro any more. I do run Ubuntu and have some snaps installed (Golang, VS code among others) and I'm now wondering if it would be possible for a malicious developer to substitute compromised snaps for the official ones. My understanding is that they update silently and automatically so I wouldn't even know about updates if I didn't check logs.
- Shikadi 8y ago
  In ubuntu, it's even less obvious. Main, restricted, and universe are all checked together by apt, and treated the same
  - geofft 8y ago
    But main/restricted and universe are both vetted—the only people who can upload to universe are Debian developers (indirectly, via Ubuntu importing from Debian) and Ubuntu developers, and the process of becoming either of these is nontrivial. Ubuntu's equivalent of the AUR, if I understand the AUR right, is PPAs, which are definitely not enabled by default and are fairly obvious about their third-party-ness. (Main vs. restricted and universe vs. multiverse is just about licensing, not access control or vetting.)
    - Shikadi 8y ago
      It took me a good amount of googling to verify that, but you're mostly correct, there are only 132 developers with upload rights to the universe repository. Though I would argue that the distinction isn't just licensing, since Canonical themselves only support main and restricted.
newnewpdro 8y ago
When I began exploring rebuilding an Arch install from source using ABS it all seemed to blindly trust everything coming from the arch repos as not being compromised. There was zero signing of anything. I had hoped the package maintainers responsible for the housekeeping of all the associated metadata would have been signing it all with their respective keys. If someone were to compromise an upstream Arch server I suspect it wouldn't be especially difficult to inject malware or trojans somewhere even those building from source would receive.
- eat_veggies 8y ago
  I'm pretty sure all packages in the official repositories are signed: > Official packages: A developer made the package and signed it. The developer's key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers. source: https://wiki.archlinux.org/index.php/Pacman/Package_signing https://wiki.archlinux.org/index.php/Pacman/Package_signing
  - newnewpdro 8y ago
    I'm not talking about the binary packages.
michaelmrose 8y ago
A pop up of the pkgbuild is almost worthless. It would require the user to personally examine at the very least the source the pkgbuild is pulling from and the pkgbuild script itself and be able to spot malfeasance including subtle attempts. Since doing otherwise is a few clicks away and sufficiently subtle attempts are unlikely to be noticed by even observant parties this is about as bad as the windows hunt down an exe model which has been proven for decades NOT TO WORK. The AUR isn't filled with malware because arch is a very small target compared to windows full of observant people. It cannot possibly scale even to the levels ubuntu aspires to achieve.

zootboy 8y ago

Also, compare the wording on the snap store: > Safe to run - Not only are snaps kept separate, their data is kept separate too. Snaps communicate with each other only in ways that you approve. Versus the AUR: > DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk.

pasbesoin 8y ago
And then, a Snap doesn't behave as the user expects (e.g. like a "native" application). And the first solution on stack-whatever, is to install it using the "--classic" switch. Whereupon, there goes your sandboxing.
cookiecaper 8y ago
The difference being that Snaps always run in a semi-encapsulated environment (a container), whereas the AUR just executes in whatever security context you're issuing commands from. PKGBUILDs are arbitrary shell scripts and they can do anything that the user executing them can do. I'm not trying to defend the perception that Snaps are immune from malware, but there is a real difference in the default safety of a package off the Snap Store and the AUR.
- pritambaral 8y ago
  > Snaps always run in a semi-encapsulated environment (a container) Even with the `--classic` switch?
  - cookiecaper 8y ago
    I wasn't aware of the "classic" switch, looks like they added it early last year. They appear to call this "classic confinement mode", and it sounds like it functions essentially like a normal package manager, though they insist on saying it's a "relaxed security model" instead of "no additional security model at all", which appears to be the truth of the matter. Their site claims that only pre-vetted Snaps can be distributed with "classic confinement", so that's something at least. If that's true, it would allow the comparison between Snaps and the AUR to hold -- Snaps would either be pre-vetted and akin to official package repositories, or unvetted but executed within containers (which is still not really an ironclad security guarantee, but better than nothing). It is deeply sad to see something that supposedly exists to facilitate and promote a sandboxed distribution model give up and cop out so blatantly though. They should've just named the flag "--make-snaps-worthless-you-should-be-using-apt-instead". Is there a technical reason to prefer "classic" snaps over packages from the official repos? It seems like the default install path may be different and the libraries/installed files possibly better segmented on the filesystem, but ultimately that's little consolation.
- beojan 8y ago
  If the application is trustworthy, it doesn't matter. If not, you should think twice about running it even in a container.
  - cookiecaper 8y ago
    To be clear, I agree. Containers on Linux are very weak security boundaries and should not be considered safe sandboxes for untrusted or dangerous code. In fact, post-Spectre, only physically independent hardware unattached to the network should be considered a reasonably safe sandbox. However, something is better than nothing, and it's just not true that there's no difference between running something from the AUR and running something in a "confined" snap. There is some crap in the way at least.
    - beojan 8y ago
      Good point. Though the fact that you read your PKGBUILDs before running them (you do read your PKGBUILDs, right?) at least compensates for this.

dtx1 8y ago

Well as a lazy arch user i installed pacaur and just use official and AUR sources without much checking. It's just convenient that there's an AUR for everything

AsyncAwait 8y ago
For packages with many votes this is somewhat fine, but you should still skim the PKGBUILD as the maintainers of even popular packages may change in time.
- ChristianBundy 8y ago
  I'd recommend checking both PKGBUILD and clicking "View Changes" to see who (and what) the last few authors have been up to. It's relatively common for people to be added as co-maintainers after posting even just one helpful comment (!) in an unpopular package, so it's worth double-checking to make sure a big change hasn't been made recently without the author's permission.
  - michaelmrose 8y ago
    If this is your means to secure your system you may be in for a rude awakening.
matthewbauer 8y ago
Be warned that malware like this is in the AUR all the time. It's so common it's not even newsworthy. They are usually pretty good at handling it though.
- voltagex_ 8y ago
  Any sources/articles for this?
- pierrec 8y ago
  I've never heard of this happening and I can't find a single occurrence of it. I mean, I agree with "don't blindly trust everything in the AUR", but this seems wrong.

HankB99 8y ago

> ... and the AUR, which everyone knows are not officially endorsed or reviewed ... Uh, not everyone. I ran Manjaro for a bit and found that many of the things I ran were available via AUR. The usual thing I'd find in a search was usually something like: sudo pacman -Sy sudo pacman -S yaourt base-devel yaourt -Sy yaourt -S gpodder (That's the entire reply, BTW.) At some point I started to wonder what the provenance of these packages was and what the security implications were. I might have looked for information on the security risks of these packages but this is the first concrete claim I recall seeing about the subject. Probably a good thing I'm not running Manjaro any more. I do run Ubuntu and have some snaps installed (Golang, VS code among others) and I'm now wondering if it would be possible for a malicious developer to substitute compromised snaps for the official ones. My understanding is that they update silently and automatically so I wouldn't even know about updates if I didn't check logs.

Shikadi 8y ago
In ubuntu, it's even less obvious. Main, restricted, and universe are all checked together by apt, and treated the same
- geofft 8y ago
  But main/restricted and universe are both vetted—the only people who can upload to universe are Debian developers (indirectly, via Ubuntu importing from Debian) and Ubuntu developers, and the process of becoming either of these is nontrivial. Ubuntu's equivalent of the AUR, if I understand the AUR right, is PPAs, which are definitely not enabled by default and are fairly obvious about their third-party-ness. (Main vs. restricted and universe vs. multiverse is just about licensing, not access control or vetting.)
  - Shikadi 8y ago
    It took me a good amount of googling to verify that, but you're mostly correct, there are only 132 developers with upload rights to the universe repository. Though I would argue that the distinction isn't just licensing, since Canonical themselves only support main and restricted.

newnewpdro 8y ago

When I began exploring rebuilding an Arch install from source using ABS it all seemed to blindly trust everything coming from the arch repos as not being compromised. There was zero signing of anything. I had hoped the package maintainers responsible for the housekeeping of all the associated metadata would have been signing it all with their respective keys. If someone were to compromise an upstream Arch server I suspect it wouldn't be especially difficult to inject malware or trojans somewhere even those building from source would receive.

eat_veggies 8y ago
I'm pretty sure all packages in the official repositories are signed: > Official packages: A developer made the package and signed it. The developer's key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers. source: https://wiki.archlinux.org/index.php/Pacman/Package_signing https://wiki.archlinux.org/index.php/Pacman/Package_signing
- newnewpdro 8y ago
  I'm not talking about the binary packages.

michaelmrose 8y ago

A pop up of the pkgbuild is almost worthless. It would require the user to personally examine at the very least the source the pkgbuild is pulling from and the pkgbuild script itself and be able to spot malfeasance including subtle attempts. Since doing otherwise is a few clicks away and sufficiently subtle attempts are unlikely to be noticed by even observant parties this is about as bad as the windows hunt down an exe model which has been proven for decades NOT TO WORK. The AUR isn't filled with malware because arch is a very small target compared to windows full of observant people. It cannot possibly scale even to the levels ubuntu aspires to achieve.