[geofft]

There is no review process or central restrictions on who can upload to the Ubuntu Snap Store, so in a sense, this isn't surprising. https://docs.snapcraft.io/build-snaps/publish

Does the name "Ubuntu Snap Store" carry a connotation that code is reviewed for malware by Ubuntu, the way that the Apple, Google, Amazon, etc. mobile app stores are? Or does its presence in the software center app imply a connotation that it's endorsed by the OS vendor?

I was at a PyCon BoF earlier today about security where I learned that many developers - including experienced developers - believe that the presence of a package on the PyPI or npm package registries is some sort of indicator of quality/review, and they're surprised to learn that anyone can upload code to PyPI/npm. One reason they believe this is that they're hosted by the same organizations that provide the installer tools, so it feels like it's from an official source. (And on the flip side, I was surprised to learn that Conda does do security review of things they include in their official repositories; I assumed Conda would work like pip in this regard.)

Whether or not people should believe this, it's clear that they do. Is there something that the development communities can do to make it clearer that software in a certain repository is untrusted and unreviewed and we regard this as a feature? The developers above generally don't believe that the presence of a package on GitHub, for instance, is an indicator of anything, largely because they know that they themselves can get code on GitHub. But we don't really want people publishing hello-worlds to PyPI, npm, and so forth the way they would to GitHub as part of a tutorial, and the Ubuntu Snap Store is targeted at people who aren't app developers at all.

[eat_veggies]

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]

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]

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]

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.

[beojan]

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

[cookiecaper]

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]

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

[pritambaral]

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

Even with the `--classic` switch?

[cookiecaper]

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.

[HankB99]

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

[B-Con]

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.

[gmueckl]

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.

[Shikadi]

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

[geofft]

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]

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.

[cookiecaper]

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

[geofft]

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

[newnewpdro]

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]

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

[newnewpdro]

I'm not talking about the binary packages.

[michaelmrose]

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.

[dtx1]

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

[matthewbauer]

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.

[pierrec]

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.

[nerflad]

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

[atomicnumber1]

Also, the aur community seems to be very active.

[voltagex_]

Any sources/articles for this?

[michaelmrose]

citation needed

[cookiecaper]

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.

[AsyncAwait]

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]

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]

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

[foepys]

> Does the name "Ubuntu Snap Store" carry a connotation that code is reviewed for malware by Ubuntu, the way that the Apple, Google, Amazon, etc. mobile app stores are?

As far as I know, Apple is the only company that manually reviews the code of apps, and even they let some (in my opinion) malware through [1]. Everybody else just does some heuristic anti-malware checking and then publishes the app.

1: Uber was permanently fingerprinting devices, even though Apple was disallowing this kind of tracking in their ToS.

[vanviegen]

Apple is reviewing code? I don't think the blob submitted to Apple includes actual source code. The way I understand it, they (briefly) tap through the app manually, and (like other stores) apply some automated heuristics on the binary.

[kpcyrd]

Firefox addons are reviewed. That's why malicious firefox addons are a lot less common than malicious chrome extensions.

[stiGGG]

Can confirm that Mozillas review process is the most sofisticated i’ve ever experienced. The good thing is that when they have something to complain you have a competent person on the other side that really helps you. Not like Apple who only send you some boilerplate to all your responses. The downside at Mozilla is that it takes them ages to even start the review, it took me once over 2 month to get my extension in their catalog.

[John_KZ]

Why do they allow so many extensions that rely on third-party services though? I don't like this trend. Especially given there's no network sandboxing of any sort, giving permissions for an extension to access your data locally is very different from allowing it to send them to a third-part, untrusted server.

[tinus_hn]

Apple doesn’t get the source code of apps. They check what apis you use so they can prevent you from using non public apis and they run some cursory checks. But there is a lot of crap on the App Store.

[mcny]

I really wish we had app stores actually require vendors to submit source code and build instructions so that the app store would build it themselves and publish it. Something like F-Droid even if the source code is not publicly available.

