Ubuntu Summit One of the most common bits of FUD about Ubuntu's Snap packaging format is that it's proprietary - but exploring the documentation shows that is wrong.

At last weekend's Ubuntu Summit in Rīga, Latvia, the Reg FOSS desk talked with Ubuntu developer advocate Igor Ljubuncic about Snap, and especially some of the myths about it: that it's entirely closed source, or restricted to Canonical control, or that you must use Canonical's Snap Store, and multiple other fallacies.

If there is one thing we hate more than bad software, it's lies. As we noted looking at Fedora 39, there have been holy wars of software advocacy since long before Linux existed, but please at least stick to facts. There's no need to make up malicious falsehoods: reality is horrible enough.

Give us a moment to lay out our position here. The Reg FOSS desk is not particularly partisan when it comes to Linux distros or their packaging tools. Like most computer techies of a certain age, after a few decades working with all manner of software, this vulture hates it all. All software sucks, as the saying goes.

Linux is software, therefore it sucks. And, as a trivial corollary, all Linux distros suck too. Package managers are also software and also suck, but least most Linux distros have one. This is better than not having one - or, even worse, having more than one, as XKCD 927 beautifully illustrates.

We are not especially pro-Snap, or anti-Flatpak. Your correspondent personally likes the AppImage format, which needs no additional frameworks - but while there is AppImageHub, the format provides no tooling for software updates. That's left up to the app.

Since all software sucks, the only important difference is how badly. After a while, what you care about most is whether it works, does what you need, and is reliable.

Your vulture spent the earlier decades of his career in tech support, fixing other people's software. From this, he learned one attribute that reduces how much a given piece of software sucks is how easy it is to understand how it works.

Btrfs is complicated, and fixing it more so. Git can be really complicated, as its name implies. (Yes, "git" is a word, not an acronym or codename, with an existing meaning.) OStree is Git for binaries, which makes it at least twice as complicated as ordinary Git - and Flatpak is a wrapper around OStree.

This means not one but two additional layers of complexity: first, a wrapper around something complicated only hides complexity, it doesn't eliminate it. Second, you can't build an OS from Flatpaks, so you need OStree as well.

So let's take apart some of the fallacies around the Snap format and tooling. This isn't a how-to guide - it's a quick overview of some of the less obvious stuff about which the haters don't know.

Distributing without the Store

A Snap package is just a squashfs - like the system image on most Linux installation media. Snaps are delivered as two files: the software itself, inside a file called _.snap, and an accompanying assertion file, which is the digital signature for the Snap. Canonical documents how revisions work, too.

It's easy to obtain the basic files using the command snap download rather than snap install:

snap download firefox
Fetching snap "firefox"
Fetching assertions for "firefox"
Install the snap with:
 snap ack firefox_3252.assert
 snap install firefox_3252.snap

Those files can then be copied to another machine and installed, without access to the Snap Store, using the commands in the output.

Igor told us:

Installing without assertions

The snap ack command reads the signature first, but you can bypass that if you want.

snap install "downloaded snap" -dangerous

This will install the Snap without verifying its signature. It does exactly what it says, but with a significant limitation: Snaps installed using -dangerous will not update from the Store.

So, it's possible to distribute Snaps within your network, prevent them from attempting to contact the Store, and manage updates yourself.

Controlling snapd's built-in update mechanism

You can control how and when the OS updates Snaps without ignoring the assertions mechanism, though. Igor has written about how to place Snap updates on hold.

You can hold Snaps for a period of time, indefinitely, or apply this for only specific Snaps, and roll it back easily. For instance:

snap refresh -hold
Auto-refresh of all snaps held indefinitely.

You can also block the Snap API via a firewall, with something like:

sudo iptables -A OUTPUT -d api.snapcraft.io -j DROP

Running snaps without snapd

A .snap file is just a compressed filesystem which contains program files (and libraries and so on) inside a conventional directory tree, which the Snap-packaged application sees as its root directory. Snapd helps set up a mount namespace for that, and adds security confinement via Apparmor and seccomp.

You can extract its contents and run them directly:

unsquashfs firefox_3252.snap 
Parallel unsquashfs: Using 20 processors
565 inodes (5428 blocks) to write
[=====================/] 5428/5428 100%
created 399 files
created 149 directories
created 166 symlinks
created 0 devices
created 0 fifos
created 0 sockets
ll squashfs-root/
total 80
drwxr-xr-x 7 igor igor 4096 lis 10 02:33 ./
drwxr-xr-x 10 igor igor 4096 lis 19 15:32 ../
drwxr-xr-x 5 igor igor 4096 lis 10 02:33 data-dir/
-rw-r-r- 1 igor igor 32441 lis 10 02:33 default256.png
-rw-r-r- 1 igor igor 9146 lis 10 02:33 firefox.desktop
-rwxr-xr-x 1 igor igor 2680 lis 10 02:33 firefox.launcher*
drwxr-xr-x 2 igor igor 4096 lis 10 02:33 gnome-platform/
drwxr-xr-x 4 igor igor 4096 lis 10 02:33 meta/
-rwxr-xr-x 1 igor igor 3716 lis 10 02:33 patch-default-profile.py*
drwxr-xr-x 4 igor igor 4096 lis 10 02:33 snap/
drwxr-xr-x 4 igor igor 4096 sij 19 2022 usr/

