Hacker News Reader

Comment by jonquark | Hacker News Reader

I can see why Snap is like it is from Canonial's perspective - but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises

[1] https://flathub.org/home

(Disclaimer: I'm talking in a personal capacity but the company I work for in my day job now owns Red Hat - I don't work on Linux Operating Systems).

View on HN

> but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises

This is interesting, because the last few days I was actually working on packaging an application of mine as a snap/flatpak.

From my PoV, they both have their fair share of issues.

Snaps enforce a sandbox, which I think is actually a good idea, because the desktop security model is somewhat broken. If your application cannot run as a sandboxed app, you need to be granted special permissions by canonical after manual review (my app needs this), where they also discuss if they can make a new permission in a safe way for your usecase that everyone can use afterwards.

On one hand this sucks because I need to ask canonical for permission to publish something, and there's no certainty that I will get these permissions as a nobody for a new app nobody ever heard of before. On the other hand, I think I like that they're doing something about the desktop security model.

The next problem is, if this is denied, how do I ship updates? Provide a self updater? Easy to write, but if everyone does that, we can just go full windows and abandon package managers. Tell people to just curl | bash? That's not more secure than a potentially shady snap.

But I do have to praise canonical for being very helpful in IRC and the forums for helping me debug issues and file bugs against snap stuff.

Now flatpak on the other hand, just feels kinda weird to me.

It sandboxes things, but every application can pretty much grant itself access to everything. This is a completely different philosophy, but if you rely on everyone tightly sandboxing their applications without granting themselves permissions for sandbox escape, I think something like landlock[0] (when it lands) or pledge is much more suited for this, and baked into the application.

Then there is this weird thing where flatpaks force a runtime on you. My application is a statically linked go binary. But flatpaks pretty much want to force me to add an entire freedesktop suite as a dependency, as you simply cannot choose no runtime.

(Community-)Support for building flatpaks? Pretty much non-existant.

So yeah, the entire linux upstream-packaging situation is still quite depressing honestly. And with the time and energy I have invested into this by now, I could have written a simple but sufficient self-updater about 10 times over.

[0]: https://landlock.io/

I'm in a similar boat with regards to launching a new, unknown product in the snap store. As an interim solution I'm planning to ask users to do use the beta flag: `snap install my-app --beta` which gets me around the secure sandbox requirements.

Did you mean devmode instead of beta?

Just wanted to easy one worry of you: the age, popularity and maturity of your application has no influence on whether or not these permission requests are granted. The approval process is formally defined and mostly depends on what your application does exactly.

You can find the specific processes in the docs at the bottom of this page: https://snapcraft.io/docs/permission-requests

As a user I don't like neither Snaps (that for sure as this is Cannonical only) nor FlatPaks (as they seem conceptually a "80% solution" which combines the problems of package systems with the problems of self-contianed apps, but don't improve on anything).

For me the only acceptable solution besides proper .debs are AppImages. AppImage doesn't try to "replace" the package management for desktop apps like the former two candidates. It tries to complement package systems for some special cases (like for example commercial software, or for the cases where the user "just wants to try something out" without "polluting" the whole system with a lot of dependencies).

For my desktop needs AppImage is like "Docker, the good parts". A simple self contained format that runs everywhere without any further dependencies. Compared to that Snap and FlatPak are bloated annoyances.

I tend to agree with you, but I really like updating all my software with one click/command.

So out of curiosity:

My application is already self contained and statically linked, so no AppImage needed, but it behaves like one, you can just run download and run it everywhere. And so what you're describing will be for sure an option for those who like it (in fact currently it's the only option in alpha).

How would you like to get updates for something like this? Visit the website yourself occasionally to check for updates? Have the application notify you a new version is available? Have an integrated updater so the binary can update itself?

That's easy. It should be officially in Debian. ;-)