[cookiecaper]

It's difficult to get useful code review out of colleagues working for the same company. The idea that Apple et al should have a competent reviewer audit each submission is simply not a practical thing for any type of repo that accepts software developed by third parties.

[zer00eyz]

Sometimes a small comment in HN makes one think in a whole new way.

I agree with you that useful code review is a tough nut to crack. Professional editors exist for writing, and science has the peer review process (also flawed).

Reading code, is a whole different ball of wax from writing it (and from optimizing it in some cases) - I can think of few people who are great at both. I have to wonder if we will ever get to the point where "review" sits in an outside role/function that isn't already overloaded (team lead, architect, management).

Does the fact that we don't have dedicated code reviewers speak to its immaturity or (in)effectiveness.

[matthewbauer]

I assume other companies have testing processes that would pick up mining scripts like this. It sounds like "Ubuntu Snap Store" is similar to the AUR (which in fact can have lots of malware) in function. It's just the name is misleading.

[ISL]

I do tend to believe that the presence of a package in the Debian repositories is a limited representation of quality/review, as there is a package-maintainer and apparent community decision as to whether or not to keep it in the distro.

Is that perception correct?

[geofft]

That perception is correct. It's limited because in practice Debian developers (being almost entirely volunteers!) don't have the resources to read and audit each line in an upstream release, so certainly intentionally obfuscated backdoors from a previously trustworthy upstream would almost certainly get through. But the type of attack in this article, with a new binary and an unwanted line of shell script to run it, would be very unlikely to get through.

There's also a limited set of people who can upload new packages and a separate team that reviews those, so duplicated functionality / low-quality apps are unlikely to make it into the archive in the first place. Yet Another 2048 Clone would probably not be allowed in unless it was part of e.g. an official GNOME game set.

It also helps that Debian insists on recompiling everything from source and does not redistribute binaries from an upstream source, even if freely-licensed source code is provided.

[im3w1l]

Thanks a lot for clarifying these things. Do they do any identity verification so people can be held accountable after the fact if something shady were to be discovered?

[jlgaddis]

Yes.

> All work in Debian is performed by developers that can be identified. For those using Debian to be able to trust Debian, we feel it is important that our users can identify those that are working on the project and that development is as transparent as is possible. [0]

I don't personally use Debian very much these days -- my desktops all run Fedora, my servers (with a few exceptions) run CentOS and RHEL -- but I used Debian exclusively for many, many years and out of all Linux distributions Debian (IMO, of course) comes the closest to doing things "the right way". In and of itself, that is pretty amazing, I think, considering that there isn't really all that much that has changed in its 25 year history! In other words, they somehow managed to get things right the first time around.

There are a few things that could perhaps be done a little better or different but -- considering that Debian is an all-volunteer project -- I think they manage to do an awesome job with the limited resources available to them.

[0]: https://wiki.debian.org/DebianKeyring

[geofft]

Yes, that's part of why Debian uses PGP keys for package uploads and insists that your key is signed by other Debian developers and not simply anyone in the web of trust. (I am aware of one Debian developer who contributes / is known to the community by a pseudonym, but I'm told that a few other senior people in Debian know this person's legal name for this exact reason.)

[throwaway08320]

While full auditing is impossible for any distribution, Debian has a multiple people eyeballing code.

Apart the package maintainers and contributors, the Security Team can also review critical packages and step in if something looks suspicious.

But, most importantly, the release cycle and the long freeze before releases is all about STABILITY and SECURITY.

Anybody can upload backdoored code on npm/PyPI etc, infect someone and then remove the malicious release without being detected.

Releasing something malicious or with serious bugs before a freeze cycle and going undetected for months is not impossible but much more difficult.

[avar]

Your perception is entirely incorrect. Debian maintainers don't have the time (or often the knowledge) to review upstream changes. Do you think the Debian Linux, GCC and Xorg maintainers exhaustively review and understand every patch? They don't.

