11 ms·

> 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

by lawl 6y ago

> 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/ https://landlock.io/

d1plo1d 6y ago
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.
- galgalesh 6y ago
  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 https://snapcraft.io/docs/permission-requests
still_grokking 6y ago
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.
- lawl 6y ago
  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?
  - still_grokking 6y ago
    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.
deleted 6y ago
[deleted]
inetknght 6y ago
> 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.
- danielheath 6y ago
  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).
  - catalogia 6y ago
    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.
    - lmm 6y ago
      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.
      - catalogia 6y ago
        Traditionally, distro maintainers do not take this power over users for themselves.
  - 6y ago
m4rtink 6y ago
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...
1_player 6y ago
> 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.
kevincox 6y ago
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.
galgalesh 6y ago
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 https://snapcraft.io/docs/permission-requests
dcow 6y ago
`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.
- lmm 6y ago
  > 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.
  - shock 6y ago
    > 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.
- sergeykish 6y ago
  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

by lawl 6y ago

d1plo1d 6y ago

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.

galgalesh 6y ago
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 https://snapcraft.io/docs/permission-requests

still_grokking 6y ago

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.

lawl 6y ago
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?
- still_grokking 6y ago
  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.

deleted 6y ago

[deleted]

inetknght 6y ago

> 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.

danielheath 6y ago
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).
- catalogia 6y ago
  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.
  - lmm 6y ago
    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.
    - catalogia 6y ago
      Traditionally, distro maintainers do not take this power over users for themselves.
- 6y ago

m4rtink 6y ago

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...

1_player 6y ago

> 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.

kevincox 6y ago

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.

galgalesh 6y ago

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 https://snapcraft.io/docs/permission-requests

dcow 6y ago

`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.

lmm 6y ago
> 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.
- shock 6y ago
  > 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.
sergeykish 6y ago
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