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.

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.

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.

If the application is trustworthy, it doesn't matter. If not, you should think twice about running it even in a container.

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.

Good point. Though the fact that you read your PKGBUILDs before running them (you do read your PKGBUILDs, right?) at least compensates for this.

> Snaps always run in a semi-encapsulated environment (a container)

Even with the `--classic` switch?

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.

> ... 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.

You can't install unofficial packages via pacman. And AFAIK none of the unofficial/AUR package managers, like yaourt, are in the official repositories so the point where you cross the line is very clear and distinct and any wiki guide to installing from the AUR makes it clear you are going into unofficial territory.

I haven't used Manjaro but they seem to intentionally hide the distinction between the official and unofficial repos, which is a bad idea.

Also, yaourt has a lot of warnings and prompts at each step along the way to make absolutely certain that you understand what you're getting yourself into with the packages you're installing. The process is certainly not for beginners. Ubuntu seems to go for a more user friendly process instead.

In ubuntu, it's even less obvious. Main, restricted, and universe are all checked together by apt, and treated the same

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.)

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.

Universe is Canonical's dumping ground. There are millions of vulnerable Redis instances in production today because Ubuntu doesn't feel inclined to issue an update for a major CVE affecting the redis-server package shipped for 14.04.

There's multiple layers of problems here, because as we see with Ubuntu, just because the code was built and uploaded by a trustworthy person doesn't mean it's automatically safe or secure (especially for more nefarious infections that bury themselves deep in the source tree). Remember the pwnage that brought down kernel.org for a few months? That was only a few years ago, but the infiltration had been quite serious, and if I recall correctly, there was some concern that infected code had made it into officially distributed tarballs.

In practice, I don't know that the distinction between distributing packages that are trivially exploitable and distributing packages that have exploits pre-baked in is really that big of a difference. Automated scanners often pick up and automatically exploit exposed instances within a few days.

What it boils down to is that admins need to take responsibility for their own workload and what they choose to execute, no matter the guarantees of the distributor or the claims that $Sandbox_Y is magically impenetrable (which was silly enough before, but completely farcical in a post-Spectre world).

I mean that the distinction between main and restricted and between universe and multiverse is licensing. It's a 2x2 matrix:

              supported   only community
    free       main        universe
    non-FOSS   restricted  multiverse

Oh yeah, definitely misread that

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.

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

I'm not talking about the binary packages.

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.

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

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.

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.

I maintain 14 AUR packages and have also never heard of this happening.

Also, the aur community seems to be very active.

Any sources/articles for this?

citation needed

The AUR is really handy, but you do need to be careful. Arch does not pretend to hold the user's hand, and you're not likely to get much sympathy from the community if you get bitten by recklessly installing stuff from the AUR.

Also, as far as I know, pacaur is no longer maintained. I switched to trizen, which prints the PKGBUILD on screen before allowing the user to opt in to executing it. Not going to pretend that I always review the PKGBUILD thoroughly, but I do generally skim them, applying more scrutiny as packages become more obscure.

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.

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.

If this is your means to secure your system you may be in for a rude awakening.