Make brave available through Flatpak and Flathub

[bsclifton]

Carried over from brave/browser-laptop#11999

Description

Brave should be avaliable through flatpak because it is an alternative to snap that feels better because it is not run by a big company as cononical. Here is a great page with the advantages between the two: https://www.maketecheasier.com/snap-packages-vs-flatpacks/

Current status

With browser-laptop, some good progress was made by @Garbee. As the developer channel becomes mainstream, we'll want to evaluate packaging this version instead

[Garbee]

OK so the new generic linux builds are available on the releases page for this repo. The site currently still links to the old laptop instructions and not the new docs (which conveniently also is missing the generic instructions anyways.)

So what I did for my initial builds, which I will repeat again here with the initial containers, is simply pull the generic build into an image. Copy in the logo and setup a desktop file to run the program and allow it into the system for setting it as a default web browser. Overall pretty straightforward, but the more complex issue to figure out before releasing it is how to handle versioning.

I'm going to have a conversation on how to handle this with other Flathub maintainers. What I'd like to do is have com.brave.Brave be what we install now since all we have is dev builds. Then when stable comes, transition that to being stable-only builds. With a secondary com.brave.BraveDev for the development channel. But I know there are other methods like saying com.brave.Brave//{version/branch} if we only wanted one listing. I don't know the full set of trade-offs between these methods yet, but that is something I am investigating before this goes live.

[x80486]

Hello! Has there been any progress with this one?

[Garbee]

Not on my end. Initially trying to pull up to the new brave-core system I got a package built, but the application would never run enough to show a GUI. It crashed out without any trace of an error. Doing some debug traces didn't yield any significant results either other than a few dead ends.

I've since switched to Hackintoshing my systems, so working on making and maintaining a Flatpak isn't a high priority anymore personally.

[Jacalz]

Is there any news on this? I would love to have Brave available through Flatpak as it would make it work on a lot of different Linux distros. It is especially useful since the Snap app doesn’t have great desktop integration and is slow, which to be fair is a limitation of Snap. Flatpak is also more widely available, fully open source and offers much better desktop integration. A great choice for a privacy minded browser 👍

[Razva]

July 2019, still no Flatpak. Come on guys, be Brave and do this for us! :)

[henk717]

Brave availability is quite poor on Arch, Suse and other smaller distro's.
Flatpak support would be a great universal way of getting this browser on any distro.
The community snap is no alternative, snaps are an inferior technology that are less adopted by the distro's and the community snap is outdated.

[maniadevice]

Flatpak has wider first-class support from a lot of distros. It would be great to have Brave on Flatpak and get Brave a wider audience, that it deserves. Please consider this.

[srirambv]

cc: @rebron @bsclifton to add a priority to this

[bsclifton]

At the moment, we don't have plans to officially support Flatpak/Flathub and other formats.

However, if someone did want to work with us, we can definitely help you get started 😄 The hardest challenge of supporting these additional formats is keeping them up-to-date.

[qnixsynapse]

@bsclifton Hi. Unfortunately the chromium setuid sandbox is not compatible with bubblewrap(flatpak Sandbox). So we need to disable it at the root label without showing any warning. I think this is going nowhere.

[t-nelis]

This document mentions:

The [user] namespace sandbox aims to replace the setuid sandbox. It has the advantage of not requiring a setuid binary. It's based on (unprivileged) user namespaces in the Linux kernel. It generally requires a kernel >= 3.10, although it may work with 3.8 if certain patches are backported.

Starting with M-43, if the kernel supports it, unprivileged namespaces are used instead of the setuid sandbox. Starting with M-44, certain processes run in their own PID namespace, which isolates them better.

The summary also seems clear:

Setuid sandbox [...] Enabled by default (old kernels) and maintained
User namespaces sandbox [...] Enabled by default (modern kernels) and actively developed

Chromium 43 was released in 2015 and Linux 3.10 in 2013.

