Distributors entering Flatpakland
A traditional binary package from a distribution contains the program of interest, of course, along with any supplementary files that it needs. The package also carries metadata describing, among other things, which other packages must be installed for the program to work. The distribution's package manager uses that dependency information to ensure that every package is properly installed.
The Flatpak format has been described as "just another distribution format" and, to an extent, it is true. A Flatpak package (or, simply, "a flatpak") has everything that a .deb or RPM package would have, but there are some significant differences. Perhaps at the top of the list is the way that dependencies are handled. A traditional package will have a (possibly long) list indicating every other package that is needed; a Flatpak package, instead, will list a single "runtime" containing the base set of libraries against which the package is built. If there are libraries or other dependencies that do not appear in the runtime of choice, they are simply bundled with the application in its flatpak.
This arrangement has a certain appeal to packagers. The "runtime plus bundling" approach simplifies dependency management, and the ability to bundle patched versions of system or runtime libraries is called out as a Flatpak feature. A package built against a given runtime can be installed on any system that has that runtime installed, making it possible to build a single package that can be installed on multiple distributions. Distributors can thus use this format to make their lives easier; purveyors of proprietary packages also see some obvious charm in this idea.
In a sense, Flatpak has set out to solve many of the same problems that the ill-fated Linux Standard Base effort addressed many years ago.
Flatpak is designed to work with distributions that are built around an immutable core; it will not install into system directories like /etc or /usr/bin. That makes it attractive for distributors that are trying to create that sort of offering.
One other key selling point for Flatpak is the built-in sandboxing mechanism. Applications installed with Flatpak will, by default, be run inside a container that has almost no access to the underlying system or the Internet. Through declarations in the manifest file used to build the package, a specific application can request access to, for example, the user's local files, the Internet, or the window-system server. In theory, at least, this sandbox makes installing packages safer and limits the damage that can be caused by a compromised or malicious package.
Flatpak is not without its critics. While packages can share the same runtime, there is nothing to prevent a proliferation of runtimes and versions; that already seems to be happening to an extent. Both the runtimes and the packages themselves are large, significantly expanding the amount of storage space and memory consumed. It is common for applications to request access to local files and the Internet whether they need it or not, to the point that some see Flatpak's sandbox claims as being more hype than reality.
All of that adds up to a certain amount of opposition to the use of Flatpak. It also seems possible that much of the opposition to Flatpak may result from an instinctive resistance to changing the way things have always been done.
Fedora's (un)filtered Flathub
On the Fedora side, the discussion has been stirred up by this Fedora 37 change proposal removing the filters currently applied to the Flathub package repository in Fedora's GNOME Software application. Once the filter is gone, all of the packages available on Flathub, including those containing proprietary software or programs that, for reasons such as patent concerns, cannot be shipped with Fedora, will be available to be installed. Flathub as a whole will still be disabled, though, unless users enable third-party repositories.
The advantages of this change are said to be that it makes more software readily available to Fedora users and makes that software more secure by sandboxing it. The latter reason is part of why the GNOME Software tool will prefer flatpaks over traditional RPM packages when both are available. But there are some vocal members of the Fedora community who are strongly opposed to the idea. Vitaly Zaitsev, for example, complained about the preference for flatpaks, saying that it would cause flatpaks to replace RPM packages as a system is updated. A lot of the points mentioned above — install size and porous sandboxes, for example — have come up in this discussion, as has the perceived bias against the RPM Fusion repository, which was discussed in depth here in June.
It seems unlikely that these objections will stop the unfiltering of
Flathub — or the transition toward Flatpak in general. The distribution
seems committed to that direction, and the Silverblue variant, which
is built around an immutable core installation, already
requires Flatpak. In the discussion, Michael Catanzaro extolled the
security benefits of the format and pointed out that, despite years of
complaints, Flatpak opponents have not come up with a viable alternative
that provides similar security benefits. Richard Hughes argued
that "flatpaks are in almost all cases what users should be using
".
Unless something changes, it looks like full speed ahead for Fedora's
Flatpak future.
OpenSUSE's ALPs are flat
Back in April, SUSE announced an effort known as the "Adaptable Linux Platform" (ALP) that is, in some way, meant to define the future of the SUSE Linux Enterprise (SLE) distribution. There was a lot of text about how the process would be open, but outside observers might be forgiven for thinking that ALP remains fairly murky so far. There is not much public information yet on just what ALP will be or how it will affect either SUSE's enterprise offerings or openSUSE. The hints that have come out, though, suggest a distribution built on a small, immutable core with applications managed separately, most likely using a format like Flatpak.
On July 5, Dan Čermák posted the
minutes from a meeting of the ALP working group that was focused on
"how the ALP Desktop is going to look like and how we can dispel fears
around flatpaks and containers when it comes to the ALP desktop
". The
minutes note that Flatpak will indeed be used as a distribution format, but
stressed that there would be no need to install flatpaks from external
sources like Flathub; "the packaging model will not change, only the
format
".
When asked about the benefits driving a switch to flatpak, Čermák mentioned the sandboxing mechanism, but said that the main advantage was in the reduction of packaging work. Desktop applications like Firefox or LibreOffice could be built once on the rolling openSUSE Tumbleweed distribution, then shipped for Tumbleweed, Leap, ALP, and presumably anything else SUSE might create. It is not hard to see why distributors are attracted to an option that could significantly decrease the amount of work required to maintain current packages of complex applications.
There was some fundamental opposition to use of Flatpak in the openSUSE
community as well. Robert Kaiser, for example, said
"if there's no RPM-based distro left without that weird packaging like
flatpak, it's probably time to go back to Windows
". As a whole,
though, the openSUSE community seems less stirred up by the prospect — so
far at least. There may be a few reasons for that, including a relative
lack of experience with Flatpak in the openSUSE community and the amorphous
nature of ALP in general. But this
reassurance from Čermák can only help as well:
Tumbleweed will be the place where development is going to take place, but there are no plans to fundamentally alter Tumbleweed. You'll still be able to use Tumbleweed like you used before. Additionally, you'll be able to use the "containerized stuff", but you won't have to, at least for the foreseeable future.
There may soon come a time where use of Flatpak on Fedora is unavoidable, at least when it comes to installing certain complex applications. Thus far, openSUSE does not appear to be driving in that direction, so Tumbleweed users (who make up a large part of the openSUSE community) need not fear being pushed unwillingly into the Flatpak world.
One should not underestimate the value of that last point. Much of the bitterness around the systemd transition was certainly caused by the feeling that it was being forced on users who were happy with their existing setup and felt no need to change. Even if Flatpak is as great as some claim, a poorly handled transition risks creating similar levels of unhappiness.
That transition seems likely to come; in a later
posting Čermák questioned the value of packinging some complex
applications and suggested that they may be made available only in flatpak
form if they are shipped by the distribution at all. Robert Schweikert said
more succinctly: "What we have today has worked reasonably well for
probably about 30 years but the model is certainly showing it's age
".
Evolving to meet current needs is exactly what the distributors need to be
doing, and that evolution will surely bring changes that are visible to end
users. The key will be handling the changes with sympathy for those users
and, hopefully, avoiding some of the turbulence we have seen with past
changes.
Posted Jul 8, 2022 15:47 UTC (Fri)
by IanKelling (subscriber, #89418)
[Link] (28 responses)
Posted Jul 8, 2022 15:59 UTC (Fri)
by ebassi (subscriber, #54855)
[Link] (23 responses)
It would be entirely possible today to write a simple script that took that manifest and downloaded every single dependency into a specific location.
Posted Jul 8, 2022 17:04 UTC (Fri)
by jafd (subscriber, #129642)
[Link] (6 responses)
Posted Jul 8, 2022 18:46 UTC (Fri)
by atnot (subscriber, #124910)
[Link] (5 responses)
Of course, being confident in the package being an authentic result of the manifest doesn't help a whole lot if what that manifest does is install opaque blobs from the internet that may not be authentic versions of their sources, even if flatpak does at least enforce that downloads match a given sha256.
[1] https://github.com/zaclegarssure/flathub-rebuilder
Posted Jul 11, 2022 8:46 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (4 responses)
That's how it works on Debian. Either the stuff is in the .tar file (or git repo) or needs to be in a .deb package. No downloading. That's important to be able to do reproducible builds.
Posted Jul 11, 2022 11:07 UTC (Mon)
by lunaryorn (subscriber, #111088)
[Link] (3 responses)
Posted Jul 11, 2022 13:32 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
Posted Jul 11, 2022 13:37 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link]
However, you can also provide files alongside the manifest in the same git repo. See e.g. the MKVToolNix manifest[2] as an example.
[1] https://github.com/flathub/org.libreoffice.LibreOffice/bl...
Posted Jul 11, 2022 19:56 UTC (Mon)
by bartoc (guest, #124262)
[Link]
Posted Jul 8, 2022 17:30 UTC (Fri)
by IanKelling (subscriber, #89418)
[Link] (14 responses)
https://docs.flatpak.org seems to be entirely about creating and building an app locally and publishing the binary, but nothing about about how to download existing app and build that.
The equivalent documentation for apt is something like this: https://wiki.debian.org/BuildingTutorial which includes apt-get source PACKAGE, and building from that.
Posted Jul 8, 2022 17:55 UTC (Fri)
by IanKelling (subscriber, #89418)
[Link] (9 responses)
Also, the license information is much worse. In debian based distros, I can easily see the license of every dependency. There is more complete licensing info in /usr/share/doc/PACKAGE/copyright. And I know that someone has put some time and effort into checking them.
Posted Jul 8, 2022 23:38 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (8 responses)
* Flathub should allow you to filter by FOSS-only.
Posted Jul 9, 2022 11:08 UTC (Sat)
by khim (subscriber, #9252)
[Link] (6 responses)
Indeed. We live in a world where the majority of users wouldn't be able to excercise these all-too-essential freedoms anyway: they are not developers themselves and they don't have money to pay the developers. We have to accept that. It's just how life is. But that means that things like licensing and even the distinction between free software or proprietary shouldn't be shoved into the new user face. If Flathub doesn't allow one to filter FOSS-only packages then it's bad, I suppose: some people do want to avoid proprietary apps and while they are in the minority (and would always be in minority) they deserve adequate treatment. As long as they not try to impose their will on the majority, that is.
Posted Jul 10, 2022 4:48 UTC (Sun)
by IanKelling (subscriber, #89418)
[Link] (5 responses)
That isn't right: the majority of students in the US are learning to
I've shown to 10-12 year old kids that they can open a terminal with
Posted Jul 10, 2022 13:55 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (4 responses)
> That isn't right: the majority of students in the US are learning to code. A large fraction of people will know some basics. Practical software freedom is useful and important.
I'm sorry, but you're living in cloud cuckoo land ...
As a professional software developer, I all too often find myself in the position of being unable to exercise those freedoms. As I said, I would like to have Reveal Codes in LO, but I lack both the skills, and money, to be able to do anything about it.
Just because it's a mandatory part of education, it doesn't mean students are even *capable* of learning, and even if they are capable, doesn't mean they have the *desire* (which is massively important!).
You can have the brightest students in the world, and if they want to be musicians, or artists, or lawyers, it's a pretty safe bet they won't be able to code for toffee BECAUSE THEY HAVE NO INTEREST IN IT! (Or their skills will be crap because it's a necessary but unwelcome requirement. I see that daily in my job.)
RMS by all accounts was a software prodigy. Mozart was a music prodigy. Other people are prodigies elsewhere. The majority of people are either below average, or tend to be prodigies hopeless at fields outside their expertise. "Jack of all trades, master of none" springs to mind. Or "Master of one, hopeless elsewhere". The freedoms are great for professional coders or software prodigies, useless for other people.
Cheers,
Posted Jul 11, 2022 8:50 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (3 responses)
apt-get build-dep xxx
You don't have to figure out the specific way that package builds, the compiler options, the configure options, the dependencies… it's all done.
Posted Jul 11, 2022 10:13 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
> apt-get build-dep xxx
You're missing a very important point.
For the typical man on the Clapham Omnibus, they don't have difficulty following instructions, they have problems with "[do your thing]".
Let me list the languages I know - FORTRAN IV, Fortran 77, C, Forth, DataBasic, Perl, VBA ... (to dramatically varying abilities - 77, C, VBA, DataBasic I've seriously used ... and I've probably missed a few ...) and still I have major trouble even trying to UNDERSTAND the code base of various projects I want to get involved in - lilypond, LO, ScarletDME. I can build it easy enough - FFS my main distro is Gentoo!
If I, a seriously bright programmer, have trouble then your average guy isn't going to stand a hope. Yes, a lot of my problem is lack of time, but then that's true of average bloke, who DOESN'T WANT TO KNOW unless he's forced to.
You forget we are a self-selecting minority. To 99% of the people out there, all this is an irrelevance, a distraction, something they would much rather not know about even when they are forced to care ...
Cheers,
Posted Jul 11, 2022 10:36 UTC (Mon)
by ldearquer (guest, #137451)
[Link] (1 responses)
Posted Jul 11, 2022 16:05 UTC (Mon)
by IanKelling (subscriber, #89418)
[Link]
Posted Jul 11, 2022 20:18 UTC (Mon)
by bartoc (guest, #124262)
[Link]
The other nice thing is that flatpak will prevent non-free apps from screwing up the system by incorrectly attempting to do applocal deployment of their runtime dependencies. It's really rather hard to do this correctly on linux (and can be nearly _impossible_ if you end up with libraries that load tightly coupled plugins and are too enthusiastic in their search for them). Let's just say if I still had to support Matlab installations I would absolutely make a flatpak and distribute it that way.
I suppose making bundling in this way easy does make it easier to distribute proprietary apps (after all, proprietary rpm/dpkg repos are .... not usually worthwhile or reliable)
Posted Jul 9, 2022 10:57 UTC (Sat)
by khim (subscriber, #9252)
[Link] (3 responses)
You don't have that web deb, you don't have that with rpm (if you claim otherwise then show me how I can download sources for the official deb/rpm builds of Chrome), why do you think flatpak would provide that? Most developers don't want to bother with publishing their sources thus any format which makes it impossible is DOA.
Posted Jul 10, 2022 4:35 UTC (Sun)
by IanKelling (subscriber, #89418)
[Link] (1 responses)
Most packages in GNU/Linux distros are free software and the source code is published.
Posted Jul 12, 2022 9:31 UTC (Tue)
by khim (subscriber, #9252)
[Link]
And only tiny minority of software ends up in GNU/Linux distros. Of course software there would be rebuildable! It's like trying to see how many people are using Internet via an Internet-based medium. But even the majority of You just try to live in the imaginary world where these don't exist.
Posted Jul 18, 2022 9:47 UTC (Mon)
by ras (subscriber, #33059)
[Link]
Odd. I do this often: "apt-get source xxx ; debuild xxx". In fact I do it often I have a little shell script that takes the URL of a Debian .dsc (source package), and builds it from source.
Yes, Chrome is a little different. It's near impossible to build from source. I'm struggle to understand anybody who favours the open source model could think that is a good thing, that should be facilitated by the open source movement. If your happy with that, why not just download the binary from Google directly and bypass all the inconvenience open source imposes? That's effectively what happens for google-chrome on Debian now. If you like running google-chrome on Debian it works very well.
Posted Jul 9, 2022 12:25 UTC (Sat)
by MickeyDance (guest, #112575)
[Link]
Posted Jul 8, 2022 19:29 UTC (Fri)
by nedrichards (subscriber, #23295)
[Link] (3 responses)
> flatpak install flathub org.gnome.gedit.Sources
gets you a flatpak extension with the sources used in the build (certainly available for all the apps on flathub) when using flatpak-builder you call --bundle-sources to create one of these extensions. Also as ebassi says you get the manifest as well which should be 'pretty reproducible' if you just built that yourself.
Posted Jul 8, 2022 20:42 UTC (Fri)
by IanKelling (subscriber, #89418)
[Link] (2 responses)
>gets you a flatpak extension with the sources used in the >build (certainly available for all the apps on flathub)
That is great. I will actually try flathub at some point then. Is this documented somewhere? If not, do you know an appropriate place for it?
Posted Jul 10, 2022 20:07 UTC (Sun)
by nedrichards (subscriber, #23295)
[Link] (1 responses)
I'll continue having a think if there's anywhere easier to send patches.
Posted Jul 11, 2022 15:45 UTC (Mon)
by IanKelling (subscriber, #89418)
[Link]
"the wiki" I assume you mean is: git clone https://github.com/flathub/flathub.wiki.git
Posted Jul 8, 2022 15:54 UTC (Fri)
by ju3Ceemi (subscriber, #102464)
[Link] (4 responses)
Basically, that's a windows 2000 level of security, where every software needs to be upgraded by itself, so every package that is not under active development turns into a security nightmare
This is a remake of containers : I wonder why flatpak and not docker ? Why not self-contained binary (the kind of 500MB binary we find somewhere) ? A single file, easy usage, just copy it somewhere and execute it ?
There are good points for those kind of technology
Posted Jul 8, 2022 17:01 UTC (Fri)
by jafd (subscriber, #129642)
[Link]
Posted Jul 8, 2022 17:19 UTC (Fri)
by ejr (subscriber, #51652)
[Link]
All of these require end-users to know about and understand the sandboxing issues. Might be ok for corporate deployment, but not for everyday laptops.
Posted Jul 10, 2022 8:21 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
A package does not need to be "under active development" to be rebuilt. Sure, it's faster and easier not to have to rebuild it at all but there are drawbacks to that approach too: the most obvious and best known is the difficulty of having multiple versions of the same library in use at the same time (by different packages). For more drawbacks see the article.
Posted Jul 11, 2022 20:45 UTC (Mon)
by bartoc (guest, #124262)
[Link]
As for container data format: actually, fedora's official flatpak repos _are_ based on the same OCI image format supported by docker. Flathub (and most other) images us OSTree, which theoretically should allow better de-duplication especially for apps that contain a lot of non-runtime dependencies.
The runtimes can update "under" the apps, and there is a concept of "runtime extensions" to add additional maintained bits to the runtime that can also update under apps. what doesn't update are all the higher level dependencies that don't really tend to provide API/ABI stability anyway but where on a traditional linux system all packages must share a single version. This leads to a proliferation of patching in distros that sucks for basically everyone.
For "why not a self contained binary": Yeah, stuff like Appimage can work. The thing is you actually really need some stuff to get updated underneath the app. Graphics driver userland libraries come to mind, as do platform libraries like glibc (and it's associated NSS plugins). These libraries all have really stable ABIs and are _designed_ for this. You can do this with just a dynamic binary that has most things static linked, ofc, and that can be fine, but flatpak uses containers because they can and because they want to do other stuff besides just bundling dependencies.
Posted Jul 8, 2022 16:05 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Jul 8, 2022 17:03 UTC (Fri)
by jafd (subscriber, #129642)
[Link]
Posted Jul 8, 2022 17:28 UTC (Fri)
by jafd (subscriber, #129642)
[Link] (9 responses)
Yeah, I know, I know, it's possible with the current systems, blah blah blah, consider VMWare Workstation hauling its own GTK+ and its dependencies, blah blah. But when it comes to open source, much of the tiring work in packaging goes into ensuring that each and every package builds against system libraries (I know, Java is going to be different soon, but that's beside the point). So if there's another hole in libssl, you update to a patched version, restart processes, and you know every one of them is patched.
But Flatpak advertises very very loudly that they are more secure, and they have a sandbox which no one else has, and it's inevitably going to create a false sense of security. There's going to be a lot of people mindlessly repeating this mantra while the sandbox is really a theater in many cases.
There have been lots of terrible tutorials about server software encouraging downloading random docker images and running them. How sure could you be that an image from some IvanNotALittleBitCreepy would do no more and no less than what it said on the tin? I expect the same kind of problems bloom from the proliferation of flatpaks.
If a vulnerability opens a way for a malicious actor to not infect your "immutable and very secure" base system but go for /var/lib/flatpak, it's going to be just as juicy a target. What measures are there in place to ensure that unpacked flatpaks *stay* what they are? What measures are there to ensure their ongoing integrity?
Also, it would be darn nice to, say, revoke access from microphone and webcams at will without having programs break. I want to be able to deny programs access to my things without telling them I deny it. IMO it's a major oversight on other platforms. Imagine a piece of software which starts mining cryptomoney if you deny it notifications or microphone access.
Mind you, I'm very philosophical about flatpaks. If it has to be a cross-distribution format, so be it. I like RPMs very much, but let flatpaks thrive. Can be AppImages for all I care. But I'd like to have it without misleading advertising, without security theater and some real benefits app isolation can give so I can have power over the application vendors. And I'd like open source packages to be up to traditional expectations as well (so I can still get a tarball and repackage it myself as I see fit, no tivoisation please).
Posted Jul 8, 2022 19:43 UTC (Fri)
by re:fi.64 (subscriber, #132628)
[Link] (8 responses)
This *should* be entirely possible in combination with Pipewire + Wireplumber, by creating a script that revokes microphone access when it detects it's a Flatpak, but my experiments haven't been successful yet (mostly because I've never played with WP scripting before and have no idea what I'm doing).
Posted Jul 9, 2022 8:37 UTC (Sat)
by jafd (subscriber, #129642)
[Link] (7 responses)
(The next step could be an ability to route any video as webcam or any application/audio file as microphone, but I concede this can be somewhere in advanced options.)
Posted Jul 9, 2022 11:24 UTC (Sat)
by khim (subscriber, #9252)
[Link] (5 responses)
If that would be a standard feature then app developers can and will find a way to detect that you denied a mic access. Which would defeat the purpose of that feature.
Posted Jul 9, 2022 13:15 UTC (Sat)
by jafd (subscriber, #129642)
[Link] (4 responses)
Applications that try to invoke things like machine learning or escape the sandbox to make sure I’m giving them a real mic should burn in hell anyway, no one ever does it for a good reason.
Posted Jul 9, 2022 13:52 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (3 responses)
imho, an app demanding mic access when it doesn't need it is pretty much the definition of nefarious ... it would get it deleted from my system instantly.
Cheers,
Posted Jul 9, 2022 15:22 UTC (Sat)
by jafd (subscriber, #129642)
[Link] (2 responses)
So many questions here, really.
You may argue, „but with regular .deb or .rpm, an unrestricted app may use anything and everything and not have to ask you!”
Yes. I am aware of this. But this is beside the point.
I’m using software that overwhelmingly doesn’t do any of these things. I have sources I can trust from which I obtain the software. I’m not the one who started the conversation about how the world is full of crooks who invade my privacy with keyloggers, screenshots, webcam access, microphone access, and who knows what else, and how our lord and saviour App Store^W^WFlatpak is going to save us from all of this suffering because they have sandboxing and permissions.
Sigh. They bring up the topic, the onus is on them to show how real good they are.
And if the single point of flatpak (and the one which it sort of delivers) is to remove a layer of package maintainers and let software publishers rule the game, just be upfront about it. No need to go into the domain of fairy tales about how my hair is going to grow silky smooth once I accept flatpak on my systems.
Posted Jul 9, 2022 21:05 UTC (Sat)
by roc (subscriber, #30627)
[Link] (1 responses)
When you check the device privacy settings there is a section listing the applications that have used the microphone in the last 24 hours. There is also a master switch there to stop all applications from using the microphone, temporarily.
Android also automatically revokes permissions from apps you haven't used for more than a month.
It's a pretty robust setup, all things considered.
Posted Jul 10, 2022 17:57 UTC (Sun)
by smurf (subscriber, #17840)
[Link]
Well, it has become a pretty robust system over the last fifteen years. At first, not so much.
It'd be nice if the Flatpak-and-whatnot people would learn from, and possibly improve upon, the solution(s) Android came up with.
Posted Jul 11, 2022 20:51 UTC (Mon)
by bartoc (guest, #124262)
[Link]
I think both of these things are goals of pipewire, hopefully someone will develop simple tools to do this (every such tool I have used on other platforms has a UI modeled after like, manual switching panels that I find difficult to use).
Posted Jul 8, 2022 18:20 UTC (Fri)
by atnot (subscriber, #124910)
[Link] (10 responses)
This is not quite true. While applications will primarily depend on one runtime, runtime extensions allow some dependencies to be managed separately. For example, ffmpeg is available separately as the org.freedesktop.Platform.ffmpeg-full runtime extension. Similarly, the org.kde.Platform.Locale extension provides shared translations for KDE apps. Base apps also allow another form of dependency reuse, although those can not be upgraded independently.
Posted Jul 8, 2022 18:21 UTC (Fri)
by jafd (subscriber, #129642)
[Link] (9 responses)
Posted Jul 8, 2022 18:35 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (5 responses)
It's atypical but feasible and Fedora has it's own Flatpaks sourced from RPMs that is independent of Flathub. Refer to https://src.fedoraproject.org/projects/flatpaks/
Ostree, the underlying storage format used by Flatpak has support for OCI containers as well, refer to https://coreos.github.io/rpm-ostree/container/
Posted Jul 9, 2022 9:03 UTC (Sat)
by GvMariani (subscriber, #7320)
[Link] (1 responses)
Posted Jul 9, 2022 14:58 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jul 9, 2022 15:25 UTC (Sat)
by jafd (subscriber, #129642)
[Link] (2 responses)
Posted Jul 9, 2022 16:32 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
I would start here: https://gitlab.com/freedesktop-sdk/freedesktop-sdk
Posted Jul 11, 2022 20:53 UTC (Mon)
by bartoc (guest, #124262)
[Link]
Posted Jul 8, 2022 19:53 UTC (Fri)
by atnot (subscriber, #124910)
[Link] (2 responses)
1. Extensions are opt-in on an application basis. If an application does not need an extension, it is not there to cause trouble. Among other things, this allows you to both reproduce a user's system exactly and guarantee it will be the same as it is on your machine.
2. Multiple branches of an extension can be installed at the same time. For an example perhaps painfully familiar for a lot of us: if one has a python extension runtime, one could require branch 3.8 of it in one application, 3.9 in another and bundle a custom patched version in a third, without there being any ambiguity about what /bin/python refers to within each flatpak.
3. Because they are coarser-grained, the number of combinations that need to be tested are a lot lower. Most applications depend on at most one or two extensions.
4. Purely technically, use of tools like OSTree requires a very different format.
5. Purely politically, making a new package format designed to unite the Linux desktops and making it heavily rely on your own existing technologies is unlikely to go over well with other distros. (cf. Snap)
Posted Jul 10, 2022 17:29 UTC (Sun)
by gray_-_wolf (subscriber, #131074)
[Link] (1 responses)
Could this lead to a fragmentation of an ecosystem for whatever interpreted language? As in, "I don't like this about python, so let me just patch that out". Since you will ship your own python anyway, you might not care. Am I too paranoid?
Posted Jul 10, 2022 19:07 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
If you're talking about the interpreter and its stdlib, who knows. Embedding Python into your own package is already a nightmare to do half decently. Attempts at "bring your own Python" packages have been a flop so far because you lose double-click on the binary. So we just ship our own and say "too bad" about anything else (`pip` is not shipped in a working condition because we disable OpenSSL; if we shipped that, we'd get hammered on every audit for being "out of date").
Posted Jul 8, 2022 20:44 UTC (Fri)
by dowdle (subscriber, #659)
[Link] (5 responses)
Generally speaking, stuff on Flathub has mostly been third-party packages with licensing issues that keep say, Fedora, from shipping it... so there isn't any conflict with Fedora distro provided packages. That isn't 100% true, because there are more and more packages available as flatpaks that distros package themselves. In many cases, the flatpaks are newer versions than the distro packages, and if you are looking for that newer version, you'll most likely be happy to find it as a flatpak. This is especially true when talking about distros with older runtimes. So, yes... with flatpak you can have the latest / greatest of the desktop stuff with flatpak... an in many cases the version disparity is stricking. Yes, a CentOS 7 desktop can have the same (or newer) versions of desktop software as what you'll find from the latest release of Fedora. That aspect is a big improvement.
In the article a complaint was made that there may be multiple versions of various libraries/runtimes installed... it should also be pointed out that having multiple versions of some things can be a benefit. If you want to install an application that requires a much newer environment or a much older environment than that provided by your distro... often you can't install that software... as you can't satisfy the needed dependencies. Since flatpaks provide what they need to run... it doesn't matter how old/stable nor bleeding edge your distro might be. You can practically run everything... if there is a flatpak for what you want.
I have mixed feelings about preferring a flatpak over a traditional distro provided package... but as long as both options work... most users won't care as they most likely aren't into the nitty-gritty details. They just want to be able to install what they want, and they want it to work. Check.
If you don't like flatpak, don't use it. I'm going to use it though... especially on older systems I want newer-versions-of-things on.
Yes, it may take a while before the build-it-yourself-ers are happy with all of the flatpak options... but again, the vast majority of users don't build their software from source and wouldn't notice. I'm glad they are putting in the effort to appease those that want to build flatpak'ed stuff themselves.
Posted Jul 9, 2022 13:55 UTC (Sat)
by mbunkus (subscriber, #87248)
[Link] (4 responses)
Yep. And it's only really suited for a single main application per Flatpak as it only generates one start menu entry per Flatpak.
You can actually run other binaries contained in the Flatpak, though, both graphical & CLI ones. For example, I offer a Flatpak for my MKVToolNix which consists of five CLI applications & one GUI. The GUI is obviously the main application, but you can run all the others with e.g. "flatpak run org.bunkus.mkvtoolnix-gui mkvmerge --output destination.mkv source.mp4"
The result is that sure, you can have your office program as a Flatpak, but you'll only get a single start menu entry for it, not one for the text processor, one for the spreadsheet etc.
Snaps, on the other hand, can contain multiple binaries, both GUI & CLI, and those are actually made available via standard directories, meaning you can just run them via their usual executable's name.
AppImages are closer to Flatpaks in this regard, though still quite different. AppImages aren't installed: you only download them, grant them the executable bit & run them directly. There is no integration with start menus, MIME systems or anything else, making them highly portable but poorly integrated. One interesting fact about AppImages is that the name you run them as is passed through to the main executable as its program name, allowing you to simply symlink the AppImage file to a name of one of the executables inside it, and then the main executable can decide which executable to actually run based on argv[0]. Definitely not all AppImages do that, though, as you have to provide your own main executable; there isn't a standardized one. (For example: "ln -s MKVToolNix_GUI-68.0.0-x86_64.AppImage mkvmerge ; ./mkvmerge --output destination.mkv source.mp4")
I'm not saying one method is better or worse; just pointing out some of the differences in packaging.
Posted Jul 11, 2022 12:44 UTC (Mon)
by abo (subscriber, #77288)
[Link] (3 responses)
Posted Jul 11, 2022 12:50 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link] (2 responses)
[1] https://github.com/flathub/org.libreoffice.LibreOffice/bl...
Posted Jul 11, 2022 20:55 UTC (Mon)
by bartoc (guest, #124262)
[Link] (1 responses)
Posted Jul 11, 2022 21:07 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link]
[1] https://docs.flatpak.org/en/latest/conventions.html#deskt...
Posted Jul 8, 2022 20:44 UTC (Fri)
by flussence (guest, #85566)
[Link] (6 responses)
Posted Jul 8, 2022 21:05 UTC (Fri)
by ejr (subscriber, #51652)
[Link] (5 responses)
Posted Jul 9, 2022 6:52 UTC (Sat)
by flussence (guest, #85566)
[Link] (3 responses)
Specifically I'm imagining an extension of plain old .desktop files with systemd's existing unit file sandboxing options; reusing the existing knowledge, tooling, specs and documentation of both in a backwards-compatible unintrusive way. A legacy /usr/bin/xdg-open or equivalent launcher would work as usual, newer ones would provide sandboxing in a way that's completely transparent to the user (and the added metadata could be used for a number of other things besides sandboxing - it's the same type of signal browsers interpret HTTPS as).
Moreover it just seems like doing that to begin with would be a more respectful use of everyone's time than yet another format war between what always seems to boil down to IBM vs Canonical vs Luddites. The ever-growing volume of the latter crowd and the fact that these things seem to drag on for years while every corner tries to beat the others into submission are a major missing stair problem.
Posted Jul 9, 2022 12:00 UTC (Sat)
by walters (subscriber, #7396)
[Link] (2 responses)
Achieving the goal requires separating the host and application filesytems.
Posted Jul 10, 2022 8:06 UTC (Sun)
by jengelh (guest, #33263)
[Link] (1 responses)
Posted Jul 11, 2022 18:40 UTC (Mon)
by walters (subscriber, #7396)
[Link]
flatpak is scoped to install only GUI/desktop applications that should run without any host privileges; you can't use today flatpak to install a (system wide) VPN system or whatever. So by limiting its scope, it is much more secure for its target domain.
Posted Jul 9, 2022 9:48 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link]
Posted Jul 8, 2022 23:43 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (8 responses)
IMHO this is the biggest wasted opportunity that should have been handled from day 1. In the long term it would have been much better for the whole ecosystem if the stores (like flathub) strictly enforced two rules:
- if a library/dependency is available in a runtime, JoeRandomDev is actively forbidden from bundling it (bonus points for static linking checks!)
Sure it would have costed some additional pain in the short term, at the beginning. But I think it would have been worth it to end up with a much cleaner, healthier and safer ecosystem overall.
Posted Jul 9, 2022 11:46 UTC (Sat)
by khim (subscriber, #9252)
[Link] (2 responses)
Sure, if your goal is to stick with 1% market share forever and ensure everything would be totally pure and clear it would be a worthwhile goal. That's what I was hearing for last 20+ years about
Posted Jul 9, 2022 12:35 UTC (Sat)
by bluca (subscriber, #118303)
[Link] (1 responses)
Posted Jul 9, 2022 19:32 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link]
Posted Jul 9, 2022 13:03 UTC (Sat)
by alonz (subscriber, #815)
[Link] (1 responses)
Posted Jul 9, 2022 15:20 UTC (Sat)
by bluca (subscriber, #118303)
[Link]
Posted Jul 9, 2022 13:14 UTC (Sat)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Jul 9, 2022 14:42 UTC (Sat)
by smcv (subscriber, #53363)
[Link]
Similarly, if Foo uses the GNOME runtime and Bar uses the KDE runtime, and both the GNOME and KDE runtimes are based on fdo Platform 21.08, then having the maintainers of the GNOME and KDE runtimes trigger an automatic rebuild against fdo Platform 21.08 is usually enough to give both Foo and Bar a fixed zlib.
The only time this would not be enough is if Foo and Bar are statically linked to zlib, or build and bundle their own zlib in /app/lib, or otherwise have their own private copy of zlib instead of using the runtime's. Traditional distro packages have the same limitation, of course.
Posted Jul 9, 2022 14:45 UTC (Sat)
by dbnichol (subscriber, #39622)
[Link]
Posted Jul 9, 2022 2:55 UTC (Sat)
by pabs (subscriber, #43278)
[Link] (3 responses)
This would mean you could easily install older or newer apps that are ABI-incompatible with your system libraries, or you could install Debian apps on other distros fairly easily. The ostree results would enable easy bisecting, which currently requires lots of debootstrap/upgrade runs.
https://manpages.debian.org/debbisect
Posted Jul 9, 2022 14:55 UTC (Sat)
by dbnichol (subscriber, #39622)
[Link] (2 responses)
It... mostly worked, but it was fragile and having to go through the Debian packaging flow to make apps was definitely not what our app developers wanted. Eventually our runtime was changed to be based on the Freedesktop runtime just like GNOME and the other folks. Our apps got converted to be build with flatpak-builder just like on Flathub.
These days we're mostly out of the apps game with our developers working on Flathub as needed.
Posted Jul 10, 2022 3:26 UTC (Sun)
by pabs (subscriber, #43278)
[Link]
Posted Jul 10, 2022 3:28 UTC (Sun)
by pabs (subscriber, #43278)
[Link]
Posted Jul 9, 2022 3:00 UTC (Sat)
by pabs (subscriber, #43278)
[Link] (4 responses)
Posted Jul 9, 2022 15:04 UTC (Sat)
by smcv (subscriber, #53363)
[Link] (3 responses)
For Snap, the portals rely on looking at the AppArmor LSM label, which requires snapd running as root with CAP_MAC_ADMIN to set up (no ability to run completely unprivileged like Flatpak can) and is not great at being cross-distro (works in Debian, Ubuntu and I think openSUSE by default, but won't work on SELinux distros like the Red Hat family, or on machines where AppArmor is on by default at the distro level but has been disabled locally).
For Flatpak, the portals rely on the fact that Flatpak sets up the app's mount namespace in a specific way, with a file /.flatpak-info describing which app this is, in a way that individual apps are not allowed to override.
It would be entirely possible to design a third set of conventions for how app identity works, teach the portals to look for those, and build a non-Flatpak convenience layer around bubblewrap that uses this third set of conventions - but nobody has done this yet, because the people doing the work are sufficiently happy with either Flatpak or one of the other frameworks that already exist.
bubblewrap is mechanism rather than policy, and is a relatively thin and user-unfriendly mechanism layer, because in some system configurations (notably, older Debian and older RHEL) it needs to be setuid root, making it important to minimize the amount of code in it to keep its attack surface small (Firejail is a sandboxing layer that does a lot more than bubblewrap, and it pays for this with the number of root privilege escalation CVEs in its history). If what you want is a non-Flatpak sandboxing mechanism based on bubblewrap, then you're going to need policy and convenience layers similar to the ones in Flatpak.
Posted Jul 9, 2022 15:25 UTC (Sat)
by bluca (subscriber, #118303)
[Link] (2 responses)
Posted Jul 10, 2022 10:15 UTC (Sun)
by smcv (subscriber, #53363)
[Link] (1 responses)
Posted Jul 10, 2022 10:31 UTC (Sun)
by pabs (subscriber, #43278)
[Link]
Posted Jul 9, 2022 11:07 UTC (Sat)
by daniels (subscriber, #16193)
[Link] (1 responses)
'It is common for applications to run suid root and for users to chmod 777 whether they need it or not, to the point that some see UNIX's security claims as being more hype than reality.'
Posted Jul 10, 2022 4:44 UTC (Sun)
by dvdeug (guest, #10998)
[Link]
Posted Jul 9, 2022 12:39 UTC (Sat)
by bojan (subscriber, #14302)
[Link] (13 responses)
Anyhow, the regular FF profile did not get picked up - everything was under ~/.var. There are probably tricks I'm not aware of to get this installed differently. Or not. No idea.
But, if this was a regular user, just looking for the latest FF in a format that is not a tarball - sure - they could get it pretty easily. I didn't test for long, but it looked and behaved just like regular FF at first glance.
Posted Jul 11, 2022 1:11 UTC (Mon)
by bojan (subscriber, #14302)
[Link] (12 responses)
Reminds me of those articles written by Urlich Drepper: https://lwn.net/Articles/250967/
Did we collectively forget about all that?
Posted Jul 11, 2022 11:08 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (11 responses)
The tradeoffs changed considerably in the 15 years since Ulrich wrote that series of articles, such that wasting memory isn't as big a deal as it used to be.
In 2007, low end brand new systems came with 2 GiB of RAM, and the population of common PCs would include a significant number with under 1 GiB of RAM; going beyond 4 GiB was the realm of high-end systems. A comparable new system now has 8 GiB of RAM, and very few PCs still in use have under 4 GiB, while you have to go beyond 32 GiB to get into the realm of high-end systems.
Memory throughput has kept pace with memory size; in 2007, top end memory was DDR3-2133 with a throughput of 17 GB/s per DIMM, while common memory of the era had a throughput around 6.4 GB/s per DIMM. Today, common memory is DDR4-2666, with a throughput of 21GB/s per DIMM, while top end memory is DDR5-7200 at 57.6 GB/s per DIMM.
At the same time, the jobs we want our systems to do haven't changed much in that time; the only thing that's had significant growth is framebuffer sizes, which have gone from typically 3 MiB for a 32bpp 1024x768 framebuffer to 8 MiB for a 1920x1080 framebuffer or 32 MiB for a 4K framebuffer. If your workload fitted comfortably in 2 GiB RAM in 2007, then it'll need at most 4 GiB RAM (allowing for the expansion in framebuffer sizes) in 2022, but your system almost certainly has 8 GiB or more RAM.
That, in turn, means much more room to waste RAM than in 2007 - there's 4x the RAM to play with, but most users haven't doubled the amount they want their system to do.
Posted Jul 11, 2022 11:55 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
4GB - are you sure? I'm not sure how long my wife has had her new laptop - a year or two? - and your typical cheap laptop then was still only 4GB. A quick look on the Currys website implies that's still the case - loads of brand new laptops with 4GB.
Cheers,
Posted Jul 11, 2022 12:14 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (1 responses)
Under 4 GiB; most machines sold in the last couple of years have 4 GiB or more RAM.
Posted Jul 11, 2022 12:35 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
I make sure my machines now have more :-) But even 4GB is still tight as a Windows machine ages - it just gets horribly slow.
Cheers,
Posted Jul 11, 2022 11:56 UTC (Mon)
by bojan (subscriber, #14302)
[Link] (7 responses)
Brute force approach, which is essentially what is going on here, is almost always wrong.
Just take the example of that FF flatpak installation. Most of the stuff that was installed as a runtime already existed on my system and was likely loaded into memory.
Distributions would be better off spending time on making sure things work across them. I don't know - maybe even consider having one packaging system that doesn't bring in tons of duplication when this is not necessary. Surely, over this many years, sufficient lessons have been learnt by the likes of Debian, Fedora, Ubuntu, SUSE etc. to allow some kind of cooperation.
When Linux distributions started, there was no cloud and having a build system for cross distro applications was not easy. Today, if major distributions started talking to each other about unifying some of the stuff, everyone would walk away a winner. Without the need for all this duplication.
If things were made accessible enough, even proprietary vendors like Google, Adobe, Microsoft etc. could easily build their own stuff there.
Runtimes are generally a good idea. Every OS already has one. Why not target levels of those instead? Distributions have been doing it for years individually anyway.
In the end, what's the point of me running F36, for example, if some random package delivers some other obsolete junk along with it?
Posted Jul 11, 2022 12:28 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (6 responses)
Caches have also grown, however, so while the absolute efficiency has gone down, the proportion of the cache that's inefficiently used has not.
Intel's 10th Generation Core processors are still current (despite the 11th and 12th generation existing), and have typically 8 MiB or 12 MiB of LLC (plus higher levels that are affected more by working set size than by total size); in 2007, the Core 2 Duo was the latest hotness, with 2 MiB of LLC (plus higher levels).
All the resources have grown significantly since 2007, and thus the "ideal" tradeoff point between needing infinite human time to get minimum resource usage, and needing infinite resources to get minimum human time has moved.
Posted Jul 11, 2022 13:42 UTC (Mon)
by bojan (subscriber, #14302)
[Link] (1 responses)
Installing another copy of, for example, mesa, on a system that already has one is simply sub-optimal. The only reason this is supposedly required in an open source ecosystem is because people refuse to come together and co-operate. And that will always be to everyone's detriment.
I understand that flatpak developers are trying to solve a real problem, which is amazing fragmentation of the open source ecosystem. The current result, unfortunately, has pretty serious side effects.
Posted Jul 11, 2022 15:31 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
But the underlying shift is that because resources have become more abundant, it's easier to consume extra resources than it is to solve the social problems within the ecosystem - requiring people to have at least 3 GiB RAM has gone from "rules out most people" in 2007 to "virtually everyone meets this requirement" in 2022.
So that moves the balance point for what sub-optimal technology decisions you can accept in order to allow you to avoid dealing with people who aren't constructively helping. It would be nice if everyone involved in open source was constructive, but unfortunately, there exist people in all walks of life who consider it more important to be "right" by their own definition than to be constructive.
Posted Jul 11, 2022 13:45 UTC (Mon)
by rbtree (guest, #129790)
[Link] (3 responses)
Oh god.
One of the of most significant advantages of Linux always was how efficient it is and how well it runs with limited computing resources. Personally I'm mostly using it on a desktop with i5-4460, and it runs as well as it did in 2014.
In my country, a lot of low-powered *new* laptops are beind sold to this day. Things with CPUs like Celeron N4020, 4 GBs of RAM, and HDDs, and people are buying them en masse because what else are you going to buy with a salary of $200-300 a month after taxes (which is what a cook or a construction worker typically makes)?
Teachers, doctors, and bureaucrats of all sorts are not doing much better.
Windows is pretty much unusable on those kinds of machines (although people are doing that and it's painful to watch). I'm sure there will be some distributions that will not go down the flatpak road and will still care about performance, but if all the popular ones do that, I'm afraid I will have nothing to recommend anymore (you're not going to recommend some student's side project that may be announced EOL a couple of days from now to a newbie).
Posted Jul 11, 2022 13:59 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Jul 11, 2022 14:41 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
The comparison is even more stark if we move down from the high end CPUs to the low end; back in 2007, if you were in the market that today buys a Celeron N4020 (4 MiB LLC) with 4 GiB RAM, you'd have been buying a Celeron 365 or equivalent, with 512 KiB (0.5 MiB) LLC, and 512 MiB or 1 GiB of RAM.
Indeed, the gap between "as cheap as possible" and "low end for rich customers" machines has been shrinking over the last 15 years; you've gone from having 1/4 the RAM and 1/4 the LLC in an "as cheap as possible" machine as compared to "low end" to 1/2 to 1/3 the LLC and 1/2 the RAM of a low end machine for a rich person. The remaining gap is in mass storage - where a "low end" machine will have an SSD nowadays, a "cheap as possible" machine will still have a HDD because of the size differential between a $30 HDD and a $30 SSD.
That said, that gap may change, too - HDDs are limited in terms of how cheap they can be because they are precision mechanical systems, where an SSD scales down in cost; it was already true 8 years ago that if 30 GiB is sufficient space, an SSD was a cheaper option than a HDD, and the space on really cheap SSDs is likely to grow over time.
Posted Jul 11, 2022 21:01 UTC (Mon)
by bartoc (guest, #124262)
[Link]
Posted Jul 9, 2022 13:08 UTC (Sat)
by alonz (subscriber, #815)
[Link] (13 responses)
This would behave more like the iOS permissions model (also adopted by newer Android versions) - the user will allow/disallow access to dangerous permissions when they actually have some context, rather than blindly at install time.
Posted Jul 9, 2022 13:19 UTC (Sat)
by pabs (subscriber, #43278)
[Link] (12 responses)
Posted Jul 9, 2022 15:22 UTC (Sat)
by smcv (subscriber, #53363)
[Link] (11 responses)
For networking specifically, it's rather all-or-nothing: bubblewrap can either keep the app in the same network namespace as the real system (meaning it can do arbitrary TCP/UDP), or unshare the network namespace (meaning the app can only access its own private loopback interface). At the low level where bubblewrap operates, there's no middle ground available. If someone puts in the necessary work, it might be possible to unshare the network namespace and then put in a filtering proxy between the app's netns and the real system using something like slirp4netns, but that filtering proxy is going to have to make authorization decisions based on the minimal amount of information that it can screen-scrape from what it sees.
The UI for portals tends to work best in terms of being user-comprehensible when they're acting at as high a level as possible, because that gives them the information they need to do their jobs, rather than having to try to reverse-engineer what an app is trying to do from the low-level actions that it carries out.
One thing that can be particularly problematic is when an action has traditionally been quick and not involved any decisions or user interaction, so an application would traditionally have done it synchronously, but a portal needs to intercept it and get a decision. For instance, this is one of the reasons Flatpak has a static permissions mechanism to allow or deny access to the home directory, instead of making all file I/O interactive by putting a FUSE filesystem between the app and the real storage: if it did that, then many apps would end up frozen and unresponsive (not even able to respond to routine Wayland/X11 messages like copy/paste, window movement, or being closed) while blocking in an open() that had resulted in the user being prompted.
Posted Jul 9, 2022 15:42 UTC (Sat)
by jafd (subscriber, #129642)
[Link] (10 responses)
Now, network. Since we’re using portals for many things and it’s ok, can we also use them for the network access? Since we can have per-program network namespace, every program can have a veth interface which can be firewalled as tight as we like it. Can we have and enforce the HTTP/HTTPS access via the portal only, which can grant it with the desired granularity (obviously, the portal needs to know the URLs to make decisions, thus a separate API for HTTP(S))? As the rest of the protocols goes, we could instead firewall it at the veth interface.
An added benefit could be that some apps which, say, spin an HTTP server internally for IPC or whatnot, could do so very privately. The protection could go both ways.
The latter is important because even at Apple they have realized that LAN access for any random app out there can be a vector attack, and LAN connection is a special kind of permissions now.
Posted Jul 9, 2022 17:48 UTC (Sat)
by atnot (subscriber, #124910)
[Link] (9 responses)
Much like on Android, files and directories should primarily be opened through the portal interface. This will open a native file chooser interface for the user and then only expose those files and directories to the app. If you are using Qt or GTK this will work automatically without any extra code. There are also more fine-grained filesystem permissions available[1], e.g. "xdg-config/appname:ro" would share the user's config for your app as read only. The mechanism is definitely there and many applications do use it.
However it is true that in practice there are a few policy caveats: For one, most applications were written without filesystem sandboxing in mind and few application developers are really willing to put in much effort to support them. Just blasting a big hole in the sandbox is an easy way to get the errors to disappear. Secondly, because these permissions are too cryptic for most people to understand, they are automatically granted at installation time. So unless you carefully audit every permission with a tool like flatseal, you are only as protected as the maintainer of the package wants you to be. However, these policy decisions are easy enough to adjust later, the important thing is that being opt-in, they can be changed now.
> If I have an app I trust, I don’t need flatpak, goes without saying.
With such a strictly binary model of trust, I presume might also be choosing to run all of your processes as root on a nommu kernel. In that case Flatpak will definitely not help much.
[1] https://docs.flatpak.org/en/latest/sandbox-permissions.html
Posted Jul 9, 2022 18:48 UTC (Sat)
by jafd (subscriber, #129642)
[Link] (7 responses)
Why "all"? I meant that in my current workflow where I run programs as curated by, say, Fedora maintainers, I can have reasonable trust in those programs not accidentally stepping all over my files, and thus sandboxing offered by flatpak is not, strictly speaking, needed. They add nothing.
> Secondly, because these permissions are too cryptic for most people to understand, they are automatically granted at installation time. So unless you carefully audit every permission with a tool like flatseal, you are only as protected as the maintainer of the package wants you to be.
But wait, isn't flatpak there for my security? I thought it was being made specifically so we could run potentially untrusted code without it doing much harm? And now I learn that not only security is optional, but it's fully in the hands of this untrusted maintainer, and those permissions will just... be silently granted. What you said just effectively negated each and every privacy- and security-related benefit flatpak might have.
Posted Jul 9, 2022 19:40 UTC (Sat)
by atnot (subscriber, #124910)
[Link] (6 responses)
Chosing not to pester the user with permission prompts at installation time is just a pragmatic policy choice that accounts for the realistic user risks, the degree to which most applications can actually be sandboxed on linux in the first place (anything with access to X or pulseaudio is right out) as well as the risk of developers refusing to support flatpak or people deciding it's a bigger hassle than just downloading random binaries off of websites instead. If flatpak is succesful enough, it is easy to just enforce stricter policies during installation, the metadata is already there.
Posted Jul 9, 2022 19:51 UTC (Sat)
by jafd (subscriber, #129642)
[Link] (5 responses)
For example, software business gets bought and sold. What if the alignment of the current owner is not the same as that of the previous one?
X.0 software is ok, X.1 carries adware in addition to its useful functionality.
A software which is demanded by an employer is, in addition to providing stated functionality, invades privacy in numerous ways. (Zoom is an example of software which is walking a very fine line between being useful and falling into total shoddiness, and is required by many.)
A program starts carrying, say, Facebook SDK.
In the world of mobile (and maybe Windows), where there is proliferation of apps, you hit these bad apples all the time. Flatpak is after the same kind of apps proliferation, so you can expect all antipatterns known in App Store/Play Store to also appear there once they succeed.
But I get it, learning from past mistakes and current mistakes of the competition is *hard*. Let’s grow, let’s hype what we don’t have, let’s fix it later or maybe never.
Posted Jul 9, 2022 20:39 UTC (Sat)
by atnot (subscriber, #124910)
[Link] (4 responses)
Please do tell me what your alternatives are. Offering a grand selection of five GNOME apps? Giving users alert fatigue by showing a big red banner for every large application? Hosting broken applications and ensuring the users' next course of action is purging Flatpak? (Snap has been very good at that.) The Flatpak developers coming in and personally porting every codebase to Wayland and Portals (including proprietary ones like Zoom)? I disagree, Flatpak definitely learned from competitors like UWP in what happens if you try to force people to do things your way overnight.
I get that you want Flatpak to be more than it is. I agree that what you're describing would be wonderful. But what I also see is that it is already a significant increase in security for the average user over what we have right now and lays the technological foundations for it being even more secure in the future. I'm willing to cut it some slack on the things it needs to compromise on to get us there.
Posted Jul 10, 2022 5:05 UTC (Sun)
by jonesmz (subscriber, #130234)
[Link] (2 responses)
Every single one of the security benefits claimed by flatpack could be provided by traditional packaging systems like dpkg and rpm as an incremental improvement to those packages.
So why flatpack in the first place, if it comes with all this enormous baggage?
Posted Jul 10, 2022 7:41 UTC (Sun)
by pabs (subscriber, #43278)
[Link]
Posted Jul 10, 2022 8:31 UTC (Sun)
by atnot (subscriber, #124910)
[Link]
Sure, but are they doing it? Almost universally no, because this kind of sandboxing for linux GUI applications requires a lot of additional work, metada, code changes and considerations and distros don't see a need. As far as I can tell, Flatpak have been the only ones driving these features. It does happen a bit for system services though thanks to systemd's sandboxing features. But getting every maintainer to turn them on has been hard.
If you want to change that go ahead, it would be great!
> So why flatpack in the first place, if it comes with all this enormous baggage?
The primary goal is to make it easier to target applications at Linux. The biggest demographic of Flatpak developers, afaict, is KDE and GNOME developers who were annoyed by the amount of work required to get your application onto every distro and inability to deliver speedy updates. Isolation and sandboxing are just implementation details to make that less haphazard.
Posted Jul 10, 2022 12:18 UTC (Sun)
by jafd (subscriber, #129642)
[Link]
Learning from the mistakes of the competition is hard. But it’s also vital.
I wouldn’t have anything against distributions just being honest: we adopt and push flatpak on everyone because maintenance of packages is hard and we don’t want to be doing it. Flatpak is also slightly better at removing stuff you don’t need without leftover files. Okay. I can understand that.
This brings us more or less to the level of Windows 7 security where you download all sorts of crap from the internet, and the publisher has the final word.
But offering a sandbox that doesn’t quite protect you, and claiming “hey it’s better than nothing” is vile. It doesn’t provide anything more than a false sense of security. Like a counterfeit bulletproof vest.
Posted Jul 13, 2022 13:36 UTC (Wed)
by grove (guest, #1721)
[Link]
Posted Jul 9, 2022 20:40 UTC (Sat)
by rcampos (subscriber, #59737)
[Link]
I would really like to see more ways to gain that confidence back when using flatpak. But I lack good proposals on how to tackle it.
Posted Jul 10, 2022 20:22 UTC (Sun)
by jdulaney (subscriber, #83672)
[Link] (4 responses)
Posted Jul 11, 2022 12:36 UTC (Mon)
by smoogen (subscriber, #97)
[Link] (2 responses)
1. New people hate dealing with the old way of doing things and want to do something different.
Having now lived through different developer generations who have practiced the following:
I expect that we will go through various solutions until curated containers will be replaced by the next 'tarball' layer.. probably someone's uploaded datacentre.
Posted Jul 11, 2022 16:19 UTC (Mon)
by atnot (subscriber, #124910)
[Link] (1 responses)
This sort of bundling and unbundling cycle has been going on forever in all sorts of places. I could just as easily shift your argument by half a wavelength and then I'd be grumbling about how the young ones refuse to see the hard learned benefits of bundling instead (it might sound a bit like someone complaining about npm).
It sure is a lucky coincidence that the generation of tools you grew up with and are most used to happen to be the ones where the cycle ends, we Finally Got It Right, made the perfect tradeoffs and there is little left to improve upon (:
Posted Jul 11, 2022 16:41 UTC (Mon)
by smoogen (subscriber, #97)
[Link]
I also did not come in when the tools were right, I came in when everything was unbundled and you downloaded various 'tarballs' from websites and hoped it worked on your system. I then went through most of the joys of 'oooh I get this so much faster and easier' to 'ooooh I get to rebuild all this and make it work the way I want it' to 'ooooh now I have to figure out how I made this 6 months ago because the backups ate themselves and I need to restore this site.' Each of them had their own positives and negatives. Each had their 'stop talking at me old person, just because you had problems then doesn't mean I will now'
Posted Jul 11, 2022 22:07 UTC (Mon)
by eean (subscriber, #50420)
[Link]
Posted Jul 11, 2022 8:58 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link]
rpm packages could come with their profile and that's it. It'd be quite easy to change and inspect.
Posted Jul 12, 2022 13:27 UTC (Tue)
by amarao (guest, #87073)
[Link] (6 responses)
It adds latency and makes output of mount/DF crazy long.
... And sandbox is sounds like chlorination for chickens. You keep chicks in unsanitary conditions and then wash them with chlorine. Or you ban chlorination and vendors are forced to vaccinate chicks and keep them in sanitary conditions.
Having sandbox for trusted apps sounds like 'not trusting apps'. And I don't want to have to hide my address book from my image editor. It's so unsanitary!
Posted Jul 12, 2022 14:24 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
I agree in general. However, the world is not so nice in reality. I *do* want to hide it from Zoom and Teams because my trust for these is quite low. I don't know how to do this without some kind of sandboxing.
Posted Jul 13, 2022 4:36 UTC (Wed)
by amarao (guest, #87073)
[Link] (3 responses)
Posted Jul 13, 2022 18:22 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Jul 14, 2022 8:54 UTC (Thu)
by amarao (guest, #87073)
[Link] (1 responses)
Insofar I got no specific issues with FF/Linux with web applications for video. (Except for some antique Cisco solution with no linux support whatsoever).
Posted Jul 17, 2022 13:08 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 12, 2022 15:27 UTC (Tue)
by jafd (subscriber, #129642)
[Link]
But you do end up with multiple shared libraries from different runtimes keeping being loaded again and again, so startup time won’t be negligible anymore.
And yeah, this is my beef too. You work hard so with PIC binaries all over the place you don’t need to play with relocations anymore, now filesystem cache and mmap() can work about as well as it gets, and then you ruin it by making all executables bring their own slightly different versions of shared libraries. There have been times that RAM and storage and electricity seemed cheap and getting even cheaper; sorry, looks like these times are over.
Posted Jul 12, 2022 15:24 UTC (Tue)
by civodul (guest, #58311)
[Link] (1 responses)
The whole “immutable core” thing also looks like poor engineering: does one really want to keep all the low-level software stack frozen in time?
I think we, free software folks, need to address the lack of flexibility of traditional distros that make opaque solutions like flatpak appear necessary. We need to let users know that their autonomy and privacy are at stake (and ours, collectively), let them make informed choices, and design distros for practical user freedom. To me this is very much the mission of Guix.
Posted Jul 13, 2022 15:07 UTC (Wed)
by muep (guest, #86754)
[Link]
What is nice is that building the updated core environment does not require changing the current one. If the newly booted new environment shows regressions compared to the old one, I can reboot back into the previous environment.
Posted Jul 12, 2022 20:21 UTC (Tue)
by madscientist (subscriber, #16861)
[Link]
pro: Emacs 2.28.1 snap allows me to have the latest Emacs very easily (I used to use a PPA but that was not always updated to the point releases etc.) At least with Emacs it's easy to build myself, but if I don't need to then so much the better. Packaging FTW!
con: Ubuntu used to use a snap for the Gnome Calculator app: it took like 3 seconds or more to start which was ridiculous; when you hit the calculator key on your keyboard you don't want to be waiting for multiple seconds for it to appear. Packaging fail! (this was changed back again since BTW)
con: Emacs flatpak is completely useless (for me) because you can't access binaries outside the flatpak except by going through contortions with flatpak-spawn: I invoke all sorts of applications from inside Emacs such as spell checkers, LSP daemons, terminals, ssh, etc. etc. Packaging fail! (the Emacs snap installs in "classic" mode which avoids these sandbox issues).
So, there are good places to use packages like flatpak and snap, and bad ones.
Posted Aug 21, 2022 1:46 UTC (Sun)
by Curan (subscriber, #66186)
[Link]
And – as a user – there are some applications (proprietary) I'd really love to lock into a very special sandbox, eg. stuff like Steam. Yes, I want to play whatever game I chose, but no, I don't want those to give access to my system.
So in summery: for everyday applications I want my distribution's (Debian's) binaries or a custom rebuild. But for proprietary stuff I do want to lock them into a tightly controlled sandbox, that Flatpak can provide.
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
[2] https://buildbot.flathub.org
[3] and large language package managers, and source code hosting websites
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
[2] https://github.com/flathub/org.bunkus.mkvtoolnix-gui
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
* Anyone who is realistically going to exercise any of the four freedoms (other than freedom 0) is also in a position to figure out what "GPL" or "MIT" mean.
* It would be nice if they had a link to the license or something like that.
* Many end users do not care to exercise the other three freedoms, and may see a big "this is proprietary" banner (or, worse, an outright segregation of proprietary software into a separate results page by default) as a nuisance.
* The modern web has done a very effective job of training users to obstinately ignore any component of the page that is not related to their current task, on the assumption that it's probably trying to sell them something or harvest their email address. You can put up a banner, but they won't read it.
* Annoying end users is not an effective means of advocacy. They didn't write the proprietary software, nor are they personally responsible for its market dominance.
Distributors entering Flatpakland
Distributors entering Flatpakland
code. A large fraction of people will know some basics. Practical
software freedom is useful and important.
just one command to download and two to build, can get sources to any
package in the entire trisquel repo, make a small change, and run the
result. They are amazed and inspired. Someone in these comments told me
a command to download flathub sources from, but it doesn't seem to be
documented anywhere, and I don't know how to build them. So, I still
consider this a major regression from free packages in debian based
distros and I'm going to avoid it in general.
Distributors entering Flatpakland
Wol
Distributors entering Flatpakland
apt-get source xxx
[do your thing]
dpkg-buildpackage
Distributors entering Flatpakland
> apt-get source xxx
> [do your thing]
> dpkg-buildpackage
Wol
Distributors entering Flatpakland
However many other packages are more manageable. My wacom was triggering a zoom event by accident on some drawing program, which was pretty annoying, and there was no config option to disable this behavior. But it was on a debian based distro, so getting the sources, searching "wheel", commenting out the wheel event and rebuilding the package was quite straight forward.
Distributors entering Flatpakland
Distributors entering Flatpakland
* yep, and I think flathub lists SPDX identifiers too, so you can distinguish between GPL-2.0-only and GPL-2.0 or GPL-2.0 only or GPL-3.0 only and so forth.
* Yeah, many users might, but on the other hand they are using a free platform with (extremely importantly) a free "appstore" and distribution mechanism.
* Yep, and perhaps many non-technical people will want to use a free platform because they want to escape from having the platform try and sell them things, especially things sold by the platform vendor.
* I agree, and I think flathub and the gnome-software experience do a pretty decent job, the banner is a pretty simple red indicator in the "app details"
> I want to know, for any flatpak package, how to download the source, and build a possibly modified version.
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
deb and rpm packages (delivered by various commercial providers and/or parts of lesser-known distributions) come without source.Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Security is not one of them
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
> This should be a standard feature.
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Wol
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Broken link:
Page not found (404)
With the message:
Project not found
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
- runtimes are curated by the store maintainers and tightly maintained (and prevented from proliferating), and JoeRandomDev is not allowed to upload a runtime
> But I think it would have been worth it to end up with a much cleaner, healthier and safer ecosystem overall.
Distributors entering Flatpakland
.deb and .rpm based approaches, too.Distributors entering Flatpakland
Distributors entering Flatpakland
I would much prefer a mechanism based on transparency, rather than blunt enforcement:
Distributors entering Flatpakland
Sure, some users will just ignore these warnings. But some will not, and this could be an effective hammer to force packagers to behave more responsibly.
Distributors entering Flatpakland
Can the runtime be upgraded?
Can the runtime be upgraded?
Can the runtime be upgraded?
Distributors entering Flatpakland
https://wiki.debian.org/BisectDebian
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Wol
Distributors entering Flatpakland
Distributors entering Flatpakland
Wol
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Wol
Distributors entering Flatpakland
Distributors entering Flatpakland
Is it possible for the Flatpak container (bubblewrap IIUC?) to always block file/network access (and maybe also mic/camera), and to open them on-demand when the app attempts to open a file/socket/device?
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
2. They build a bunch of tools in a new way and pile out their repositories with all those things.
3. Older people point out that their will be problems and if they did this or that they would be better off.
4. New people usually respond with 'this time it will be different.'
5. It isn't different and then the generation afterwards comes up with a curated method to deal with the pile of software.
6. They build businesses on this and get settled into their ways.
7. Goto 1.
download someone's prebuilt tarball and install it. Cant fix the code so suffer
download someone's source code and build it
upload that code to some central place for people but then find ftp site full of crap
come up with debs and rpms to help deal with updates and see what was built with built
find that ends up with dependency hell
come up with apt/yum/etc to deal with dependency hell
find out that people are building repos willy nilly and stuff is now broken between repos
try to figure that out with modules and other tooling
decide that all that is too much work and pile up all the prebuilt code into a container.
...
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
As the author aptly notes, it was clear from the start that the very design of flatpak is appealing to proprietary software vendors—unlike traditional distros, which were designed for free software and make it easy to exercise user freedoms, for example with apt-get source. Flatpak’s web site has advertised proprietary apps on its front page for a while now; it should come as no surprise that distros that support it will now provide proprietary software without letting users make informed choices.
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland
Distributors entering Flatpakland