Stuff like AppImage, static binaries, Docker & Co are for me at least a kind of "last resort". Even I'm using Docker a lot[1] to try things out I first look for an AppImage in those cases. But when I decide that some app should become part of my system I will look for a proper package. One source to rule them all…

[1] Docker is a big problem on it's own. But as I can't avoid to have it installed because of work I decided I could use it at least to "keep experiments under control". Before I was forced to have Docker I've used systemd-nspawn for that use-case.

Debian has a lot of rules, some of which prevent statically linked binaries, like Go programs, from being packaged and shipped with it. A notable example is lxd.

Appimages are great but there's no sandboxing or updates. But hey, we used to downlad debs and install them by hand on Debian 1.3, before apt was a thing. Maybe appimages could be signed and distributed in a similar fashion.

> prevent statically linked binaries, like Go programs

What do you mean? There's debian go packaging team: https://go-team.pages.debian.net/ as well as go packages in stable (for example https://packages.debian.org/buster/influxdb)

"Appimages are great but there's no sandboxing or updates"

Actually there is sandboxing and updates, if you want to take an extra steps.

I prefer AppImages over Flatpack and Snaps for essentially the same reasons commented above.

I typically launch them with Firejail for the sandboxing. i.e. "firejail --appimage /path/to/appimage" instead of just the appimage alone. Seems to work just fine. Firejail has additional options that can be done.

Some AppImage creators do provide an update method that can be installed using zsync2, but I've not tried it since the whole point is disposability.

Go programs are not (generally speaking) statically linked, unless you're explicitly doing CGO_ENABLED=0, -tags 'netgo' and the whole variety of other tricks needed to coax static binaries out of the compiler. Try running "ldd" or "file" on your Go binaries -- most of the time they'll be dynamic objects and linked to glibc, especially if you're just doing a stock "go build".

In addition, Debian definitely does package Go programs -- they've packaged some of mine and they have possibly the most ambitious way of solving the great vendor/ issue (which most other distributions have ignored).

The likely issue with LXD is that they require specific versions of various system libraries that they package in their source code bundles (including a fork of sqlite3!). I packaged LXD for openSUSE[1]. It wasn't really fun, but it is fairly doable if you have a flexible enough view on "good packaging practices" (and I imagine Debian packagers didn't feel like going through all the necessary workarounds -- which includes patching the ELF binary in the openSUSE case). And note that LXD isn't even a static binary -- I tried to compile it statically to get around a whole range of issues and it was a nightmare.

[1]: https://build.opensuse.org/package/show/Virtualization:conta...

> Appimages are great but there's no sandboxing or updates.

I know nothing about AppImages, but up above someone said they do have updates: https://news.ycombinator.com/item?id=23773878

Go also supports dynamic linking actually.

Unfortunately even micro releases of the Go compiler break ABI, so Go dynamic linking isn't feasible for distros to use:

https://wiki.debian.org/StaticLinking#Go

