Linux Snap package

[elcste]

A Snap package for Linux would be a great addition. Better security and integration than installing a deb package or appimage, and Ubuntu — the most popular Linux distro AFAIK — doesn't include/enable FlatPak by default in favor of Snap.

There is an existing third-party Snap package (repo) that works well in my experience. The maintainer is kind of slow at updating it, but gets there eventually. It would be great if this could be adopted upstream!

[danielweck]

Many thanks for opening this discussion, this is much appreciated as I personally (other team members too) need community input regarding Linux usage. I know the basics but I am only an occasional user.

[elcste]

Thank you for including Linux as a supported platform! (I know Electron gets it most of the way there, but still.)

[hajonnes]

I do not know if a Snap package is really the best of ideas.
This is what I have heard about the systems over the years:

The linux community does not really like Snap, Flatpak and appimage.
You might attract bad-will if you release in those formats.
It is because dependencies and a part of the operating system is included in the installation.
Each time you install a program you would have a part of the operating system included so you would end up with programs that would hog your hard drive.
Flatpak is a little different, they can share the operating system files and I think dependencies. That means after the first installation that bundles the os-files your installations will be smaller.

An other problem with these packages is that when a package gets updated because of vulnerabilities they do not get updated in Snap,flatpak, appimage. This makes the system vulnerable. To my knowledge these updates are also one of the reason that maintaining a package is some work. One of the reason why linux systems are considered much safer than windows is because of these package updates and the modularity of the system. If you go for Snap you will keep files that are risky and perhaps end up with problems.

Flatpak tries to mitigate some of these vulnerabilities by making a sandboxed environment. I’m no expert on flatpak but I spent some 2 hours googling to find a way to insert a generic file in an sanbox without problem. E.g. I ran Thorium in bottles (wine fork) that run in flatpak. I could not insert a .epub file in the reader because the strict sandbox implemented. Perhaps it was a settings question or not, but it was not a nice experience.

Perhaps openbuildservice.org might be something, according to wikipedia it makes it easy to create real packages for all the major linux distributions at once.

[elcste]

The linux community does not really like Snap, Flatpak and appimage.

There's no way all Linux users agree with a statement like this. And they already have an appimage, in addition to a deb package, so if it were really true, I guess the damage is already done.

But this is the place for arguing about Linux packages. By suggesting a snap package, I certainly don't mean only a snap package. Having that option doesn't mean you have to use it any more than having a Windows package means you need to install Windows or having a Mac package means you need to go buy a Mac.

[hajonnes]

You are right, I just wanted to state what I have heard over the years to someone that is not so familiar with Linux.
One real problem is that a lot of times software creators tend to use Snap, Appimage and Flatpak as the only a way of distributing the software, not as an alternative which I'm all for.
I think that is why the bad-will has emerged.

[danielweck]

Related:
#1740
#1750

[danielweck]

Generic "thorium" search term:

https://snapcraft.io/store?q=thorium

https://snapscope.popey.com/package/thorium

(note that thorium-reader isn't reserved yet, EDRLab should grab it!)

thorium-reader-snap is the outdated community-contributed package, which is now woefully out of date:

https://snapcraft.io/thorium-reader-snap

Source code:

https://gitlab.com/mtyshibata/thorium-reader-snap

... that's a good template to work from, but I question the --no-sandbox command line argument on the Thorium Desktop Reader executable. This shouldn't be necessary and is essentially an escape hatch that introduces potential security issues.

Furthermore, the thorium executable name conflicts with the web browser app with the same name. We could disambiguate by using thorium-reader instead in the Electron Builder config for the Debian package (and AppImage) but this might break some third-party integration script somewhere that depends on this naming convention.

I also notice that the Snap source is the EDRLab website, probably an alias / redirect, but I think it would be better to use a more canonical GitHub download URL?

I am not sure if updating the source URL when rebuilding the Snap package will cause hash mismatch issues further down the line (I am not familiar with Snap immutability / reversibility)

Also note that Intel (amd64) and ARM (arm64) supported architectures should be revisited, I see discrepancies in the available Snap revisions for this third-party thorium-reader-snap package.

[danielweck]

I would also like to bring up the possibility of a supply chain attack, such as malware distributed via abandoned Snap package:

https://blog.popey.com/2026/01/malware-purveyors-taking-over-published-snap-email-domains/

See for example:

https://snapscope.popey.com/package/thorium-reader-snap

https://snapscope.popey.com/publisher/Bn9FxMgeKxid8aajK96E3kkOGcenhkVS

[danielweck]

https://www.electron.build/snap

[gautierchomel]

• Flatpak: Write a Flatpak manifest (YAML/JSON) describing the build, dependencies, and permissions, then build/test with flatpak-builder and publish to Flathub if desired.
• Snap: Create a snapcraft.yaml defining app command, plugs (file access, network, etc.), and confinement; then build with Snapcraft and push to Snap Store.

[gautierchomel]

openbuildservice.org can help build artifacts for some “app store–style” channels (notably Flatpak bundles), but it does not natively push to the Snap Store or most proprietary stores; that last mile usually requires separate tooling or CI