Now, AFAICT Flatpak would already isolate the full application in a single user namespace, even when --no-sandbox is passed to Chromium (this is independent from contained processes). Yet, Chromium sandboxing isolates some of its subsystems and tabs from each other, and as such requires nested user namespaces. (I haven't validated both these claims thoroughly but I'm somewhat confident it's accurate.) So, in other words: while using --no-sandbox would protect the host from Brave, internal Brave subcomponents wouldn't be protected from each other and this is why Chromium sandboxing is still desirable.

I've confirmed nested user namespaces are fully supported by the kernel, and that since 3.8 unprivileged processes can create them. However, Flatpak and similar systems block this for security reasons (I haven't researched the details yet but given this is widespread and seemingly well discussed upstream it seems legitimate and not an oversight).

Flatpak offers a higher-level API to allow sandboxed applications to run sub-processes in nested sandboxes in a secure way; see flatpak-spawn. I gathered that a patch to Chromium was submitted which leveraged this, but it was rejected given how specific it is to Flatpak, though apparently the Chromium team expressed they'd reconsider if Flatpak were to become more dominant. Again: I haven't yet learned the details of how this API works and I haven't verified the claims, it seemed legitimate.

As a result, there is a seemingly active collaboration between the Flatpak team and the Snap team (the other major player) to agree on a common high-level API that could be used in a new patchset to be presented again to the Chromium team (and leveraged by all other application vendors who need "granular sub-sandboxing").

It seems there is still a bit of work to be done on the Snap side, and as always with these things potential deviations from flatpak-spawn in the common API semantics (as a result of these discussions) might generate some work on the Flatpak side as well, but all parties seem enthusiastic about making this happen.

I'd thus like to offer a more hopeful perspective: it seems this is going somewhere.