Instead, the reason you don't see malware pushed to those repositories is because the incentives in the free software world don't align to make them happen in the first place. The moment some project would embed phone-home advertising it would be forked and replaced by all the major distros, so it doesn't happen.

There's also an alignment of incentives between upstream and packagers. If e.g. Xorg tried to embed something evil the volunteer contributors to Xorg would pro-actively sound the alarm and tell distros before they shipped that code.

None of this is true in the iOS and Android stores where you have proprietary paid-for apps where the incentive is to extract as much value from the user as the app store in question will allow, and where the upstream maintainers aren't free software advocates but some corporate employees that'll do what they're told at the cost of the wider software community.

It's an adversarial relationship, not a cooperative relationship.

[matthewbauer]

The particular problem with Snappy is all that's submitted is a single binary blob. Usually with free software source code is submitted & built that has multiple mirrors. That alone can make a big difference.

[throwaway08320]

> Debian maintainers don't have the time (or often the knowledge) to review upstream changes > Do you think the Debian Linux, GCC and Xorg maintainers exhaustively review and understand every patch? They don't.

This is plain false. While it's impossible to guarantee a 100% code reviews, the number of bugs and vulnerabilities found, reported upstream, and patched by distributions (especially Debian) shows that code is being reviewed.

[yrro]

Every line of code should have been reviewed by at least one DD. But the system is self policing, so it's hard to guarantee that that's the case. But Debian certainly leans towards being a curated collection of software rather than a wild west.

[icebraining]

Self-policing? Aren't only DDs allowed to upload to the repositories? From what I understand, dak (the Debian archive management software) won't publish a package which hasn't been approved by a sponsor DD.

[geofft]

The part that's self-policing is that nobody verifies that a DD has in fact reviewed the code that they're signing and uploading (and as another reply points out, for large codebases like the Linux kernel, the maintainer almost certainly doesn't and just trusts the upstream signature).

[jacquesm]

Ever since I learned about it and then read up on it Anaconda has been my go-to way of using Python. Python packaging is a huge mess.

[RayDonnelly]

Glad to hear it. We take these matters very seriously, including good hardening flags etc: https://www.anaconda.com/blog/developer-blog/improved-securi...

[jakobegger]

I think a big difference between Github and package managers is that on Github everything is prefixed with a user name. It takes two clicks to find out who made jakob/TableTool. It’s obvious that the author is a random dude on the internet.

But the brew cask package “table-tool”? That sure sounds official!

[madrox]

The lesson I learned from this comment is "if you assume security, you won't get security."

[rando444]

While code reviews are helpful, can they really prevent malware?

(since an app can always download and execute extra code after it's installed.)

[geofft]

Yes - the code review can say "This app has functionality to download and execute extra code without the user's active participation/consent, which isn't allowed."

iOS enforces this in several ways. Any executable page of code must be signed by Apple (unless your phone is jailbroken), so you simply can't ship native code outside of the App Store delivery path. Apple looks at what functions you link against and bans "private API", and functions like dlsym() that let you open arbitrary symbols from a runtime string are forbidden. Apple usually disallows things that look like they're downloading and interpreting some language at runtime (though I'm not clear on the current rules for this, and I think things like e.g. Python shells are fine as long as it's user-supplied code). The only exception is JavaScript inside a webview, and that doesn't give you any access to the system without having native code to expose things to JavaScript, and Apple can review that native code.

Debian will enforce this too, for computing-freedom reasons as opposed to platform-control reasons: it's impossible for Debian to say "yes, this is free software" if the code isn't available for Debian to audit. And it's obviously impossible for Debian to check it for malware / unwanted functionality. Applications like Firefox or pip can download and install code at the user's request, but applications that automatically download part of their core functionality cannot go into Debian without being patched to allow Debian to compile and ship those parts as part of the package.