There are two types of "static linking" being discussed:

  * Linking with system libraries (what GP mentioned).
  * Linking with Go packages (what you're talking about).

Yes, Go doesn't really support -buildmode=shared anymore (and it was pretty broken from the outset). But this is a separate question to whether a Go binary is actually a static object. In most cases (and by default), Go binaries are dynamically linked to system libraries (with Go packages being statically linked into the program).

pjmlp's comment seemed to be about Go packages to me, not system libraries.

The original comment[1] spoke about "statically linked binaries" which has a pretty specific meaning ("file" says its a static binary). There are similar issues for Debian packaging if you had a hypothetical language which required you to vendor your dependencies because maintenance for security issues would be annoying (Debian worked around this problem in Go through "de-vendoring" and Go modules -- in theory -- mostly solve this issue today). But static binaries are generally not distributed in distributions because they make make core library updates worse in terms of download size as well as inflating memory usage due to lack of page-cache sharing.

[1]: https://news.ycombinator.com/item?id=23773480

Where can I find an up to date guide on how to package software for Debian and what to do to get it included in the repository?

I’ve often came across orphaned packages where Debian was stuck with an old version, but didn’t know what to do about it other than installing from source. Or using a PPA if I was lucky.

For the first part, I found Debian’s Maintainers’ Guide [0] pretty helpful when I was updating xscreensaver last year (hasn’t been uploaded yet though...). It also has a section at the beginning concerning how to adopt orphaned packages. For upstream updates, some projects will have a way to create deb packages themselves, which can make installation/updates easier later on (concrete example, with OpenZFS can create RPMs and debs from the upstream tree).

0: https://www.debian.org/doc/manuals/debmake-doc/index.en.html

Personally, I rarely think about updating my software unless there's a new feature I need or a fix for a bug that's been ruining my life, so just visiting the website when to check for new versions is fine by me.

However, you could also include a facility to manually check for updates and either self-update or just show the changelog. Why manually? "I know you're about to do this thing real quick that needs to get done, but a new version is available! Would you like to twiddle your thumbs for 5 minutes while watching a progress bar?".

> Why manually? "I know you're about to do this thing real quick that needs to get done, but a new version is available! Would you like to twiddle your thumbs for 5 minutes while watching a progress bar?".

That's a very Windows-centric point of view. Programs on Linux can be updated without closing them. You get the new version when you restart them.

Firefox has entered the chat

Chocolaty GUI for Redmond.

sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove -y && echo 'All done!, rebooting' && sudo reboot now

For everything else.

It only works if they are self contained without access additional resources on the file system, as the executable file is kept alive until process termination.

Now if the process tries to access some datafiles that changed contents during the upgrade, it might just crash and burn, eventually corrupting data in the process.

Ideally security updates aren't deferred for 5 years because its working well enough and happen for the whole system when you aren't using the machine as opposed to just for that app when you launch it.

most AppImages seem to auto-update themselves when you run them, which is convenient, until it isn't.

I'd want it in an apt repo, really.

That actually sounds pretty dangerous - what is more likely to get compromised and stay that for a long time - a random developpers app image update service or distro infrastructure ?

> How would you like to get updates for something like this? Visit the website yourself occasionally to check for updates? Have the application notify you a new version is available? Have an integrated updater so the binary can update itself?

I've seen all three approaches with AppImage'd software.

There are also package managers specifically for AppImage'd software, though it doesn't look like any of 'em are particularly mature.

Plenty of software companies provide their own Apt repositories. Adding a repository is usually as simple as copying a single file to /etc/apt/sources.list.d/. Sometimes you may also need to add a GPG key, which can also be as simple as copying a file to /etc/apt/trusted.gpg.d/ (though most instructions seem to favor a manual one-liner that imports the key to the global database[1]). Technically you could automate both with a one-time deb install, though I'm not aware of anybody that actually does this. In any event, after that `apt-get upgrade` will upgrade third-party packages just as well as Debian or Ubuntu packages.

I much prefer Debian packages over RPM, and Apt over Yum/DNF, but unfortunately setting up a Debian package repository is more difficult than for RPM. The tools exist, and are more sophisticated and capable--for example, Aptly--but there's a higher learning curve. Also, good luck using them outside Linux. Years ago I published Debian package repositories from OpenBSD, but I had to manually hack the relevant tools to build and work on OpenBSD. For RPM/Yum I could have more easily written (and at a different job later did) an indexing tool from scratch.

The problem with Debian packages and Apt repositories isn't that they're not capable, it's that they have high learning curves due to the slow accretion of features that obscure their potential. A better tooling story would help, particularly for repositories. Better tools for initializing Debian package builds exist; the problem is more a surfeit of choices.

[1] It's more complicated and creates unnecessary headaches than dropping a file into trusted.gpgp.d, but the practice seems to reflect the opacity of the Debian packaging ecosystem. There's a better, simpler way to do it, but everybody cargo cults the same old solutions and then complains that it's too complex or inelegant.

Appimage has its own issues though: - no update mechanism - no sandboxing and only basic app isolation - no deduplication (Flatpak automatically deduplicates everything it installs on a machine)

AppImages do have an update mechanism:

https://docs.appimage.org/packaging-guide/optional/updates.h...

Interesting! That must be something relatively new, as it at least looked like there was nothing back then when I looked up Appimage.

AppImage seems like the best replacement then. I've loathed Snap since it first appeared on my horizon and I installed LibreOffice with it and that snap image showed up in my mounted drives forever. I was a big fan of Canonical/Ubuntu for years and switching to Debian has not been without pain points but at least I have more control of my computer. Pop! OS and Linux Mint seem like good Linux desktop alternatives to Ubuntu at this point if you don't want to use Debian.

> Linux Mint seem like good Linux desktop alternatives to Ubuntu at this point if you don't want to use Debian.

Mint also has Debian based distro.

On the sandboxing front, it works great with Firejail: https://firejail.wordpress.com/documentation-2/appimage-supp...

FlatPack was made to address two things focused on security:

1) Application won't need root privileges

