Brave-browser: Make brave available through Flatpak and Flathub

[bsclifton]

Carried over from https://github.com/brave/browser-laptop/issues/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.

[akarshanbiswas]

@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.

[Nonononoki]

Posting here to show interest. Flatpak is getting more and more popular and it just works.

[JaneSmith]

For what it's worth, getting Brave up on Flathub would also solve issue #6865. Flathub is the de facto repository for Flatpak applications, so any Flathub-enabled system would have Brave discoverable and installable via the GNOME Software GUI - as well as other Flatpak-aware tools like KDE Discover.

[peakgeek]

+1 Commenting to highlight interest.
I've been a regular Brave user since early 2017 and I continue to be amazed by this project. It's a bummer that you have to choose between using an Arch-based distro or being able to use Brave (other than the community snap). A Flatpak option would be killer.

[kojid0]

+1 from here. It would make brave easily available for 'average' linux users.

[Chocod2]

Also posting to show interest. I would like to see Brave browser on Flathub.

[t-nelis]

Riot apparently successfully used zypak for addressing the sandbox-related issue.

[Spacesurfer]

Bi-weekly comment showing interest in Brave becoming available through a Flatpak install and integration within Flathub.

Just an FYI, that pesky Gecko based browser is to have a stable build available through Flathub in April ;)

[msmoljan]

Also interested in Brave on Flathub!

[fmarier]

Firefox 75 was just released with support for Flatpack. There might be code/configuration we could borrow there.

[fmarier]

It's a bummer that you have to choose between using an Arch-based distro or being able to use Brave (other than the community snap).

Just wanted to point out that we've supported RPM/DEB based distros with officially-supported packages (including timely updates) for a while now: https://brave-browser.readthedocs.io/en/latest/installing-brave.html#linux

So while we don't yet have a Flatpack, we do support a large number of Linux distributions.

[t-nelis]

In addition to Riot using zypak to solve this issue (as previously reported), the Exodus project has just done the same.

[rajmondburgaj]

Is there any plan soon to do this ? Would great if the would have this option to install from flathub

[fmarier]

Due to time constraints, this is not something we are planning to do in the short term. If someone would like to take this on and create an unofficial flatpack for Brave, that would be a good first step towards our integrating it into our build process.

[TheEvilSkeleton]

@bsclifton I have decided to send an issue to Flathub. Let's hope they will package it as Flatpak.

[eljuno]

+1 from Community https://community.brave.com/t/flatpak-for-endless-os/125944?u=eljuno

[mwleeds]

Relatedly, there's ongoing work to make a sandboxed Chrome Flatpak: https://github.com/flathub/flathub/pull/1630

[x80486]

...and since the Flatpak for Chrome just made it to the Flathub's beta repo, it should be easier to do this one now :partying_face:

[rany2]

I just made a flatpak for this based on the Chrome flatpak. I've made it public: https://github.com/analotia/flathub/tree/com.brave.Brave

It's working fine so far except for print support

[rany2]

Update: the issue with printing seems to be caused by the zypak. So it's not really possible for me to fix.

[x80486]

@analotia, if it's working already, why don't you go ahead and try to push it to Flathub's beta repo (where Chrome is at still) until it gets stable along with Chrome?

[rany2]

@x80486, sorry but I don't know how to. I'll try to search on how I could do that. Hopefully it's easy to get started

[rany2]

Done! Seemed easy to get started, all it takes is a pull request to https://github.com/flathub/flathub. I was somewhat worried i'll have to send emails and stuff

We'll see how this goes... https://github.com/flathub/flathub/pull/1852

[rany2]

Now you can just do:
flatpak install --user https://dl.flathub.org/build-repo/27286/com.brave.Brave.flatpakref
to try out the flatpak

[x80486]

It would nice if someone from Brave (@fmarier or @bsclifton) helps @analotia with some questions and stuff specific to the browser — probably some recommendations. The pull request is on Flathub already.

[JayDoubleu]

