Canonical on trust and security in the Snap Store

[Posted May 15, 2018 by corbet]

Here's a posting from Canonical concerning the cryptocurrency-mining app that was discovered in its Snap Store. "Several years ago when we started the work on snap packages, we understood that we could not instantly implement an alternative that was completely safe from all perspectives. In addition to being safe, it had to be useful. So the challenge we gave ourselves was to significantly improve the situation immediately, and then pave the road for incremental improvements that could be rolled out gradually."

to post comments

Canonical on trust and security in the Snap Store

Posted May 15, 2018 20:55 UTC (Tue) by Tov (subscriber, #61080) [Link] (2 responses)

OK, so which snap was it and what was the name of the publisher??

I fail to see the benefit of tip-toeing around the central question of *who* thought it to be a good idea to (ab)use their users computer resources for personal gain without their knowing. As the publisher did not find it unethical, they would surely not mind being open about it - or what?

Then we can decide for ourselves who to trust...

Canonical on trust and security in the Snap Store

Posted May 15, 2018 21:29 UTC (Tue) by Tov (subscriber, #61080) [Link] (1 responses)

More detail here: https://github.com/canonical-websites/snapcraft.io/issues...
The snaps were named "2048buntu" and "hextris". Apparently a lone developer with bad judgment...

Canonical on trust and security in the Snap Store

Posted May 16, 2018 15:52 UTC (Wed) by sce (subscriber, #65433) [Link]

Look at what one of the commenters on hacker news is claiming:

> Whoa, I made Hextris (https://github.com/hextris/hextris, one of the games removed from the store) a few years ago! Is there any precedent in OSS developers being held responsible for misuse of their code?

https://news.ycombinator.com/item?id=17055986

Canonical on trust and security in the Snap Store

Posted May 16, 2018 1:29 UTC (Wed) by lsl (guest, #86508) [Link]

The "legitimate monetization" angle pushed by the developer (and regurgitated in the Canonical post) loses all remaining credibility (if any) when you go on and name your mining program executable "systemd".

Canonical on trust and security in the Snap Store

Posted May 16, 2018 13:09 UTC (Wed) by jriddell (subscriber, #3916) [Link] (8 responses)

Snaps have no source code repository. This is obviously illegal for GPL and a pain for all open source software. But it also means it's even easier to sneak problems into the code such as this. It's much the same for FlatPak and AppImage.

Canonical on trust and security in the Snap Store

Posted May 16, 2018 13:22 UTC (Wed) by Otus (subscriber, #67685) [Link]

> Snaps have no source code repository. This is obviously illegal for GPL [...]

Not if the program comes with a written offer to provide the source code for three years to anyone who requests it.

Canonical on trust and security in the Snap Store

Posted May 16, 2018 15:18 UTC (Wed) by callegar (guest, #16148) [Link] (3 responses)

Out of curiosity, when a snap is on the snap store, who is the actual distributor, namely who is responsible for delivering the sources in case the snap contains binaries that need to be accompanied by the sources? Is it the author of the snap or the snap store itself?

Canonical on trust and security in the Snap Store

Posted May 16, 2018 18:05 UTC (Wed) by khim (subscriber, #9252) [Link] (2 responses)

Ultimately it would be up to court to decide, but I SERIOUSLY doubt Snap Store could be held responsible. Otherwise all these mirrors on sites like kernel.org would also be burdned by that which would be a nightmare.

Canonical on trust and security in the Snap Store

Posted May 16, 2018 22:21 UTC (Wed) by callegar (guest, #16148) [Link] (1 responses)

I was asking precisely because I was traying to figure out analogies (as you did), yet getting the impression that none is really a good fit. For instance, for sites that are mirrors, pointing at the mirrored source would likely be enough. Conversely, for an application on a store there may not be any other upstream site. Furthermore, what happens if the original author of some application goes himself offline? Doesn't that leave the store as the sole distributor? Finally, while many mirrors are not for profit, an App Store is usually meant to monetize the apps it provides, even those that are given away for free, for which the value creation is indirect, either via advertising or by the creation of a critical mass around commercial services. This may suggest that distribution is an inherent part of the business for which the store may be held accountable. I wonder if these aspects have already been evaluated for other app stores.

Canonical on trust and security in the Snap Store

Posted Jun 9, 2018 16:27 UTC (Sat) by JanC_ (guest, #34940) [Link]

If mirror sites were responsible, they would still have to provide sources up to 3 years (or so) after the mirrored source goes offline; nobody would want to run a mirror site if that were true…

I think in general the (main) responsibility is with the entity who makes the decision to distribute, and not the medium they use to distribute (be that a network of mirrors or an app store). Although in recent times there has been a push from the copyright lobby to make the distributors responsible…

Canonical on trust and security in the Snap Store

Posted May 17, 2018 1:18 UTC (Thu) by smcv (subscriber, #53363) [Link] (2 responses)

There's a convention for how to make source code available in a Flatpak repository (source code for app or runtime com.example.Foo is in an extension named com.example.Foo.Sources in the same repository), and for apps built from source using flatpak-builder (like those on Flathub) the creation of the Sources extension from the inputs to the build is automated. The build isn't normally allowed to access the network, so everything that contributes to the build has to be pre-downloaded, and all the pre-downloaded files end up in the Sources extension.

It's entirely possible to publish a Flatpak app or runtime without source, just like it's possible to publish a dpkg or RPM package without source, but the tooling to do it right does exist.

(As with dpkg/RPM, the "source" might just be an archive containing prebuilt binaries, which is how proprietary apps' packaging is normally implemented; knowing that you've built an app from some sort of downloadable archive is no substitute for review.)

Canonical on trust and security in the Snap Store

Posted May 17, 2018 1:26 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Where is this documented? Last time I was trying to find a source code for Asterisk snap (to rebuild it for ARM64) and I couldn't figure this out.

Also, is anybody working on deterministic builds for snaps? Otherwise we're definitely in "left-padding my wallet" territory: https://hackernoon.com/im-harvesting-credit-card-numbers-...

Canonical on trust and security in the Snap Store

Posted May 17, 2018 1:26 UTC (Thu) by smcv (subscriber, #53363) [Link]

For example:

% flatpak --user remotes -d
Name Title URL Priority Options
flathub Flathub https://dl.flathub.org/repo/ 1
% flatpak --user remote-ls -a flathub
...
ca.desrt.dconf-editor
ca.desrt.dconf_editor.Debug
ca.desrt.dconf_editor.Locale
ca.desrt.dconf_editor.Sources
...
% flatpak --user install flathub ca.desrt.dconf_editor.Sources
% ( cd ~/.local/share/flatpak/runtime/ca.desrt.dconf_editor.Sources/x86_64/stable/active/files; find . )
.
./downloads
./downloads/455b53d827820efd28a176ee52e13eda5cda8cdf4e31e0145cfdd69931bf0c5a
./downloads/455b53d827820efd28a176ee52e13eda5cda8cdf4e31e0145cfdd69931bf0c5a/dconf-editor-3.28.0.tar.xz
./manifest
./manifest/ca.desrt.dconf-editor.json
./.ref

Canonical on trust and security in the Snap Store

Posted May 21, 2018 10:33 UTC (Mon) by simosx (guest, #24338) [Link]

An issue with snap packages is that the packager only uploads the completed .snap package to the Snap Store.
They do not need to provide details as to which source code repository they used, and their full configuration settings.
If a snap package is called mysnap, then you can see the partial configuration at /snap/mysnap/current/meta/snap.yaml. It's handy!
But it does not include the full snapcraft.yaml file because what you get in snap.yaml is the information that was inserted into the snap package. And it would be elemental for someone to fake such a file, if they had to.

The alternative would be for the packager to provide instead the snapcraft.yaml configuration file which is mainly needed to build the .snap package.

It makes sense for now (less complexity, faster acceptance of snap packages, friendlier for closed-source) that the Snap Store only deals with generated .snap packages, and not have to be a build server as well.

I envision some separate service that works like a build server, and the packager feeds them with the snapcraft.yaml file. The build server build the .snap package and uploads it to the Snap Store. In this way, it would be possible to get a nice guarantee of how a package was built and what was the snapshot of the source code at the time of building.