💾 Archived View for ruario.flounder.online › journal-extract-2023-11-11-2227.gmi captured on 2023-11-14 at 07:43:12. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I am currently working on getting Vivaldi Browser onto Flathub, which involves creating the various files to convert our .deb package to flatpak format.
Add com.vivaldi.Vivaldi #4422 (flathub)
This has been ongoing for a while now (several months), largely because I keep on procrastinating and doing other stuff instead. But it looks like I am close now. It is a weird why it takes so long. I am not procrastinating because I am not capable of doing it… I just don't wanna and there is always something else I could be doing! 😆
In the past, I have actually done software packaging for Arch, Slackware, .deb, .rpm and created various shell based installer/uninstall scripts. I even had a play around with AppImage and Snap packaging at one point (though never published anything publicly using either). Oh and I have also written guides to removing software that was installed from source.
'make install', uninstall help
During all of this I have spent time reading lots of packaging guides, along with both the Filesystem Hierarchy Standard (3.0) documents and the XDG Base Directory Specification.
XDG Base Directory Specification
In short, while I would certainly not claim to be an expert, I am also not a total newb either. Still I find Flatpak annoying. Part of it is because of the sandboxing considerations (I get why they are a good thing but they are annoying from a maintainer perspective) but also just because I am not totally sold on the whole concept. I am not a fan of bundling of all dependencies with the app or the idea of a new cross distro packaging standard to replace them all. Firstly I do not believe that will ever happen on Linux and also, right now it is not "readily available" or "easily installable" on "all distros", despite multiple what the fanboys say. Indeed they only say that because their concept of an alternative distro is running Mint or Fedora, rather than Ubuntu. I also get a strong xkcd "standards" vibe.
There is an extra problem for me in addition. Vivaldi is based on Chromium and the Chromium sandbox and the flatpak concept of sandboxing do not play nice together. Again I will not profess to be an expert but nonetheless see my comments from the vivaldi.net forums in answer to questions about why Vivaldi is the only browser company without a flatpak—Spoiler: It isn't. There are NO "official" flatpaks for ANY Chromium based browser and in fact Firefox is the only "major" browser that has an "official" flatpak, last I checked.
My reply to "make a flatpak" on the Vivaldi Forums (21 May 2023)
Security is also harder on flatpak for Chromium based distros. You must replace the Chromium SUID sandbox with zypak, which is maintained by [AFAICT] a single person and in addition the SUID sandbox is a fallback in the first place, happening only because the namespace one cannot be setup by Chromium when running under flatpak.
There is a reason there is not a single officially maintained flatpak from the Chromium browser manufacturers.
That is not to say we will not do it (I need to spend more time looking at this). I have made a flatpak internally whilst testing which is why I became aware of all of this. 😉
My follow up reply on why no Vivaldi flatpak (24 May 2023)
Firefox does not contain the same sandboxing mechanism that Chromium does, so the fact that they have an official app is basically irrelevant. I presume because they do [something] differently [and] do not hit the same problems that Chromium apps do, which I will expand on now.
So let's start by saying that the Chromium sandbox is actually very good and it is fully [interprocess]. flatpak's "sandboxing" is typically only used to [separate] the app (in our case Vivaldi) from other apps and/or from parts of the OS. In Chromium if you load facebook in one tab it cannot get access to the process that runs youtube in your other tab.
But the Chromium sandbox needs greater integration with the OS and the attempts by flatpak to handle sandboxing clashes. Thus all the Chromium browsers and Electron apps use a hack (Zypak) which fakes part of the chromium sandbox.
In short, Flatpak doesn't allow important parts of the Chromium sandbox to work as intended by the Chromium team, when running under Flatpak. So you either end up with no internal (interprocess) sandbox or one which is replaced with something potentially weaker and certainly less well understood and tested. Zypak is maintained by a single person. Those responsible for the Chromium sandbox are a whole team.
I do not currently feel confident that you aren't actually getting less security trying to run a Chromium based app in flatpak. I also strongly suspect this is why you are not finding a single official flatpak by any Chromium based browser. Either they decided it is less secure or they suspect it might be and do not want to take a risk.
If we made this official we would be saying this is Ok and my gut tells me it really is not!
So … wait… why am I creating a flatpak on flathub for Vivaldi? Well, the users never stop requesting it even if they could use an official package or their distro of choice provides a nice repack. I suspect many of them ask because they are convinced it is more secure and safer, even if it might not be (nobody told them that was a possibility). But… since they ask my boss and our marketing team really wants us to support flatpak.
As a compromise I decided to put one out as myself and clearly label it as "non-official" (even though I am a Vivaldi employee who helps maintain our official Linux packages). This is not unprecedented. For a little while I unofficially maintained Vivaldi for Arch Linux and I still maintain Vivaldi for Slackware (via Slackbuilds).
Vivaldi on the SlackBuilds Repository
So this is an experiment to provide something on par with what is available for the other Chromium browsers (Chrome, Edge, Opera, Brave, etc.), for which there are non-official flatpaks (albeit none of them are maintained by employees of their respective companies AFAIK). It also makes it easier for me to walk away from it turns out to be a bad idea. So in summary, I am working on it… but I still recommend you use a different package type if one is available to you. 😉
⁂