2) Without compromising on the systems security

Some kernels, e.g. Linux, were also made to do just (that amoung other things).

I think fixing what we have in standard kernel/userland, and leaving the containers for specialized developer/devops deployed workloads may well be where this (what will be known as the snap/flatpack saga) started from, and will end as well.

Is "I just give you a tgz with small folder of files, one of which is a binary; I managed to make it run just about everywhere" worse than AppImage (notably, for a GUI app)?

That's basically what an AppImage is, except that an AppImage goes one step further and slaps that tarball onto an executable that opens its embedded tarball and runs whatever's inside.

AppImage is the format I'm using for distributing Linux apps as well, for many of the reasons you mention

AppImages are the only thing I run also, as a full time linux user and admin. I just hate the proliferation of questionable services, especially in systemd land. A lot of my focus is on minimization of stack, and snap and flatpak just don't stand up to scrutiny imho.

I also prefer appimages as the "least worst" of the three.

However, a quick note: As someone who unofficially maintains a linux port of my companies software, I have considered packaging it as an appimage, but there's one problem with appimages that kills the concept.

Appimages are read-only[1]. I'd love to package my companies product that way, but we already have update-delivery infrastructure that works on windows and mac (and linux), and it assumes it can write to the "install folder". Changing the entire update infrastructure specifically for an OS we don't officially support is a non-starter.

From a developer perspective, I would love the ability to update an appimage's contents in place. However, as a user I'd also like the ability to set it read-only to block updates if I desire. Flatpak's mandatory updates are one of the key reasons I dislike it. Never the less, if the goal is to smooth the path for proprietary software to support linux without making half a dozen different packaging solutions, in place updates need to be supported.

[1] edit: according to comments below, they now have an update mechanism, but it's still a totally appimage-specific process, so my problem remains :/

> The next problem is ... how do I ship updates?

...why not make a new release and ship that? That's the way package managers work. Developer makes a package. User installs the package. Then when developer fixes some bug and releases a new version the user can install the new version when the user decides it's necessary.

The whole point about this is that it's user-centric. That's good.

It’s largely a good thing but it’s unreasonable not to mention the “flood of bug reports about issues that have since been fixed” effect that comes with manual updates.

This has burnt a few projects pretty badly (especially where distros have packaged an old version and never updated it).

Taking power away from users to address that inconvenience may be the status quo in the proprietary software industry, but it's totally over the line for user-respecting FOSS software. Not least because, once a developer acquires that power over users they very frequently succumb to the temptation to abuse their userbase as involuntary beta testers for half-baked bullshit which users struggle to opt-out of.

Taking power away from the users and putting it in the hands of upstream maintainers is pretty bad, but putting it in the hands of distro maintainers is even worse in my experience. Upstream maintainers are at least the people who develop the software directly and deal with the bug reports.

Traditionally, distro maintainers do not take this power over users for themselves.

