Flatpak 1.2 Likely Coming Around Year's End With New Features

[brrrrttttt]

This turned up on HN front page today: http://flatkill.org/. Apparently flatpak marketing is lies.

[ssokolow]

This turned up on HN front page today: http://flatkill.org/. Apparently flatpak marketing is lies.

Looks like either a smear or propaganda to me.

Here are some reasons that I'm not very impressed by that page:

• The overall feel of the site is that someone wrote one of those single-page "I'll sell you the secret to success" sites using something like Jekyll or asciidoc and left it on the default template.
• The page is conspicuously missing any information on when it was published or updated and who wrote it. (To the point that, if I'm reading the WHOIS information correctly, the flatkill.org domain is one report away from being shut down for the ToS violation of failing to provide valid WHOIS information.)
• It conflates flathub and flatpak.
• It uses dramatic language, with a dearth of details.
• It doesn't provide clarifications or citations for claims like "almost all popular applications on flathub".
• It says "flatpak shows a reassuring "sandbox" icon when installing the app" when flatpak itself has only a CLI or library interface and it's up to each desktop to provide an interface graphical enough to have icons. Given that I can find no such icon on Flathub for any of the packages that are mentioned, and this mention, it's pretty clear that the author is actually referring to a design flaw in GNOME Software Center.
• It doesn't provide any screenshots of the aforementioned problems (eg. where does the "sandbox" icon appear?) and it leaves it up to the reader to determine the meaning of the contents of the one screenshot it does provide.
• The "You are NOT getting security updates" section links to CVEs aplenty, but has no actual citations for the claimed delay in getting the fixes into Flatpak'd applications.
• The author assumes that "This is a minor security update" in the release notes means "We don't consider a setuid vulnerability to be a big deal" which it could just as easily mean something like "This security update didn't change many lines of code" or "This security update poses minimal risk of breaking production systems". (ie. The author assumes the interpretation most favourable to their agenda, rather than either giving the benefit of the doubt or finding further evidence, as is expected of good discourse.)
• The author resorts to childishly writing "Running KDE apps in fakepak?" (emphasis mine)
• In claiming that "fcitx has been broken since flatpak 1.0, never fixed since", the author neglects to mention that the problem was reported to the flatpak developers less than two months ago and the breakage happened because fcitx was relying on a security hole.
• A trustworthy source is more likely to put in the effort to prevent grammatical errors like "rethinked" from slipping into the released page, and to correct them promptly.

[oiaohm]

Why does it even matter how fast official releases are done? It's not like people work or send patches any faster (or slower) just because there's a time-based release.

You have to remember users need official releases that will work. Users really taking from master of git where they might get something half way though a patch series being applied is not really a workable option.

People work or send patches are partly effected by release cycle. Stackleak patches for Linux mainline shows this. Developer modified their patch they now have to wait for a release cycle to get it approved or rejected for include in next release. Why release is when a lot of projects run their final quality control checks. So something that has taken less than 30 mins of work can take 5 years to get included in the Linux kernel all due to the 90 day release effect and minor revisions required to get code to acceptable quality.

So how quick you patch will be reviewed is linked to the release cycle.

You don't want year long release cycles in most cases. 90 days is how long a CVE fault will be kept secret for. So to produce releases to deal with reported CVE faults you have to release roughly every 90 days. This is also to hide defective releases a bit.

90 days is a slow release cycle.
1-90 days is what you release cycle has to be inside. CVE rules set your upper limit. You min is set by how fast you can do quality control and packaging.

Wine development is fairly fast release cycle. Wine cannot go faster than 2 weeks without starting to effect those packaging with burn out. Wine is also at 2 weeks to at least give a tolerable turn around on driver caused breakages in wine.

[oiaohm]

This turned up on HN front page today: http://flatkill.org/. Apparently flatpak marketing is lies.

https://forum.snapcraft.io/t/cant-use-input-method-in-snap-apps/4712

Really site like that not doing proper review. Result is snap has has the fcitx broken for longer. There are equal CVE issues with snapcraft/snap files.

Flatpak marketing is not full of lies. Flatpak has a set of objectives its attempting to get to. They have not got there yet.

There is a downside to having a runtime frozen in time like it or not is increased CVE numbers and increased security exploits.

Something else to be aware of is major distributions get in most cases a 90 days heads up on CVE issues before they are released to public. Flathub has to get to a particular maturity level before it gets that access.

Also this issue with files have old exploits its a problem with appimage as well.

Really brrrrttttt most of that site you could write generic about flatpak, snapcraft, appimage, nixos.....Windows, OS X.

[brrrrttttt]

https://forum.snapcraft.io/t/cant-us...snap-apps/4712

Really site like that not doing proper review. Result is snap has has the fcitx broken for longer. There are equal CVE issues with snapcraft/snap files.

Flatpak marketing is not full of lies. Flatpak has a set of objectives its attempting to get to. They have not got there yet.

There is a downside to having a runtime frozen in time like it or not is increased CVE numbers and increased security exploits.

Something else to be aware of is major distributions get in most cases a 90 days heads up on CVE issues before they are released to public. Flathub has to get to a particular maturity level before it gets that access.

Also this issue with files have old exploits its a problem with appimage as well.

Really brrrrttttt most of that site you could write generic about flatpak, snapcraft, appimage, nixos.....Windows, OS X.

Yup, agree that the site over-sensationalises the findings, which are not at all surprising, because as you basically said, most are general problems for apps distributed with deps bundled. That's one reason I would always prefer a distro packaged release if available. I do agree with the site where they point out that Flatpak claiming sandboxing just because it's technically possible is a little disingenuous, when most (all?) the popular paks don't do it.

[oiaohm]

Yup, agree that the site over-sensationalises the findings, which are not at all surprising, because as you basically said, most are general problems for apps distributed with deps bundled. That's one reason I would always prefer a distro packaged release if available. I do agree with the site where they point out that Flatpak claiming sandboxing just because it's technically possible is a little disingenuous, when most (all?) the popular paks don't do it.

There are quite a few different flatpaks that are properly sandboxed. Problem here is having enough features provided by portals and having the applications modified to use portals.

http://docs.flatpak.org/en/latest/sandbox-permissions.html#

Flatpak has quite decently designed sandboxing. The problem is having applications work.

Over time flatpak can keep on tightening the sandbox.

https://blogs.gnome.org/mclasen/2018...l-experiments/ We are starting to see upstreams looking at using portals as default features.

Basically flatpak had to start talking about sandboxing and asking toolkits and applications what they need to get though the sandbox and work out how to deliver that. Also you have to keep the application developers happy while you are doing it.

So yes the sandbox is currently compromised but its a trade off.

You can think of the flatpak as a chick and egg problem. Flatpak needs a solid sandbox it also needs applications. You cannot test if you have your new sandbox portals right without applications using them.

By the way Flatpak holes in sandbox snapcraft is just as bad. Flatpak has a goal of a solid sandbox but its not there yet.

[Weasel]

You have to remember users need official releases that will work. Users really taking from master of git where they might get something half way though a patch series being applied is not really a workable option.

People work or send patches are partly effected by release cycle. Stackleak patches for Linux mainline shows this. Developer modified their patch they now have to wait for a release cycle to get it approved or rejected for include in next release. Why release is when a lot of projects run their final quality control checks. So something that has taken less than 30 mins of work can take 5 years to get included in the Linux kernel all due to the 90 day release effect and minor revisions required to get code to acceptable quality.

So how quick you patch will be reviewed is linked to the release cycle.

You don't want year long release cycles in most cases. 90 days is how long a CVE fault will be kept secret for. So to produce releases to deal with reported CVE faults you have to release roughly every 90 days. This is also to hide defective releases a bit.

90 days is a slow release cycle.
1-90 days is what you release cycle has to be inside. CVE rules set your upper limit. You min is set by how fast you can do quality control and packaging.

Wine development is fairly fast release cycle. Wine cannot go faster than 2 weeks without starting to effect those packaging with burn out. Wine is also at 2 weeks to at least give a tolerable turn around on driver caused breakages in wine.

You obviously have no idea how the Wine development process works. Even as a user, you can always use the latest git version if you think it's too slow and just want the latest commits.

The only time that the release cycle does impact Wine development is when the major version is bumped (i.e. bumped Wine stable release, not just bugfixes) such as going from 3.x to Wine 4.x. For most contributors it otherwise doesn't matter whatsoever.

[Vistaus]

Sure, but spotify claims that they do snap. So I used snap to have spotify.

Ah, so you claim Flatpak doesn't have Spotify just because Spotify recommends Snap? In that case, why are you on Linux? 'Cause almost every PC manufacturer recommends Windows, so if you only go by claims/recommendations as you said in the Spotify case, you shouldn't even know what Linux is.

[AdamW]

This turned up on HN front page today: http://flatkill.org/. Apparently flatpak marketing is lies.

Not really. Rather, that page starts with a lie:

"It's secure they say ..."

Only, "they" don't. Check out flatpak.org for yourself: nowhere does it make any claims about security. Nor, AFAIK, have Flatpak devs etc. made any claims anywhere else that it's any more secure as a third-party app distribution method than Snap, or plain third-party RPM/DEB packages or tarballs, or anything else.

And that's perfectly intentional: because the Flatpak devs know that, as of yet, it isn't. So they don't say that it is. There aren't any claims that the sandboxing is a security measure, because as of yet, it really isn't.

Other than that, most of what the page says is true, but it's also kinda irrelevant - because it only means Flatpak is about as insecure as every other way third party developers can distribute applications. And no-one has claimed that it's *more* secure.

It's good to be aware that when you install a third-party RPM or DEB or Snap or Flatpak you are allowing that third party to do more or less anything it likes, with root privileges, but framing this as some sort of major problem unique to Flatpak, or claiming that Flatpak says it has solved this, are both wrong.

**EDIT** In the interests of accuracy, after poking into references for this a bit more, I noticed that flatpak.org actually *did* used to make some security claims. Up to about January 2018 the front page had this:

"Flatpak's sandboxing technology prevents exploits and hinders malicious applications."
That text was gone in February. I think one of the discussions around CVE-2017-9780 actually prompted the Flatpak devs to reconsider that text and remove it.

[Weasel]

Not really. Rather, that page starts with a lie:

"It's secure they say ..."

Only, "they" don't. Check out flatpak.org for yourself: nowhere does it make any claims about security. Nor, AFAIK, have Flatpak devs etc. made any claims anywhere else that it's any more secure as a third-party app distribution method than Snap, or plain third-party RPM/DEB packages or tarballs, or anything else.

And that's perfectly intentional: because the Flatpak devs know that, as of yet, it isn't. So they don't say that it is. There aren't any claims that the sandboxing is a security measure, because as of yet, it really isn't.

Other than that, most of what the page says is true, but it's also kinda irrelevant - because it only means Flatpak is about as insecure as every other way third party developers can distribute applications. And no-one has claimed that it's *more* secure.

It's good to be aware that when you install a third-party RPM or DEB or Snap or Flatpak you are allowing that third party to do more or less anything it likes, with root privileges, but framing this as some sort of major problem unique to Flatpak, or claiming that Flatpak says it has solved this, are both wrong.

I couldn't care less about security.

I hope flatpak stays true to its most important goal, which is ABI stability and compatibility rather than some crap like sandbox "security" for totally innocent apps which don't even have internet access (if they do, it's the fault of the user for not setting his PC properly). Don't slow apps down with security please.

Last thing I'd want is for the mobile minimalism hand-holding garbage to come to Linux's only hope for sane application distribution.

If people want security they should SET THEIR PC UP for it themselves which will work with any app, flatpak or not.

That website is so cringy.