The Wayback Machine - https://web.archive.org/web/20210628133643/https://forum.snapcraft.io/t/bogus-apps-in-store/4703/9

Bogus apps in store

store
#4

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

#5

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.

#6

Yes, I was thinking about official distro repositories which is what I see as snap alternative for user

#7

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.

#8

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.

#9

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.

#10

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

I don’t have any further questions and I’m thankful for your answers.

#11

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.

1 Like
#12

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

#13

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…

#14

Not sure I understand. Snapd already auto-connects interfaces as asserted by the store on install. Once installed the user is in control.

Peek 2018-03-28 10-11
Peek 2018-03-28 10-111205×835 1010 KB

2 Likes
#15

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.

#16

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.

1 Like
#17

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.

3 Likes
#18

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…

1 Like
#19

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?

2 Likes
#20

It’s in GNOME Software in 18.04. I’m sure @kenvandine or @robert.ancell can speak to the backporting plans.

1 Like
#21

Yes, that should be backported to 16.04.

2 Likes
#22

@Reynolds5 We are mostly in agreement. That’s why you need to trust the publisher, even if there is sandboxing. But sandboxing helps, even then. I do not trust any online password managers, for example, and local password managers can be 100% strictly confined. No access to anything. If there’s malware inside that sandbox, it cannot do much.

We understand, but this project aims at solving a larger problem, which includes reality based on data analysis. PPAs and third-party packages and repositories are extremely popular. So for this conversation to make sense at all we need to account for those.

Yes, that’s suboptimal, and we’ll work to improve this situation by introducing some level of publisher verification. But again this isn’t much different than other online trust building: how do you trust code in GitHub? How do you trust code from a third-party PPA? There are many answers and I don’t intend to go over these details, but the underlying point is that this isn’t much worse.

We show something very similar to that when people install unconfined snaps, and we always put the publisher name next to the snap name when listing or providing information about a snap.

@Ads20000 Yes, we’ll implement verification of publishers, so we can at least be more certain that there’s a real person or entity that corresponds to the name.

3 Likes
#23

To clarify “100% sandboxing”: if the snap doesn’t plugs network or network-bind, then the snap can’t send off the passwords somewhere. This sounds very reasonable for a password manager (even if it does plug x11 or unity7 (which due to X limitations, allow keyboard sniffing), since it can’t ship off anything it sniffs).