Linux Mint drops Ubuntu Snap packages

Posted Jul 8, 2020 21:33 UTC (Wed) by IanKelling (subscriber, #89418)
Parent article: Linux Mint drops Ubuntu Snap packages

Trisquel has never had snap, one reason being that the snap repo mixes
nonfree and free software without giving the user any way avoid nonfree
software without manually reviewing the license of each snap.

Licensing within snaps seems intentionally poor, I just downloaded the
gnome-sudoku snap, and it has insufficient license information for
GPLv3+ which it is under. Building it failed after getting fairly far
within the VM the build downloaded.

So, random binaries that you can't reproduce, bad licensing, no
differentiation between free and nonfree, and secret repo software
clearly designed for vendor lock-in. Reminds me of docker and nodejs. I
hope people demand better in all cases. It's clear that they were are
all designed from beginning to cater to nonfree software in many ways.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 4:12 UTC (Thu) by ras (subscriber, #33059) [Link] (10 responses)

> So, random binaries that you can't reproduce, bad licensing, no differentiation between free and nonfree, and secret repo software clearly designed for vendor lock-in.

Ye gods. Thanks for summarising it so well.

Is Flatpack any better?

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 7:24 UTC (Thu) by abo (subscriber, #77288) [Link] (9 responses)

Flatpaks can have pretty clear metadata including license information, and Flathub (the main repository) builds everything from specifications that are public in git repos, in a way that should be easily reproducible.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 7:49 UTC (Thu) by tsdgeos (guest, #69685) [Link] (8 responses)

Not really, flathub has non free stuff in it too

https://flathub.org/apps/details/us.zoom.Zoom
https://flathub.org/apps/details/com.spotify.Client

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 8:07 UTC (Thu) by abo (subscriber, #77288) [Link] (1 responses)

It does, yes. But it's clearly marked and even the proprietary packages are reproducible (starting with the upstream binaries).

They could of course split the repo into free and nonfree, like many other distros and third party repos of various kinds do. But that's a choice made by the Flathub maintainers, either way would be possible with Flatpak.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 14:58 UTC (Thu) by IanKelling (subscriber, #89418) [Link]

Is there a configuration option or a command line flag I can use to only install freely licensed packages from flathub? If not, then it still has one of the same major problems as snaps.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 8:19 UTC (Thu) by ras (subscriber, #33059) [Link] (5 responses)

> Not really, flathub has non free stuff in it too

So does Debian. In Debian non-free there are binary blobs without source that run under Debian (as opposed to being firmware that runs on a different CPU). But that it's clearly marked - in fact not even available unless you manually add it.

Just as importantly the rest (which is the vast bulk of it) is truly open source - meaning it can be built from the source files available from Debian using a one line command, perhaps even reproducibly built.

The difference is not just just philosophical. The availability of source means Debian stable can be truly stable - security flaws have just the change needed to fix the flaw applied, as opposed to an entirely new version. And the open source programs have an audit trail from the binary to the upstream source, usually going back many versions. It's one of the few antidotes we have to Ken Thompson's "reflections on trust".

So the differentiator isn't whether they include proprietary binary blobs. It's whether the flatpacks that are open source preserve all the advantages of open source.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 9:37 UTC (Thu) by pabs (subscriber, #43278) [Link]

> security flaws have just the change needed to fix the flaw applied, as opposed to an entirely new version

That isn't always the case, especially for packages that are their own mini-distribution, like modern web browsers such as Chromium or Firefox.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 23:01 UTC (Thu) by sheepgoesbaaa (guest, #98005) [Link] (3 responses)

I had never heard of "Reflections on Trusting Trust", and I just read it, really interesting.

PDF link: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_...

Linux Mint drops Ubuntu Snap packages

Posted Jul 10, 2020 15:37 UTC (Fri) by stephen.pollei (subscriber, #125364) [Link] (2 responses)

Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers

Linux Mint drops Ubuntu Snap packages

Posted Jul 10, 2020 23:17 UTC (Fri) by ras (subscriber, #33059) [Link] (1 responses)

David Wheeler's paper is one solution, but I've never heard of an instance of the technique he describes catching anything.

On the other hand, the techniques Open Source has developed over the years has caught a few attempts to slip nefarious code in. Those techniques are:

1. A cryptographically sealed audit trail of every change (eg, git's sha1 sums).

2. Digitally signed commits, so if someone does slip something in you know who was responsible. (This is something Wheeler's technique doesn't give you).

3. Open Source, as in everyone can see and verify the previous two points for themselves.

But the sound of it Snap throws all of this away. In this era repeated of nation state attacks on infrastructure, to me that creates an unacceptable risk. Currently that seems to be a lonely position to take, but I'm betting as we get more Huawei style conflicts arise we see gradual realisation Open Source is the one of the few things that naturally gives rise to trust between otherwise antagonistic parties.

Linux Mint drops Ubuntu Snap packages

Posted Jul 20, 2020 2:29 UTC (Mon) by branden (guest, #7029) [Link]

Fortunately the state of the art has advanced since Thompson coded his Trojan. Here's a paper from 2013:

"We extend the existing formal verification of the seL4 operating system microkernel from 9 500 lines of C source code to the binary level [11,736 instructions]. We handle all functions that were part of the previous verification. Like the original verification, we currently omit the assembly routines and volatile accesses used to control system hardware.More generally, we present an approach for proving refinement between the formal semantics of a program on the C source level and its formal semantics on the binary level, thus checking the validity of compilation, including some optimisations, and linking, and extending static properties proved of the source code to the executable. We make use of recent improvements in SMT solvers to almost fully automate this process.We handle binaries generated by unmodified gcc 4.5.1 at optimisation level 1, and can handle most of seL4 even at optimisation level 2."

https://ts.data61.csiro.au/publications/nicta_full_text/6...

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 5:49 UTC (Thu) by simosx (guest, #24338) [Link] (9 responses)

They are looking into implementing a switch to show open free/open-source software in the Snap Store.
It is a low-hanging fruit and makes sense to those that really need it.

You claim an issue with packaging gnome-sudoku. As these are packaged inside VMs, it does not make sense why it would not be reproducible.
If you look into the snapcraft.yaml, you can easily check whether it locks into a git branch or whether it tries to build from /master/.
In the latter case, you obviously expect issues. You need to see the git commit hash in the snap package information, and switch to using the exact snapshot of the source code.

In addition, if you are not using the Ubuntu VM to build the snap package (invoked by snapcraft for you), then you are expected to find some issues here and there. Snap packages aim to run anywhere, and the snapcraft.yaml is not tested to build anywhere.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 13:45 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

They can just get chromium from debian. Not that hard really.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 15:04 UTC (Thu) by IanKelling (subscriber, #89418) [Link] (3 responses)

Right, it generally seems like it should work, I was too harsh implying it's a general problem without more research. So, what I did was:

snap download gnome-sudoku
sudo mount -t squashfs gnome-sudoku_59.snap /mnt/4
cd /mnt/4
snapcraft --debug

It failed on meson trying to run something and finding no c++ compiler.

Where did I go wrong?

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 16:02 UTC (Thu) by simosx (guest, #24338) [Link] (2 responses)

> Where did I go wrong?

You used this process as a way to get access to the "snapcraft.yaml" recipe file.
And you tried to build it inside a read-only location. Snapcraft should install all the requirements

Here is what you should add.

mkdir -p ~/MYSNAPDEVELOPMENT/gnome-sudoku
cp /mnt/4/snap/snapcraft.yaml ~/MYSNAPDEVELOPMENT/gnome-sudoku/
cd ~/MYSNAPDEVELOPMENT/gnome-sudoku/
snapcraft

Snapcraft will use "multipass" to setup a VM, enter the VM, and build "gnome-sudoku". Finally, it will take the built gnome-sudoku snap package and copy it back to your host.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 16:55 UTC (Thu) by IanKelling (subscriber, #89418) [Link] (1 responses)

Same error as before. Here's the last lines, some obvious ones replaced with ...

Cloning into '/root/parts/gnome-sudoku/src'...
...
Note: checking out '2ecbfa7bc71a5c79716517634858eaa16b4f9957'.
...
Collecting meson
Downloading https://files.pythonhosted.org/packages/04/db/53fe14aa9a4... (1.7MB)
100% |████████████████████████████████| 1.7MB 569kB/s
Building wheels for collected packages: meson
Running setup.py bdist_wheel for meson ... done
Stored in directory: /root/.cache/pip/wheels/66/09/2d/4fcfb30d06d18fd9bdc67a724b8a56844e94cc194a45ea41f7
Successfully built meson
Installing collected packages: meson
Successfully installed meson-0.54.3
Get:1 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
...
Get:39 http://archive.ubuntu.com/ubuntu bionic-updates/universe Translation-en [340 kB]
Fetched 31.7 MB in 6s (5240 kB/s)
Get:1 libqqwing2v5_1.3.4-1.1_amd64.deb [16.5 kB]
Fetched 16.5 kB in 0s (0 B/s)
Get:1 libgee-0.8-2_0.20.1-1_amd64.deb [210 kB]
Fetched 210 kB in 0s (0 B/s)
Get:1 libffi6_3.2.1-8_amd64.deb [17.9 kB]
Fetched 17.9 kB in 0s (0 B/s)
Get:1 libglib2.0-0_2.56.4-0ubuntu0.18.04.6_amd64.deb [1171 kB]
Fetched 1171 kB in 0s (0 B/s)
Pulling libraries
Skipping build desktop-gnome-platform (already ran)
Building gnome-sudoku
meson --prefix=/usr snapbuild
The Meson build system
Version: 0.54.3
Source dir: /root/parts/gnome-sudoku/build
Build dir: /root/parts/gnome-sudoku/build/snapbuild
Build type: native build
Project name: gnome-sudoku
Project version: 3.32.0
Using 'LDFLAGS' from environment with value: ' -L/root/stage/lib'

meson.build:1:0: ERROR: Unknown compiler(s): ['c++', 'g++', 'clang++', 'pgc++', 'icpc']
The follow exceptions were encountered:
Running "c++ --version" gave "[Errno 2] No such file or directory: 'c++': 'c++'"
Running "g++ --version" gave "[Errno 2] No such file or directory: 'g++': 'g++'"
Running "clang++ --version" gave "[Errno 2] No such file or directory: 'clang++': 'clang++'"
Running "pgc++ --version" gave "[Errno 2] No such file or directory: 'pgc++': 'pgc++'"
Running "icpc --version" gave "[Errno 2] No such file or directory: 'icpc': 'icpc'"

A full log can be found at /root/parts/gnome-sudoku/build/snapbuild/meson-logs/meson-log.txt
Failed to run 'meson --prefix=/usr snapbuild' for 'gnome-sudoku': Exited with code 1.
Verify that the part is using the correct parameters and try again.
Run the same command again with --debug to shell into the environment if you wish to introspect this failure.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 19:35 UTC (Thu) by simosx (guest, #24338) [Link]

I am using LXD as the backend, instead of multipass. And it worked for me, the snap package was created.

$ snapcraft --debug --use-lxd

I do not know why you are getting those messages.
I suggest to have a look at the page at
https://forum.snapcraft.io/t/snaps-officially-supported-b...
which lists the officially supported snap packages by Canonical.
You can file a bug report if a snap package does not build for you.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 15:13 UTC (Thu) by IanKelling (subscriber, #89418) [Link]

> They are looking into implementing a switch to show open free/open-source software in the Snap Store.
> It is a low-hanging fruit and makes sense to those that really need it.

It's the biggest problem I have with snaps. I hope it gets done!

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 15:26 UTC (Thu) by DigitalBrains (subscriber, #60188) [Link] (2 responses)

> As these are packaged inside VMs, it does not make sense why it would not be reproducible.

I think you're using a different notion of reproducibility here than is common. Reproducability means I can download a binary compiled by someone else, and using the source code, verify that it was indeed built from *that* source. In essence, I will compile a binary myself and be able to prove the binary I downloaded is the same as my binary. This requires specific things in the compilation process, for instance, there can't be any timestamps of the build or non-deterministic behaviour in compilation.

Your notion of reproducability seems merely to say everybody can setup a build environment.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 15:43 UTC (Thu) by IanKelling (subscriber, #89418) [Link]

> I think you're using a different notion of reproducibility here than is common.

You're right. I shouldn't have said reproducible. I should have said someting like buildable, or rebuildable.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 15:48 UTC (Thu) by simosx (guest, #24338) [Link]

> Your notion of reproducability seems merely to say everybody can setup a build environment.

You do not "setup a build environment" yourself. The software (snapcraft and the Build service) launch the same build environment in a brand new VM of a generic Ubuntu image. The pieces are there so that two different users may well end up with the same binaries.
Whether this is offered as a future service, it looks to be easy to implement.