Can I ignore flatpak indefinitely?
-
Adopt
nixand you will be able to ignore it forever!
Seriously though, as others have said, use whatever fits you best. I avoided snaps and flatpaks due to the increased size requirements. So many things were duplicated for no apparent benefit (to me). However, with their introduction of permissions and portals, it does seem like a safer option. Although, we're in a phase right now where not everything is flatpakked and applications trying to talk to each other is a pain (keepassxc unable to talk to flatpak
firefoxlibrewolf, chromium, etc.).Now that I use nix, I have a whole bunch of other problems, but at least getting packages is quite low on the list.
Thanks for the suggestion. I am interested in nix, but haven't explored it yet.
-
Do you have a resource I can take a look at for what this implies at what it accomplishes?
Sure, here are some:
http://security.stackexchange.com/questions/259088/ddg#270934
https://en.wikipedia.org/wiki/Digital_signature
The main feature would be that if flathub (or a hacker with access to flathub) acted maliciously, digital signatures would prevent them from issuing malware infested updates to flatpaks. Only the software's originator would have the cryptographic key needed to sign releases of the software.
-
Thanks for the suggestion. I am interested in nix, but haven't explored it yet.
I wasn't being very serious about
nix. IMO, it's quite the time investment due to its poor documentation and it has a lot of gotcha's if you aren't on NixOS e.g one example is that it's great for terminal applications, but horrendous for GUI applications as it'll be hit or miss. Again, this is if you're not on NixOS. So, it can feel like an "all or nothing" approach.If you have the time and will, then it can be very rewarding. But if you just "want something that works
" side by side in your current system, personally, I wouldn't recommend it - unless it's hidden by some other tool like devenv(which is a great tool for reproducible developer environments). -
I'm admittedly yelling at cloud a bit here, but I like package managers just fine. I don't want to have to have a plurality of software management tools. However, I also don't want to be caught off guard in the future if applications I rely on begin releasing exclusively with flatpak.
I don't develop distributed applications, but Im not understanding how it simplifies dependency management. Isn't it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?
Don't maintainers have to release new bundles if they contain dependencies with vulnerabilities?
Is it because developers are often using dependencies that are ahead of release versions?
Also, how is it so much better than images for your applications on Docker Hub?
Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it's something I should adopt, or if I can continue to blissfully ignore.
I never use flatpaks and am doing just fine. I don't want my packages to be installed from a bunch of different places; I want it all managed by one package manager, which for me is my distro package manager. I've never noticed a problem arising out of not using flatpaks; everything I want is either already packaged for me, or I can make a package myself.
-
Another upside is the easy permission management.
You can revoke network access from your password manager to reduce attack surface; you can revoke camera access from your chat app to prevent accidentaly enabling it; You can restrict an App's file system access to prevent unwanted changes; etc.
It's not yet fit to protect from malicious apps, but it still finds some use.
Itâs not yet fit to protect from malicious apps, but it still finds some use.
That it is "not yet fit to protect from malicious apps" is an important point which I think many people are not aware of.
This makes sandboxing something of a mixed bag; it is nice that it protects against some types of incompetent packages, and adds another barrier which attackers exploiting vulnerabilities might need to bypass, but on the other hand it creates a dangerous false sense of security today because, despite the fact that it is still relatively easy to circumvent, it it makes people feel safer (and thus more likely to) than they would be otherwise when installing possibly-malicious apps packaged by random people.
I think (and hope) it is much harder to get a malicious program included in most major distros' main package repos than it is to break out of bubblewrap given the permissions of an average package of flathub.
-
I wasn't being very serious about
nix. IMO, it's quite the time investment due to its poor documentation and it has a lot of gotcha's if you aren't on NixOS e.g one example is that it's great for terminal applications, but horrendous for GUI applications as it'll be hit or miss. Again, this is if you're not on NixOS. So, it can feel like an "all or nothing" approach.If you have the time and will, then it can be very rewarding. But if you just "want something that works
" side by side in your current system, personally, I wouldn't recommend it - unless it's hidden by some other tool like devenv(which is a great tool for reproducible developer environments).Lol thanks for clarifying your sarcasm.
I can be an airhead at times.I was actually interested in trying NixOS on a laptop that is gathering dust. I did see a few months ago that there was some drama surrounding the project owner, though. I never investigated enough to understand what that was all about, but I'm less excited about digging into something if it may suddenly end.
-
This seems to be a dependency failure.
I'm sad that we had this solved 20 years ago. It's like Texas measles.
What do you mean by this? Flatpak definitely solved the Linux distro balkanization problem for application developers without trying to destroy the benefits of having different distros. Having a distinction between system software, utilities, and advanced end user applications does solve a problem.
-
This is what's so great about Linux, you can use whatever the hell you want.
Flatpaks provide some cool security functionalities like revoking network access to a specific application. Maybe you care about this, maybe you don't.
My personal policy is to always install from the repos. Occasionally something is only available in flathub, which is fine for me. I really understand how hard is maintaining something for every single package manager and diatributions and totally respect the devs using a format that just works everywhere. If I were to release a new Linux app, I would totally use flatpak.
Same boat. As a user, I greatly prefer everything to come from the repos. However, as a distributor, Flatpak makes so much more sense.
The only Flatpak I have installed is pgAdmin. I looked at the build on Flathub with the idea of porting the package myself but got scared off. It was a maze of Python dependencies running in Electron. That seems like exactly the kind of thing that may be better off in its own sandbox.
-
Glad it is working well for you. What does that have to do with this post?
no flatpak. chill.
-
Ok, show me how you compile Emacs 29/30 on a fresh Debian 10 install in a few minutes...
-
I'm admittedly yelling at cloud a bit here, but I like package managers just fine. I don't want to have to have a plurality of software management tools. However, I also don't want to be caught off guard in the future if applications I rely on begin releasing exclusively with flatpak.
I don't develop distributed applications, but Im not understanding how it simplifies dependency management. Isn't it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?
Don't maintainers have to release new bundles if they contain dependencies with vulnerabilities?
Is it because developers are often using dependencies that are ahead of release versions?
Also, how is it so much better than images for your applications on Docker Hub?
Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it's something I should adopt, or if I can continue to blissfully ignore.
So far I have also completely ignored them. From what I understand they technically allow you to install old versions of software, potentially having multiple at the same time. This could come in a clutch when working with stuff like Godot or Blender where constantly upgrading to the latest version would cause issues on bigger projects.
This is the only thing I can see myself using them for, at least in the near future. -
Downsides of distro pacakges:
- someone needs to package an application for each distro
- applications often need to maintain support for multiple versions of some of their dependencies to be able to continue to work on multiple distros
- users of different distros use different versions of the application, creating more support work for upstream
- users of some distros can't use the application at all because there is no package
- adding 3rd party package repos is dangerous; every package effectively gets root access, and in many cases every repo has the ability to replace any distro-provided package by including one with a higher version number. 3rd party repos bring the possibility of breaking your system through malice or incompetence.
Downsides of flatpak:
- application maintainers are responsible for shipping shipping their dependencies, and may not be as competent at shipping security updates as distro security teams
- more disk space is used by applications potentially bringing their own copies of the same dependencies
Another downside of flatpak is that I don't trust upstream devs to have my best interests at heart, but I trust Debian developers far more. I've seen upstream do some annoying or stupid shit and the Debian maintainers not budging.
I think it was poppler or evince that decided they were going to enforce the no-copy-and-paste bit you can set on pdfs. Debian patched it out. I've seen Mozilla decide they were going to enforce their trademarks. They carved out special exceptions for various distros but that still would have meant you would have to rename Firefox if you were to fork Debian. Debian had none of it. There were many dodgy copyright and licensing problems upstream devs gave no shit about. Debian not including these often eventually but pressure on them to fix this shit or for some replacement to get developed.
-
I'm admittedly yelling at cloud a bit here, but I like package managers just fine. I don't want to have to have a plurality of software management tools. However, I also don't want to be caught off guard in the future if applications I rely on begin releasing exclusively with flatpak.
I don't develop distributed applications, but Im not understanding how it simplifies dependency management. Isn't it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?
Don't maintainers have to release new bundles if they contain dependencies with vulnerabilities?
Is it because developers are often using dependencies that are ahead of release versions?
Also, how is it so much better than images for your applications on Docker Hub?
Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it's something I should adopt, or if I can continue to blissfully ignore.
If there is nothing appealing on flatpak, then sure. But for me it was really appealing and I still ignored it because you need to download big files at the beggining. But later on i started using it for steam and all because that thing is better staying as user-installed files in some form of permission sandbox
-
Another downside of flatpak is that I don't trust upstream devs to have my best interests at heart, but I trust Debian developers far more. I've seen upstream do some annoying or stupid shit and the Debian maintainers not budging.
I think it was poppler or evince that decided they were going to enforce the no-copy-and-paste bit you can set on pdfs. Debian patched it out. I've seen Mozilla decide they were going to enforce their trademarks. They carved out special exceptions for various distros but that still would have meant you would have to rename Firefox if you were to fork Debian. Debian had none of it. There were many dodgy copyright and licensing problems upstream devs gave no shit about. Debian not including these often eventually but pressure on them to fix this shit or for some replacement to get developed.
I trust Debian developers far more
i definitely agree with you here
I think it was poppler or evince that decided they were going to enforce the no-copy-and-paste bit you can set on pdfs. Debian patched it out.
This is hilarious and I had to know more. First I found this help page which confirms that evince does have code which implements PDF restrictions, but it says that its
override_restrictionsoption is enabled by default. But I wondered: was it ever enabled by default? And who implemented it?Here are the answers to these questions:
- in May 2005, a redhat employee implemented the restrictions in evince in this commit
- in September 2005, a yandex employee added the
override_restrictionsoption in this commit, after discussion in bug #305818 - in December 2006, someone opened bug #382700 requesting that
override_restrictionsbe enabled by default - in January 2008, a GNOME maintainer changed the default in this commit in 2008 - but only after someone showed a maintainer that the PDF spec does not in fact require the restrictions to be enforced. (The spec says "It is up to the implementors of PDF consumer applications to respect the intent of the document creator by restricting user access")
I don't see any indication that Debian patched this out during the time when evince had it enabled by default, but I'm sure they would have eventually if GNOME hadn't come to their senses
Iâve seen Mozilla decide they were going to enforce their trademarks. They carved out special exceptions for various distros but that still would have meant you would have to rename Firefox if you were to fork Debian. Debian had none of it.
In my opinion both sides of the DebianâMozilla trademark dispute were actually pretty reasonable and certainly grounded in good intentions. Fortunately they resolved it eventually, with Mozilla relaxing their restrictions in 2016 (while still reserving the right to enforce their trademark against derivatives which make modifications they find unreasonable):
Mozilla recognizes that patches applied to Iceweasel/Firefox don't
impact the quality of the product.Patches which should be reported upstream to improve the product always
have been forward upstream by the Debian packagers. Mozilla agrees about
specific patches to facilitate the support of Iceweasel on architecture
supported by Debian or Debian-specific patches.More generally, Mozilla trusts the Debian packagers to use their best
judgment to achieve the same quality as the official Firefox binaries.In case of derivatives of Debian, Firefox branding can be used as long
as the patches applied are in the same category as described above.
Ubuntu having a different packaging, this does not apply to that
distribution. -
I trust Debian developers far more
i definitely agree with you here
I think it was poppler or evince that decided they were going to enforce the no-copy-and-paste bit you can set on pdfs. Debian patched it out.
This is hilarious and I had to know more. First I found this help page which confirms that evince does have code which implements PDF restrictions, but it says that its
override_restrictionsoption is enabled by default. But I wondered: was it ever enabled by default? And who implemented it?Here are the answers to these questions:
- in May 2005, a redhat employee implemented the restrictions in evince in this commit
- in September 2005, a yandex employee added the
override_restrictionsoption in this commit, after discussion in bug #305818 - in December 2006, someone opened bug #382700 requesting that
override_restrictionsbe enabled by default - in January 2008, a GNOME maintainer changed the default in this commit in 2008 - but only after someone showed a maintainer that the PDF spec does not in fact require the restrictions to be enforced. (The spec says "It is up to the implementors of PDF consumer applications to respect the intent of the document creator by restricting user access")
I don't see any indication that Debian patched this out during the time when evince had it enabled by default, but I'm sure they would have eventually if GNOME hadn't come to their senses
Iâve seen Mozilla decide they were going to enforce their trademarks. They carved out special exceptions for various distros but that still would have meant you would have to rename Firefox if you were to fork Debian. Debian had none of it.
In my opinion both sides of the DebianâMozilla trademark dispute were actually pretty reasonable and certainly grounded in good intentions. Fortunately they resolved it eventually, with Mozilla relaxing their restrictions in 2016 (while still reserving the right to enforce their trademark against derivatives which make modifications they find unreasonable):
Mozilla recognizes that patches applied to Iceweasel/Firefox don't
impact the quality of the product.Patches which should be reported upstream to improve the product always
have been forward upstream by the Debian packagers. Mozilla agrees about
specific patches to facilitate the support of Iceweasel on architecture
supported by Debian or Debian-specific patches.More generally, Mozilla trusts the Debian packagers to use their best
judgment to achieve the same quality as the official Firefox binaries.In case of derivatives of Debian, Firefox branding can be used as long
as the patches applied are in the same category as described above.
Ubuntu having a different packaging, this does not apply to that
distribution.https://lwn.net/Articles/335415/
The evince PDF reader ran into this issue back in 2005. It is now rare to find a distributor shipping a version of evince which implements copy restrictions. Xpdf implements copy restrictions unconditionally, but Debian patched that code out in 2002, and that patch has spread to other distributors as well. In general, as one would expect, free PDF readers tend not to implement this behavior. Okular is about the only exception that your editor can find; it's interesting to note that the version of Okular shipped with Fedora Rawhide also implements copy restrictions by default. Perhaps this behavior is result of the relative newness of this application; as it accumulates more users, the pressure for more user-friendly behavior is likely to grow.
-
Ok, show me how you compile Emacs 29/30 on a fresh Debian 10 install in a few minutes...
-
https://lwn.net/Articles/335415/
The evince PDF reader ran into this issue back in 2005. It is now rare to find a distributor shipping a version of evince which implements copy restrictions. Xpdf implements copy restrictions unconditionally, but Debian patched that code out in 2002, and that patch has spread to other distributors as well. In general, as one would expect, free PDF readers tend not to implement this behavior. Okular is about the only exception that your editor can find; it's interesting to note that the version of Okular shipped with Fedora Rawhide also implements copy restrictions by default. Perhaps this behavior is result of the relative newness of this application; as it accumulates more users, the pressure for more user-friendly behavior is likely to grow.
I see, it was Xpdf where Debian patched it out in 2002.
Also lmao @ the fact that Okular's
ObeyDRMoption still defaults to true today(Including in Debian, as their KDE maintainer declined to carry a patch to change it.)
-
I'm admittedly yelling at cloud a bit here, but I like package managers just fine. I don't want to have to have a plurality of software management tools. However, I also don't want to be caught off guard in the future if applications I rely on begin releasing exclusively with flatpak.
I don't develop distributed applications, but Im not understanding how it simplifies dependency management. Isn't it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?
Don't maintainers have to release new bundles if they contain dependencies with vulnerabilities?
Is it because developers are often using dependencies that are ahead of release versions?
Also, how is it so much better than images for your applications on Docker Hub?
Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it's something I should adopt, or if I can continue to blissfully ignore.
Just use Nix. It can run all the packages on whatever platform. It has the largest repository of software & are some of the most up-to-date.
-
apt install build-essential apt build-dep emacs wget https://ftp.gnu.org/gnu/emacs/emacs-30.1.tar.xz tar -xf emacs-30.1.tar.xz ./configure âprefix=/usr/local make make installDid I ask for a command? Give that a try in Debian 10...
-
This is what's so great about Linux, you can use whatever the hell you want.
Flatpaks provide some cool security functionalities like revoking network access to a specific application. Maybe you care about this, maybe you don't.
My personal policy is to always install from the repos. Occasionally something is only available in flathub, which is fine for me. I really understand how hard is maintaining something for every single package manager and diatributions and totally respect the devs using a format that just works everywhere. If I were to release a new Linux app, I would totally use flatpak.
But for apps distributed in your systemâs package manager, itâs not the devs that are distributing them in every package manager. Itâs the distribution itself that goes to each repository, checks and tests the dependencies they need and create the package for the distribution, along with a compiled binary version of it.
When they arenât offered in the distroâs package manager (or the version is outdated because the distro isnât rolling release) things become more complicated.