It's almost 2021. flatpak and snaps are here to stay.
Snaps are default in latest ubuntu LTS, flatpaks are common for fedora workstation and default in fedora silverblue.
I think it's time to simply acknowledge that they are here to stay and start building packages for it please :)

[rany2]

@JayDoubleu

you could try out the new flatpak now: flatpak install https://dl.flathub.org/build-repo/27407/com.brave.Brave.flatpakref

I think it's pretty ready and it's working fine now. We have benefited massively from the com.google.Chrome flatpak work.

If you get a "Action Required" page please follow the instructions, otherwise you'll have a broken flatpak

[JayDoubleu]

Is there a code on GitHub which provisions mentioned flatpak ?

[rany2]

What do you mean? @JayDoubleu

This is built by a bot run by the flathub people

[JayDoubleu]

Isn't anyone allowed to just publish anything onto flathub ?

[rany2]

Isn't anyone allowed to just publish anything onto flathub ?

Not really. You need to get it approved by flathub. Anyone is allowed to send a pull request though

[rany2]

Are you confusing flathub with flatpak? The two aren't the same.

• flatpak is the package manager
• flathub is the repo for flatpak

Unlike snaps, flatpak has repositories which could be run by anybody. Whereas on snaps, it's centralized to one hard coded repo

[elechner]

Glad to see that a flatpak of Brave is finally in the works. Thanks for getting the ball running, @analotia . When do you think Brave will be available on flathub-beta and approved by @brave ?

[rany2]

@elechner It seems like it won't be approved by Brave for a while. However according to fmarier it is very likely this will start off as an "unofficial repo" but will eventually be maintained by brave officially.

[Dani3I]

Hi, if I want to test Brave I should install it from the last command from "flathubbot" from this: https://github.com/flathub/flathub/pull/1852 or is there another preferred version?

[rany2]

@Dani3I You should install from the last command from @flathubbot

[x80486]

For the record, @analotia just got this one in. You can install Brave from Flathub "beta" (for now) using:

$ flatpak remote-add --if-not-exists flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo
$ flatpak install flathub-beta com.brave.Browser

The same instructions apply for Google Chrome — in case you are interested :wink:

[andirsun]

For the record, @analotia just got this one in. You can install Brave from Flathub "beta" (for now) using:

$ flatpak remote-add --if-not-exists flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo
$ flatpak install flathub-beta com.brave.Browser

The same instructions apply for Google Chrome — in case you are interested wink

andirsun@andirsunpc:~/projects/tingo/backend/rest-api$ flatpak install flathub-beta com.brave.Browser
Looking for matches…
error: The application com.brave.Browser/x86_64/beta requires the runtime org.freedesktop.Platform/x86_64/20.08 which was not found

[x80486]

That's weird. I can only think that it failed because it's using the flathub-beta repository and it cannot resolve the dependencies from flathub. You might want to file an issue in the flatpak repository about this.

In any case, just install org.freedesktop.Platform/x86_64/20.08 from flathub first, and once you have that one, try the initial command again.

[tannercrook]

I tried installing the flatpak beta:
flatpak install org.freedesktop.Platform/x86_64/20.08
and got:

The application com.brave.Browser/x86_64/beta requires the runtime org.freedesktop.Platform/x86_64/20.08 which was not found

When I tried to install from flathub, it had already been installed.

Skipping: org.freedesktop.Platform/x86_64/20.08 is already installed

I also tried the runtime/org.freedesktop.Platform/x86_64/20.08beta runtime to no avail either.

flatpak install flathub-beta com.brave.Browser
Looking for matches…
error: The application com.brave.Browser/x86_64/beta requires the runtime org.freedesktop.Platform/x86_64/20.08 which was not found

[x80486]

You might want to file an issue in the Flathub's Brave repo. As it stands, this issue should be already closed :wink:

[JayDoubleu]

This beta worked for me. The only issue I have at the moment is a latency within the flatpak.
When running speed-tests side by side Brave <> Brave flatpak, the flatpak version adds ~5ms extra to the ping.