If you check the dynamic dependencies for the Firefox binary inside the Snap, you'll see that it wants files from the root filesystem:

ldd usr/lib/firefox/firefox-bin
 linux-vdso.so.1 (0x00007fff33cc5000)
 libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6cf2c00000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6cf2e40000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6cf2be0000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6cf2800000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f6cf300e000)

Inside the Snap, that root is your base (core18 or core20 or whatever). But once you unsquash the Snap, without the security confinement that snapd provides when the Snap is set up and run, then Firefox will try to access the root libraries, and this can lead to inconsistency in execution.

For example, you may have a Snap inside which you have GNOME 3.38 libraries, but your host is running GNOME 3.32. If you unsquash and try to run that app, it may try to load libraries from the host, and this could cause inconsistencies - or worse still, crashes.

To prevent this, the only thing you need to do is set the LD_LIBRARY_PATH environment variable to tell the program where to find its libraries and ensure it uses those first, rather than the OS's copies, which could make it fail to run.

LD_LIBRARY_PATH: ${SNAP_LIBRARY_PATH}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}:$SNAP/usr/lib:$SNAP/usr/lib/x86_64-linux-gnu

In general, you would want LD_LIBRARY_PATH to be: /snap/"snap name"/ first, then /lib, /usr/lib and the other usual paths. As for the other contents, the firefox.launcher file prepares the runtime environment, and the rest, such as firefox.desktop, are for desktop integration: an icon, a full name, file associations and so on. They make it look and work better, but they aren't strictly essential.

It's not even necessary to extract the Snap's contents. You could just mount the Snap file itself as a loopback device - read only, if you like - but without the mount namespace confinement. And without the environment set to tell the application inside the Snap to look for its libraries first inside the Snap, you will still need to set the library path correctly.

Proxying and caching Snap packages

Igor told us that if they don't want to run their own complete, branded Snap Store, customers can manually set up a Snap proxy, if they are so inclined. Again, Canonical has documentation for this, as well as a description of the network access needed.

It's also possible to configure a caching Snap proxy - which is a slightly simpler exercise and might be viable for a home network where you want to reduce the bandwidth of your machines' downloads.

Run your own Snap Store

As we have covered before, you can also ignore all Canonical's infrastructure and just run your own Snap Store. Last year, we wrote about Ubuntu Unity maintainer Rudra Saraswat who did just that, among his many other projects. We've been told that several orgs using Ubuntu Core in production do this, and all the tools are in the Ubuntu repositories.

Canonical publishes quite a lot of documentation on it, including building your first Snap and creating them in different programming languages. This year's summit had several talks on how to build Snaps - including building Snaps on a tablet and automating building updated Snaps, which this vulture attended, though it went rather over his head.

There is a little new terminology to learn, but it's documented as well. We liked this explanation:

• slots are providers (these are resources provided by Snaps)
• plugs are consumers (these use the resources provided by Snaps)
• interfaces are meeting places (these connect plugs with slots)

To summarize the comments from the Canonical representatives El Reg chatted to, they seem more than anything else just irritated by mischaracterizations of the Snap Store and arguments that Snap is a locked-up, closed proprietary system.

Some fifteen years ago, there were claims that Canonical's code hosting and project management platform Launchpad was proprietary, so it cleaned up the codebase and published it in 2009. But, as the folks we talked to put it: "Nobody cared." It's a Canonical in-house tool, and it's simply not much use to anyone else. They told us that they didn't want to go through that again.

We'd also note that Red Hat is going in the opposite direction, and migrating from open source Bugzilla to the closed, cloud-based Jira - without any great scandal.

The code for snapd itself is already on GitHub, as part of Canonical's snapcore repository. The packaging format is an existing, documented one used by most distros. The tools used for confinement are existing third-party ones, already used in other distros. For example, Debian and the SUSE family also use AppArmor, as described in the Arch wiki, while its main rival, SELinux, is more complicated and mainly used in Red Hat and its derivatives.

So, yes, though Canonical's own Snap Store backend remains closed source, the Snap format, the snapcore software, the snapcraft.io frontend, and more components are open. You can host your own Snap Store.

Don't let angry forum posters persuade you otherwise.

And finally...

As it happens, this vulture has worked for both Red Hat and SUSE, but mainly uses Ubuntu, as he has since it first came out in 2004. It works and gets out of his way. However, if only to make updating quicker, he long ago removed snapd and its supporting tools from his main work laptop, and replaced it with deb-get - originally written by Martin Wimpress, the creator of Ubuntu MATE. Your scribe also uses the very shiny Nala package manager instead of Apt, partly because it's a bit quicker.

He rather wishes he could give up all forms of Unix for anything but servers, and use RISC OS or Classic MacOS instead, but they're sadly lacking in the web browser and network connectivity departments - not to mention multi-core support and general stability.

The bill for attending the Ubuntu Summit this year was footed by Canonical, which this hack is happy to disclose. And on that subject of openness: the Linux Foundation also got him to this year's Open Source Summit in Bilbao, and Red Hat took care of his attendance at Flock to Fedora in 2016 in Kraków. This kind of support from vendors lets us spend our ad dosh on other things and never guides our coverage: The Reg always looks forward to biting the hand that feeds IT. ®

https://www.theregister.com//2023/11/10/snap_without_ubuntu_tools/