I was browsing through snaps avalaible in offcial store and noticed that there are two snaps of dnsmasq:
One of them called “dnsmasqd” wasn’t updated since 2016. Moreover its license is set as “proprietary” which obviously can’t be true. https://snapcraft.io/dnsmasqd
I looked around for more snaps from the same author and all of them are listed with “proprietary” license which isn’t true at least for some of them (didn’t check them all), maybe even all of them. https://uappexplorer.com/snaps?q=author%3ALoïc+Minier&sort=-points
Currently, when a publisher doesn’t specify licensing information for their snap, the store assumes the license to be proprietary. This is described in this thread:
It is something we’re working on fixing, because as you pointed out, it is an incorrect assumption. I suggest you read the above thread to learn where things stand.
Other than it being illegal, harmful, or misleading, there aren’t strict constraints imposed. Yes, snaps that target the same underlying software are allowed.
@roadmr thx, that explains from where it come from but I’m more concerned that it was submitted with wrong license 1,5 years ago and it’s still there untouched. I don’t know if it matters from legal point of view or is it only UX issue but the fact nobody verifies what packagers claim as license is questionable.
@niemeyer I think this is huge reputation risk for snaps similarly to what happened with Google Play which is known to be a can of malware where for every popular app, dozens of harmful imitations exist. Imagine if real malware was found in snapstore - it will be shouted in every corner of Linux related web.
Also it will be harder to attract users to snap when they realize that nobody looks what’s inside packages in contrast to deb repos which are scrutinized by distro maintainers.
At least there should be published rules for snapstore hosting and official way for users to report packages which violate them.
You are probably thinking of Canonical or Debian-published repositories, rather than “deb” repositories. And that’s the key difference which makes the whole problem more clear.
Nobody looks at every apt repository either, and we have a surprisingly large volume of those with PPAs and whatnot. You need to trust the publisher there just like you need to trust the publisher of snaps. That’s why we make the publisher very clear when you list or install a snap.
Snaps are simply making that picture more organized, and more secure by establishing more clear lines about which ways a given snap can access one’s data.
The story is richer and more comprehensive than that. When you see that “firefox” is published by “mozilla”, that’s literally what it means. It was Mozilla publishing that snap. And you can publish snaps too if you want.
I’m skeptical of this model which reminds me Google Play as I already said. I would expect something like Mozilla addons where every new addon is (or was as it isn’t true anymore) reviewed. Maybe not full source code review which isn’t feasible but at least look at what’s inside snapcraft.yaml. I think Flathub does it that way.
If the goal is to replace PPA then current approach may be still an improvement. Replacing traditional linux software distribution needs more safeguards.
Pretending to review is worse than not reviewing. We are not reviewing, and you need to trust the publisher just like in any other packaging publishing platform. If you are using a deb published by Google (in a repository or otherwise) you need to trust Google. If you are using a snap published by Google, you still need to trust Google.
That may sounds uncomfortable, but that’s exactly the situation you are already in no matter your choice of Linux, with or without snaps. If you are only using official Ubuntu repositories, you need to trust Ubuntu developers. If you use snaps that are only published by Canonical or snapcrafters, that’s who you are trusting.
The difference is that instead of asking people to host their repositories elsewhere, PPA or not, we have a convenient and integrated publishing platform, and also that we improved the packaging technology, including confinement strategies.
Please let us know if there are any other questions we might help with.
Trusting Google, Canonical or Debian developers which have proven track record is different than trusting dozens of unknown people.
I don’t know how users will choose packages when many duplicates of the same app are available without reading snapcraft.yaml and hunting for snap sources over the web. This is much different experience than installing something from official distro repos.
Maybe I’m overreacting, maybe no one care. On Windows people are installing apps straight from malware,com and they’re still happy.
I don’t have any further questions and I’m thankful for your answers.
I publish several snaps where I am not affiliated with the upstream maintainers. I publish these snaps because the upstream maintainers are not interested, or do not have the time, to publish their own.
I do not audit every line of the upstream source code. I publish these snaps with as strict a confinement as appears practical, so that even malicious upstream code is unlikely to harm the user. Occasionally, I patch the upstream code to allow the app to run under more strict confinement, and build from my patched repository. I think this is preferable to running an unconfined application.
I’m not saying your fears are unfounded. At present, a snap can be published which has access to a user’s home directory and the internet without triggering manual review, and without any indication to the user of the security risk if s/he installs the package. That’s far from perfect imho. But all of this is better than adding a PPA, or installing a random .deb which runs a postinstall script as root.
… and again, you can trust whoever you choose to trust, in both models. If those are the only deb publishers you trust, then only install snaps by those as well. Most of us will also trust those plus other vendors or open source developers that we’re comfortable with.
We do need the work on a GUI in Software for connecting interfaces to go through so that auto-connections/Terminal connections aren’t required. I think this will help from a security point of view. Users will be able to deny interface connections that they don’t need and are worried about the application using and the possibility of the user denying the interface connections (something users can’t really do in Android, for example?) should encourage upstreams to accept patches that allow confinement to work properly…
Sandboxing is meaningless when you install malware on your system. Imagine KepassXD - rogue password manager or browser or email client or dns client… malware doesn’t have to break any sandbox - all secrets already belongs to it.
I agree and already said that I’m comparing here snaps to official distro repositories, not PPA. Also I believe there are a lot of people who aren’t affiliated with upstream but still do high quality maintenance of snap packages but it’s hard to know that basing on snapstore info.
All Information Security is build on trust, that’s clear. If we stick to only known developers and vendors then number of available snaps would be cut tenfold for reasons which @mcphail described.
The question is how you can trust publisher when you know only his name and email? I believe most people install snaps from store because they trust Canonical and they think Canonical wouldn’t allow hosting snaps which could harm users.
If there was warning like “This snap is published by John Doe (john.doe@example,com). This snap isn’t affiliated with Canonical Ltd. Install at your own risk.” the situation will be more clear.
There is also a quality issue when snaps are outdated and unmaintained. No one should install dnsmasqd but some users do. I know PPA have same problem but this package is in official repos of every distro and users will expect similar quality in snapstore otherwise there is no point.
You may say that Canonical provides only a platform and publishers and users are free to do everything they want but I doubt it will end happily.
If Canonical are too controlling though then they’ll get criticized for censoring / being over-controlling etc. Atm they’re taking a very radical neutral stance when it comes to managing the store. I think there were plans for some sort of verified publisher system though? Also I think the warning message you suggested could work.
Again it’s up to the users to work out what works and what doesn’t. Ubuntu reviews (at least) have been disabled for snaps and Flatpaks (in GNOME Software), maybe these need to be re-implemented on snappy’s level (rather than GNOME Software/Ubuntu’s level) to allow for independent assessment of the quality of software. Outdated and unmaintained snaps would run the risk of getting one-star ratings and reviews, which should be useful for the end-user…
Some in the community already despise certain snappy design decisions for being over-centralizing so Canonical going further here would potentially incur more anger, rather than less.
However you can see, for example, this decision for a precedent for removing outdated/unmaintained apps, as you can see, the store managers were very reluctant to do so but there is a precedent, at least, for removing an outdated snap when the snapcrafter isn’t contactable and when there’s an existing snap which is up-to-date.
That doesn’t make sandboxing meaningless. If a browser is sandboxed and cannot access the user’s home directory it can only leak whatever information is passed through its sandbox. Yes, that is still horrible; but it is better than the status quo.
That’s amazing!!! Is that in Software 3.28 (and I’m guessing will be backported to 16.04 LTS and 14.04 LTS at some point)? Software 3.26.1-0ubuntu2.17.10.1 doesn’t have that…
The “official” way to install Google Chrome is via a .deb from Google. This nasty package adds a PPA as part of its postinstall script which has caused breakage in Ubuntu in the past, and a root cron job to replace the PPA if the user removes it. I don’t trust Google to do the right thing either. Wouldn’t it be better to have this as a snap?