Make the user report their current version in the reporting dialog. Automatically close all reports for prior versions and inform the user to update and revisit.

Flatpaks deduplicate everything - all flatpak apps and all flatpak runtimes installed on a machine agains each other. So if you specify the basic freedesktop.org runtime, it is effectively a no-op as pretty much everyone will have it already installed, due to most of the other runtimes being based on it and most flatpak apps needing a runtime.

As for sandboxing with Flatpal - AFAIK this is all intentional for the time being. The authors have ckearly statet their initial effort targets app dependency isolation and app portability, not security just now. That is much harder to do without severely limitting useful applications in what they can do.

I have encountered incomplete sandboxing systems that strived for security in past and it has not been a good experience.

For example I had the onr and only official Ubuntu Touch tablet, which used a predecessor of the Snap technology. One day I wanted to show my friends a couple photos from a micro SD card. I put it in to the tablet, bit no photo viewing app could show photos from the card.

Why ? Because back then you could only open files from outside of the apps sandbox one by one using a special system controlled dialog. Not really usable for hundreds of photos and forget about a text editor or an IDE.

This is where I like Flatpak - it gives you all the goodies of app separation and portability without all the hassle of a strict but unfinished secure sandbox. You only need to make sure you are getting the software from thrusted sources.

A I think that's something one should be doiny anyway, even with a strct sandbox - if it can't support basic app use cases, who knows what security holes have the authors left in it...

> Then there is this weird thing where flatpaks force a runtime on you. My application is a statically linked go binary. But flatpaks pretty much want to force me to add an entire freedesktop suite as a dependency, as you simply cannot choose no runtime.

That's a weird criticism to have of Flatpak. The FreeDesktop dependency is the base set of libraries all flatpaks have access to. You don't have to use it. In fact Freedesktop is a great idea, to provide a base framework applications can use that goes further than just libc. If we want Linux on the desktop, we need a common desktop framework interface.

It would be like being unhappy a static go binary on Windows COULD access all of the win32 libraries.

Also, Flatpak currently is best suited to GUI apps. If your go binary is a GUI app using either GTK or KDE, these will need the freedesktop facilities (such as D-Bus) to actually run properly.

For sandboxing the user is supposed to decide if they will give you access to the permissions that you requested. Now in practice most FlatPak apps don't use sandboxing but hopefully that will change and permissions are treated with scrutiny.

In case this eases your worries: the approval process for permissions is formalised and does not depend on how mature or well-known the app is.

In addition: users always have the option to override permissions. The approval process is for automatic (default) permission grants. Even if these are not granted, users can grant them manually.

The specific processes for approval are listed at the bottom of this page: https://snapcraft.io/docs/permission-requests

`curl | bash` gets a bad wrap. From a security perspective (assuming you trust web pki), it's 100% no different than a) downloading and running a script, b) downloading a package and and installing it, c) downloading a binary blob and executing it, etc. I actually find that piping an install script to an interpreter is the easiest to audit of all the options because I can see exactly the changes that will be made to my system. I don't know where the whole "zomg pipe to bash is so insecure" vibe came from, but it's effectively developer urban myth. The only improvement is if you somehow directly exchange keys with the vendor out of band with no web pki intermediate step and then verify the signature on the software you're installing... yeah.

> The only improvement is if you somehow directly exchange keys with the vendor out of band with no web pki intermediate step and then verify the signature on the software you're installing... yeah.

