Flatpak 1.0 Nears With Today's 0.99.1 Release

[M@yeulC]

inb4 people start saying how flatpak, snap, AppImage or whatever are "useless" and should just use distro packages "without the bloat". Because building 1 single application for 10 Ubuntu versions, 10 Fedora versions, and so on, is a perfectly sane thing we have going on without flatpak.

The normal userland design is just broken and rotten at the core. I may not like flatpak's sandboxing, but it's really the only solution right now, unfortunately. Don't hate it for trying to fix something rotten, even if it isn't ideal. (ideal would be stable libraries, like on Windows, then you won't need flatpak or bloat)

Really, oiaohm's answer is quite good. I would just like to add my point of view on this:

• The current system is perfect for open source software, the one that is compiled, packaged and maintained by your distribution. To a lesser extent, it also applies to software you compile yourself.
• The real problem only arises when you try either:
  • To run a proprietary or unmaintained app on a recent system
  • To run a recent app on a legacy system.

The simple answer in case of the latter case is to upgrade. You should really do it and come back when you just want to run your legacy apps on an updated system (together with the recent app), but I agree that this is not always easy or possible.

Luckily, snap, flatpack, appimage and the various container solution solve both issues. I would then advise to use it only when a software is not available from your distribution, and unmaintained or proprietary, or if you want some clean "sandboxing" (clean uninstall).

THE major issue with self-containing every dependency, is that you end up using old libraries, that no longer play nice with modern systems: have a look at the ut2004 port: no easy alt-tab, uses OSS for sound, outdated SDL for input, etc. You can also have security issues. And this is the reason why I prefer the Linux approach, where you always only have the latest and greatest libraries. This works well for 99% of the software, so I believe that calling its design "broken and rotten at core" is something I very strongly disagree about.
When you have a broken (with regards to this paradigm, of course) app such as a proprietary app, then you have those various solutions, that work admirably well for the use case.

Nix is also an awesome concept if you really have to use some complex and incompatible dependencies; try it (I yet have to)! It also works from userspace, or on the NixOS distro. One case where such problems might arise with up-to-date dependencies is if two different projects use two incompatible forks of the same library. Nix looks like the traditional package management approach, without the issues.

Now, to disagree on something else: Bloat. Windows *is* bloated, as its solution to dependencies is SxS, as oiaohm wrote (windows keeps a copy of every dll it encounters, if you want).

[woprandi]

Please note providing multi libraries particular old libraries like Windows does has a security price. This is one of the factors that makes windows easier to find exploits.

But with flatpak, it's sandboxed. Not on windows

[starshipeleven]

The current system is perfect for open source software, the one that is compiled, packaged and maintained by your distribution.

Which sounds very cool in theory but in practice we have already seen that it can become a clusterfuck very quickly, as distro maintainers don't always do a decent job at shipping sane configurations and keeping the application up-to-date to fix bugs long fixed upstream.

Ubuntu is notorious for this on KDE, shipped broken PulseAudio for a long while, and so on and so forth.

So there is plenty of reasons to want a system that can sidestep the need for maintainers.

[oiaohm]

But with flatpak, it's sandboxed. Not on windows

That in fact wrong. https://en.wikipedia.org/wiki/Window...rce_Protection There is a sandbox inside windows designed to protect the core of the OS from applications and even the administrator this is Windows Resource Protection. Flatpak has sandbox also design to allow user to apply more control over applications.

Both applications windows and flatpak applications are sandboxed to different levels.

[Weasel]

Stable libraries really don't exist on windows.
http://test.winehq.org/data/9ef8fa2a...ndex_Win8.html
Wine project running tests has see that the idea of stable libraries and windows is kind of false. Wine works out what the average functionality of windows libraries is and implements that.

Weasel there are formal tools to give you ABI changes rates.

https://lvc.github.io/abi-compliance-checker/

This gives you reports like the following
https://abi-laboratory.pro/index.php...eline&l=ffmpeg

If you perform the proper tests on Windows you will find its ABI breakage numbers are higher than Linux Distributions.

Obviously Wine doesn't implement the full API properly, dunno what your point is.

And for ABI breakage, like what? msvcrt does not count mostly, since it's compiler-specific anyway by default and you have to go through hoops to use it on GCC (MinGW) or whatever (except the original msvcrt.dll, I mean the C++ ones).

LOL not true at all. Please stop random presuming crap. If you were running ABI tests you would notice that Microsoft Com object regularly lose features more often than not. Does not cause issues due to program error handling.

WTF? Do you guys even know what an ABI breakage is? It's not "unimplemented feature". That's a DOCUMENTED way for an application to handle it, like you said, with "error handling". There's nothing wrong with that, if it's in the spec, because a proper application will handle errors gracefully.

ABI break is when something changes than an app has no idea of (at the time it is written) and likely results in stack crash or missing functions altogether (missing at load time, so it gives hard error before the app even launches -- NOT a runtime function that MAY OR MAY NOT exist according to documentation, the latter is NOT an ABI break since an app WILL be designed to handle it "missing").

Windows updates ABI breakage about 1 in 5 updates do a ABI break. So Windows ABI is technically half as stable as Linux Distribution ABI.

Tell me 1 break of a major library. Because you or starshipeleven never give examples.

Clearly, something is off here, your definition of ABI break is definitely not the same as the actual definition (which leads to applications either refusing to start by the loader itself, or a stack corruption/crash).

Also see for WinSxS: https://blogs.technet.microsoft.com/...deal-with-vss/

Name me 1 major Windows DLL that broke API/ABI. You know, those DLLs documented in MSDN. Like kernel32.dll, user32.dll, and so on, not compiler-specific libraries. It may have a slightly different effect with same flags, but that is very rare, and usually should not impact an application that's written properly and doesn't rely on a gimmick.

Note that the Linux kernel does similar thing here, for example, some things have even been removed in functionality completely but the API respects its contract to an outside application (except that it obviously doesn't provide any gains anymore). For example, like the non-linear page mapping, which was deprecated, it still exists and applications using it will still see the same results -- but it won't be performant anymore (it's as if they did it "manually" which is inefficient and uses more memory). Nevertheless this is not an ABI break.

Please note providing multi libraries particular old libraries like Windows does has a security price. This is one of the factors that makes windows easier to find exploits.

Bullshit!

A library has no extra privilege compared to the application that uses it. So it cannot do what the application cannot do. A security exploit in the application itself would be the same thing.

And if you hate that exploit for being there, then don't use the library or the "legacy" APIs in it? Really not so difficult. If the library merely exists or its legacy APIs exist, it does NOT cause a security problem until it is used. But if it's used, then without them it wouldn't work at all.

What's better: an application that refuses to load, or the same application with a vulnerability? Pretty sure the latter, because the latter at least gives YOU the choice to... not use it. The former gives people NO choice to ever run that application even if they don't give a shit about the vulnerability!

It's not like on Linux where, say, a compromised X or Wayland server (buffer overflow etc) would compromise the entire system, because it runs as a different process/user.



I know you're going to say something silly such as "but if the application that doesn't use those legacy APIs gets compromised and starts using them, then see, it's an exploit".

Let me ask you something, why would the attacker bother loading the legacy API after compromising your "modern" application not using them, instead of taking over the application directly since it was compromised anyway???

Libraries are not processes, like services or servers. And unused functions are not a security vulnerability in the slightest for merely existing there. "Used" vulnerable functions are, however, way more valuable than "used" non-existing functions. If you disagree then turn off your PC, clearly not running code at all is more important than running vulnerable code. (and yes, nobody says you have to use the vulnerable code in the first place, if you don't use it, the libraries are NOT a liability, if they're not used, they won't even get into RAM usage, since the libraries are memory mapped and untouched pages are not allocated.)

[Weasel]

• The current system is perfect for open source software, the one that is compiled, packaged and maintained by your distribution. To a lesser extent, it also applies to software you compile yourself.
• The real problem only arises when you try either:
  • To run a proprietary or unmaintained app on a recent system
  • To run a recent app on a legacy system.

The simple answer in case of the latter case is to upgrade. You should really do it and come back when you just want to run your legacy apps on an updated system (together with the recent app), but I agree that this is not always easy or possible.

I completely disagree.

But I guess you're happy using just what your distro decides to package for you, which is an extreme minority of apps. I mean there's many "PPAs" out there for Ubuntu, and that's just the tip of the iceberg. (and yes, the maintainer of the PPA hates the fact he has to compile so many fucking versions of the same application, even on one architecture, ffs).

If you consider the tiny amount of Linux applications compared to Windows, what do you think will happen when the huge Windows ecosystem gets "ported" to Linux in the imaginary event that Linux dominates the desktop? All hell will break loose, the current system is unmaintainable and garbage. You can barely maintain apps in the sorry state it's currently in (2%).

Look at Ubuntu maintainers, they bitch about "dropping" packages all the time, even without including all the PPA-only software out there, they still think there's too much, because it's just a retarded way of distribution. I have no sympathy for them though, they're the ones who relied on this piece of shit way of distributing and breaking stuff on every distro version in the first place, when their first priority should have been a stable userland for *all* of Ubuntu (like they just now start with snaps).

It's by no means "perfect" for open source software, sorry.

I don't know about you but I *really* don't like depending on people to build software I write, lest I get people requesting I build for their stupid distro. Which is why I rarely make stuff for Linux in the first place. And I'm not alone, even Linus with Subsurface gave a speech quite awhile ago and mentioned it the same way I did (in an even more insulting way).

I do *use* Linux, but I prefer to write Windows apps that I test to work under Wine just fine (so it's "first-class support", so to speak). Yes, writing Windows apps to run them on Linux is a better experience than writing Linux apps directly. Look at the VK9 and DXVK devs, they do the same thing. Guess why that is?

[starshipeleven]

Tell me 1 break of a major library. Because you or starshipeleven never give examples.

I can't as I never debugged custromer's software when it breaks. I'm not their developer. I'm not even a professional developer at all.

What I just refute is the notion that Windows applications never break because Windows API never changes. Facts prove that it's false. Applications and drivers break sometimes when you update Windows. It's not a 100% thing, but it does happen often enough that I can't really ignore it.

For example it's been 3 months now that Outlook 2013's search function intermittently breaks and works again, they broke it around e months ago, then it worked again after some more OS updates, then less than a month ago it broke again. And I talk of OS updates, not application updates.

A library has no extra privilege compared to the application that uses it. So it cannot do what the application cannot do. A security exploit in the application itself would be the same thing.

He meant probably that if you keep libraries with unsafe functions around you let applications become exploitable through that.

And if you hate that exploit for being there, then don't use the library or the "legacy" APIs in it? Really not so difficult.

There is no better way to convince lazy bummers to upgrade their software than dropping support for their functions.

What's better: an application that refuses to load, or the same application with a vulnerability? Pretty sure the former, because the latter at least gives YOU the choice to... not use it. The former gives people NO choice to ever run that application even if they don't give a shit about the vulnerability!

The issue here is that given the choice none would give a shit about the vulnerability, due to either ignorance or stupidity.

That's the same thing with safety on the workplace, laws were put in place because otherwise none would use safety boots or follow some specific (safe) procedure.

It's not like on Linux where, say, a compromised X or Wayland server (buffer overflow etc) would compromise the entire system, because it runs as a different process/user.

Nice how you have chosen Linux here instead of using some other Windows system component.

Also very nice how you are posting bullshit about both Xorg and Wayland, as both xorg and wayland compositors can be run as a user too, it's not required to run them as root (Unless you use NVIDIA drivers anyway, but that's because they can't just update their drivers to be nice).

And at least xorg isn't usually run as root in distros now (I don't know about wayland compositors as I don't use wayland yet).

https://wiki.gentoo.org/wiki/Non_root_Xorg

https://blog.martin-graesslin.com/blog/2014/10/libinput-integration-in-kwinwayland/

[Weasel]

I can't as I never debugged custromer's software when it breaks. I'm not their developer. I'm not even a professional developer at all.

What I just refute is the notion that Windows applications never break because Windows API never changes. Facts prove that it's false. Applications and drivers break sometimes when you update Windows. It's not a 100% thing, but it does happen often enough that I can't really ignore it.

For example it's been 3 months now that Outlook 2013's search function intermittently breaks and works again, they broke it around e months ago, then it worked again after some more OS updates, then less than a month ago it broke again. And I talk of OS updates, not application updates.

That's not what I asked for, though.

Have you ever considered the possibility that the application just has bugs? Seriously. It doesn't mean the API broke. It means the application has bugs in how it interacts with the API (i.e. improperly).

What I asked for, though, wasn't a specific application that broke. I was asking which API "broke" in a major way (there are few changes in behavior of APIs though, like GetTempPath, but they're minor and usually only in extreme corner-cases, such as when you reach MAX_PATH).

He meant probably that if you keep libraries with unsafe functions around you let applications become exploitable through that.

Yeah but only if the application uses that library. So the alternative is that such application does not launch at all. Which is way worse.

If a library is not used, it doesn't even get loaded. Heck, even a function that is not used or imported does not get loaded, since the library is mapped in memory, so only used pages get allocated. (of course excluding those functions that fit in an other 4k page, but that space would be wasted anyway).

So it cannot "compromise" the application unless the application uses that library. But if it *does* use it, then if the library did not exist (or the legacy APIs), it would *not launch* at all. That's objectively worse for the simple fact that you *can* already just not run the app, even with the library there, and be just as safe as it refusing to launch.

There is no better way to convince lazy bummers to upgrade their software than dropping support for their functions.

People should be free to use what they want to. You disagreed on other thread about my idea of forcing people to unify their APIs on Linux.

Yet you encourage forcing people here to drop their use of X API just because you don't like it? i.e. you want to "dictate" what APIs should be used etc. Clearly, they don't care about the vulnerability, so it's their choice. After all, if the app gets hijacked because of the library, it's the application who is vulnerable (literally, even technically, its process space is hijacked), just as if itself had bad code. It doesn't gain any extra privileges.

Anyway, you're aware you can hide the API from the SDK and headers right? Literally just don't expose it anymore. That should be more than enough encouragement. Or even use "deprecated" attributes (standard in C++) on them so they give fat warnings when compiling.

Nice how you have chosen Linux here instead of using some other Windows system component.

I tried to use a familiar example to Linux folks. I did not intend to imply that Linux is less secure in this aspect, but now that I re-read how I phrased it, I can see your confusion. Sorry for that.

Also it doesn't matter if it runs as root or not. X will still run with more privilege than the unprivileged user (in this case) so it can wreck your files in theory. Suppose you have an unsafe user with almost no privilege and which hijacks X or Wayland (assuming he has access to them, let's say you need graphics), which runs under starshipeleven. Then your files are compromised despite the fact that the "unsafe" user has no access to them!

[starshipeleven]

That's not what I asked for, though.

Sorry to disappoint you, I'm sure the other guy will answer that.

Have you ever considered the possibility that the application just has bugs? Seriously. It doesn't mean the API broke. It means the application has bugs in how it interacts with the API (i.e. improperly).

Let's examine the situation. The application is running fine, then some OS update happens, the API is still stable as per your thesis, but the application breaks.
Wtf broke the application if it didn't change (wasn't updated) and we postulate that the OS API didn't change?

Bad spirits possessed the PC? Do I need to perform an exorcism?

Yeah but only if the application uses that library. So the alternative is that such application does not launch at all. Which is way worse.

Way worse for who? The lazy application developer perhaps. (he can ship the older version of the library and be fine though, Windows allows that, and it is also a thing)

For the library developer it's much better as he avoids potential liability issues, and reduces wasted time on what is a lost cause, which means that the rest of the library receives more attention.

Seriously, you are a web developer masquerading as something more serious. Your approach of "fuck security", "fuck library developers breaking my program", "fuck everyone that isn't bending backwards and giving me a blowjob for free" is common in their ranks.

If a library is not used, it doesn't even get loaded.

Completely irrelevant, the issue here is applications using that library that don't like to update their codebase, and won't do so unless forced to.

People should be free to use what they want to.

Yeah, more "fuck everyone else, give me money" entitled kid bs. People has no right to demand you to work for free for them (maintain a mess of code, or take large risks in liabilities just so you can live the good life).

Developers that don't want to update their application can use older versions of the library and ship it with their program (which is very widespread, also Windows is designed to allow that as the other guy has pointed out).

You disagreed on other thread about my idea of forcing people to unify their APIs on Linux.

Yet you encourage forcing people here to drop their use of X API just because you don't like it?

Much better, I stated valid reasons why library developers would want to drop support for some API, or drop unsafe APIs alltogether (if they are beyond sanitizing).

Library developers are just like other application developers, their time and resources are finite, their skills may not be much better than average.

Just like a software developer removes features he cannot maintain properly from his application, so do library developers.

I'm frankly appalled that you can't even grasp that they are the same as you (well, maybe a little less asshole than you).

After all, if the app gets hijacked because of the library, it's the application who is vulnerable (literally, even technically, its process space is hijacked), just as if itself had bad code. It doesn't gain any extra privileges.

Lol that's not how it works. The library developer will be harassed by security reports and bad PR, and could even get some lawyers looking for his head.
Does not matter who's the fault here, if they start looking for a scapegoat and you don't have lawyers ready you get fucked.

While you get bad PR from security analysts that need to show how cool they are.

Anyway, you're aware you can hide the API from the SDK and headers right? Literally just don't expose it anymore. That should be more than enough encouragement. Or even use "deprecated" attributes (standard in C++) on them so they give fat warnings when compiling.

Did you miss that the main issue is codebases already using the bugged function?

Also please don't tell me you webdevelopers actually even read the compiler warnings at all, because I know for a fact that it isn't true.

X will still run with more privilege than the unprivileged user (in this case) so it can wreck your files in theory.

Yeah, it goes much deeper than that, but it's not just a matter of X or Wayland here, the whole UNIX/Linux OS design was aimed mostly at server usecase, it's not fit for desktop. That's why I keep mentioning Android, there the system was built from scratch with the "end user device" usecase in mind, and it's in another league (while still having its own share of issues).

As you say, we are in the silly situation where most malware does not even need to get root access to actually steal your data/accounts/files, (as most software is run with your user, that has access to all the home directory where settings and other stuff is stored), while it would need to get root access only to do changes to the system... which isn't really required at all if all you want to do is steal the user data/accounts/whatnot.

This https://conf.qtcon.org/system/attach...f%3F1473018986 is a nice writeup about what needs to be done to even begin to talk about secure user-facing Linux system. And it's not just a wank about Flatpack (which is crucial to restrict a bit what application can access what in a relatively easy way for the application packager that does not need to deal with SELinux or AppArmor profiles or anything of that sort directly), but focuses more on what the DE needs to do to ensure some security and to avoid basic "fake password prompt" applications or similar kindergarden-grade malware which would currently just pwnzor any linux system.

I'm a bit worried that since the guy writing that is now no more the Kwin maintainer and he said that the KDE community is getting overrun by "usability team" or somesuch that have your same unsettling disregard for security if there is performance or usability on the stake.

[caligula]

Yeah, it goes much deeper than that, but it's not just a matter of X or Wayland here, the whole UNIX/Linux OS design was aimed mostly at server usecase, it's not fit for desktop. That's why I keep mentioning Android, there the system was built from scratch with the "end user device" usecase in mind, and it's in another league (while still having its own share of issues).

Well, one could argue that typical Linux desktops are as fit for desktop as pre Vista era Windows were. I don't know Windows internals that well, but even the UAC seems more like sudo. The world has changed quite a lot since then. Nowadays, you might not even need all the security for running local apps as many users only use web 2.0 apps and it might be sufficient to just sandbox the browser.