FYI: This impacts many other projects obviously, it may be useful to track those as well just in case somebody gets creative. Electron. Riot. Chrome. Skype. Signal. Exodus. There is definitely some pressure to make this work for everybody (especially given this isn't specific to Flatpak). I haven't verified this, but it seems that if you see a project where "things work" (e.g. with a Flatpak package or a Snap package) it is probably because either they disabled "sub-sandboxing" or whitelisted the application to allow the relevant syscalls necessary for creating nested user namespaces, neither of which are apparently good options.

Some people argue the status quo (no "sub-sandboxing") is still very acceptable for them (this all depends on any individual's threat model after-all, remember the Chromium sandboxes in particular are second-level security measures to begin with and it is isolated from the host), so there might be value in a Flatpak with --no-sandbox even before a proper solution is ready (as long as the security guarantees can be made clear enough that end-users can make an informed decision of whether to use it or keep waiting).

[HadetTheUndying]

Just posting to show interest in this, as it would enable the browser to be run in distributions not using glibc.

[JaneSmith]

Posting here to show my interest in it as well. Personally, I think this should be a much higher priority. Flatpak is the future of application packaging on Linux. It works on all distros, has sandboxing with a permissions system, along with many other benefits.

In my case, I am running Fedora Silverblue, which actually uses Flatpak as its native package manager. Flatpak is how applications are supposed to be installed on Fedora Silverblue. This means that I can't even use Brave. Technically I can get it to work, but it requires some hacky workarounds (altering the base OS image via rpm-ostree), and I would rather not have to resort to that.

[srirambv]

+1 from @vikdevelop via #18190

[tunix]

@Zlopez - does it work with extensions.gnome.org ?

[Zlopez]

@tunix It complains about native host connector on F35 Silverblue.

[iam-cult]

@tunix @Zlopez because of the nature of flatpak sandboxing, the browser extension has no way of connecting with the native host. This is an issue with every flatpak browser.

[alvarlagerlof]

Is there not a point in making it available if it works well enough?

[JayDoubleu]

I'm still waiting for @brave-dev to make a little effort in making their browser available to half of linux community (flatpak) who don't use snaps. Just a single sRPM file published to fedora would make it available in flatpak and non-flatpak fedora users at the same time. 👀

[JaneSmith]

I just want to chime in and point out that Valve's upcoming new portable Linux PC — the Steam Deck — will be making use of a similar approach to Fedora Silverblue. That is, an immutable base OS with third-party applications installed via modern Flatpaks. Further evidence that Flatpak is the solution most everyone is uniting on and standardising on. Having a modern Flatpak package for this application will make it much easier for users to install on the Steam Deck.

[bayazidbh]

@TheCultLeader666 is there any Flatseal setting that I could modify to allow it? host-os and host-etc maybe?

[alvarlagerlof]

@TheCultLeader666 is there any Flatseal setting that I could modify to allow it? host-os and host-etc maybe?

There are many issues, but see flathub/org.chromium.Chromium#52

[iam-cult]

@TheCultLeader666 is there any Flatseal setting that I could modify to allow it? host-os and host-etc maybe?

I do not think so, and honestly more holes in the sandbox is not a good idea. I would just keep a native browser around.

[JaneSmith]

For GNOME extensions, personally I'd just go with the local installation method rather than using the browser add-on. I'm not sure why the browser add-on is a thing in the first place — it just seems unnecessary and even invasive. All you need to do is download the GNOME extension that you want, and put it into ~/.local/share/gnome-shell/extensions/ with the correct UUID folder name. See here for a guide on doing this. I prefer this method as it doesn't involve any dodgy browser add-ons or sandbox holes, and just works. It still gets shown in the Extensions app like normal. So I don't see any need for the Brave Flatpak to support the GNOME extension add-on.

[tunix]

Actually I've always had trouble with that method. Either the downloaded pack was different than what the browser installed or I wasn't able to figure out the directory name/structure etc. Of course, this has nothing to do with Brave itself but GNOME. 😄
So when do we move Brave to stable or (even better) to flathub itself?

[iam-cult]

So when do we move Brave to stable or (even better) to flathub itself?

Pretty sure that stable is the same thing as flathub @tunix, since brave is currently in the flathub repo, and there's only 2 flathub repos, beta and stable.

But yes, it would be nice to get brave into stable.

[alvarlagerlof]

But yes, it would be nice to get brave into stable.

Are you aware of some sort of list of what an "MVP" stable Brave flatpak would be? To some extent I think it not being there in the stable repo is worse that it being there, but with some corner-cases not working.

[iam-cult]

Are ad notifications in a working state in the flatpak? I have not seen any. I am on wayland, but I was under the impression that the custom notifications had made their way into stable.

Getting this in the logs:

[Dec 10, 2021, 6:24:36.2 PM:ERROR:get_available.cc(69)] Unexpected HTTP status: -1
[Dec 10, 2021, 6:41:48.4 PM:ERROR:publisher.cc(774)] Publisher info not found
[Dec 10, 2021, 6:41:48.4 PM:ERROR:publisher.cc(774)] Publisher info not found
[Dec 10, 2021, 7:36:56.7 PM:ERROR:publisher.cc(774)] Publisher info not found
[Dec 10, 2021, 7:36:56.7 PM:ERROR:publisher.cc(774)] Publisher info not found

[Amanse]

is it available publically for testing?

[JayDoubleu]

is it available publically for testing?

Brave is available on flathub beta remote. Been using it for quite a while now and it seems stable enough. The reason why it is still in beta is largely due to all chrome/chromium based browsers are still in beta on flathub as there's still few issues yo resolve.

[BryanQuigley]

I've also been using it for quite a while and it works great :).

I have not dug deeper but Chromium is now available in non-beta: https://flathub.org/apps/details/org.chromium.Chromium

[mihaiplesa]

Brave should move to stable in Flathub this week flathub/com.brave.Browser#53

[fmarier]

Once it's available, we should link to it from https://brave.com/linux/#unofficial-packages.

[mihaiplesa]

Available now at https://flathub.org/apps/details/com.brave.Browser

[Rots]

Available now at https://flathub.org/apps/details/com.brave.Browser

Emmmm...

NOTE: This package is not verified by, affiliated with, or supported by Brave Software.

And...

Developer
Brave Software

[239]

Developer != Publisher (package maintainer)

[fmarier]

I've just updated our installation instructions to link to the Flatpak: https://brave.com/linux/#flatpak

Thanks to everyone who contributed to this effort!

[NayamAmarshe]

The flatpak launch times are a lot longer than native package, any particular reason why?