Which is what Apt has done for 20+ years - packages are gpg-signed, developers sign with their individual keys (and have to have their identity verified by at least one other developer) and even someone who controls a root CA (which is most national governments and many large corporations, let's be fair) would have to mount a dedicated attack to subvert that process.

> Which is what Apt has done for 20+ years - packages are gpg-signed, developers sign with their individual keys

AFAICT,debian packages themselves are not signed, just the repository release files are gpg-signed.

You fail to see how piping to bash worse than other awful choices? It is not.

It is bashed by those who value reproduction and discoverability:

* every person receives same script, confirmed by signature

* multiple mirrors, no single point of failure, no pull out by author (left-pad)

* no silent update (browser addons)

* tested to work on your system

* clean remove of installed files

* search in packages not in web (anti fishing)

* hosted in secure environment

* watched by many eyes

I feel like both Snappy and FlatPak are inferior to AppImage, which IMO is much easier to use (it's a self-contained executable) and doesn't rely on any fancy management daemons or what have you.

Like, in terms of user experience it's about as close to the Windows-style "download this .exe and run it" approach as one could get, though it'd be interesting to see a macOS-style "put this .app in your ~/Applications" approach as well (which should be doable with a daemon watching such a folder and generating e.g. menu entries and such, as an optional component or perhaps a feature of the desktop environment itself).

> the company I work for in my day job now owns Red Hat

That's the longest spelling I've ever seen for a three-letter company.

I assume then that you don't speak German?

Every attempt at "solving" this "problem", including Snap, Flatpak, and AppImage, are an absolutely awful regression in the state of Linux. I absolutely hate this trend. These tools solve problems for only two kinds of software: proprietary software, and software with suck reckless, runaway complexity that it can only run in one specific environment. I have no interest in either kind and I will give no quarter to "solutions" for their "problems".

Criticism specifically regarding Flatpak: https://flatkill.org/

I mostly agree with you and I'm not going to get even near Snaps and Flatpaks.

However, ignoring the aspect of software distribution, wouldn't you agree that the approach taken by the Linux desktop today is deficient security-wise? For example, I would like to be able to give mbsync (or Thunderbird or whatever) my IMAP password without giving it to any other program. So I don't want to store it in mbsync's config file in plain text. Neither will I use gnome-keyring (or any other keyring) because it doesn't have any kind of "program authorisation". Any program can just spawn a new "secret-tool" process and get my credentials from gnome-keyring.

I've been thinking for a while about implementing a keyring which runs as a daemon with SUID of a dedicated user and checks which program sends requests to it, using /proc/pid/exe, but I'm not sure if it's a secure source of truth: how e.g. namespaces affect what's visible in /proc/pid/exe. I know you've been developing himitsu[1]. Have you thought about this problem in that context?

[1]: https://git.sr.ht/~sircmpwn/himitsu

I agree with you, but the solution would have been Plan 9 namespaces, not Linux containers. What we're working towards today is awful.

flatkill.org is clickbait, not written in good faith, and doesn't propose any solution. Moreover things like "it's obvious Red Hat developers working on flatpak do not care about security" is just unnecessary and toxic.

Issues mentioned on flatkill are already fixed, will be fixed or doesn't depend on flatpak itself (like the UI / icon in the software app store).

I don't like Flatpak either but I think we should elevate the debate to deeper architectural issues of flatpak that won't be fixed easily. Personally, I do not like the following in Flatpak :

- no effort on full reproducibility like Nix&Guix

- a big fat flat runtime rather than traditional fine grained dependencies (although OStree avoids duplication, but still very elegant)

- you can't install extra pkg in the sandbox. So the quite overkill solution in RedHat's vision is to separate between Toolbox/Podman for devs vs Flatpak for users, rather than trying to make a single unified sandbox for everything. Of course everything breaks down when you try to code using a Flatpaked IDE, if you follow RedHat's vision you basically need to spawn a toolbox container from an unsandboxed flatpak instance of your IDE : https://github.com/flathub/com.visualstudio.code/issues/44

So personally, I'm still waiting for a packaging system that is :

- compatible with the idea of a declarative/immutable os (like nix, guix, silverblue)

- tries to make everything reproducible (like guix)

- sandboxed with runtime permission API (like Flatpak portals, IOS, Android)

- sandbox can be augmented with packages so that you can code in your sandboxed IDE + add necessary dev packages inside a same sandbox without having to break it

Reply on news.ycombinator.com