Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make brave available through Flatpak and Flathub #1000

Closed
bsclifton opened this issue Sep 7, 2018 · 94 comments
Closed

Make brave available through Flatpak and Flathub #1000

bsclifton opened this issue Sep 7, 2018 · 94 comments
Labels

Comments

@bsclifton
Copy link
Member

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

@bsclifton bsclifton added this to the Triage Backlog milestone Sep 7, 2018
@bsclifton bsclifton modified the milestones: Triage Backlog, 2.x Backlog Sep 7, 2018
@Garbee
Copy link

Garbee commented Sep 7, 2018

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.

@bbondy bbondy modified the milestones: 2.x Backlog, 1.x Backlog Sep 30, 2018
@x80486
Copy link

x80486 commented Nov 11, 2018

Hello! Has there been any progress with this one?

@Garbee
Copy link

Garbee commented Nov 12, 2018

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
Copy link
Contributor

Jacalz commented May 13, 2019

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
Copy link

Razva commented Jul 14, 2019

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

@henk717
Copy link

henk717 commented Jul 30, 2019

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
Copy link

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
Copy link
Contributor

srirambv commented Aug 8, 2019

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

@bsclifton bsclifton added help wanted priority/P5 Not scheduled. Don't anticipate work on this any time soon. labels Aug 12, 2019
@bsclifton
Copy link
Member Author

bsclifton commented Aug 12, 2019

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
Copy link
Contributor

@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
Copy link

t-nelis commented Nov 20, 2019

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
Copy link

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

@JaneSmith
Copy link

JaneSmith commented Dec 5, 2019

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
Copy link
Contributor

srirambv commented Sep 19, 2021

+1 from @vikdevelop via #18190

@tunix
Copy link

tunix commented Nov 1, 2021

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

@Zlopez
Copy link

Zlopez commented Nov 1, 2021

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

Screenshot from 2021-11-01 15-57-57

@iam-cult
Copy link

iam-cult commented Nov 6, 2021

@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
Copy link

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

@JayDoubleu
Copy link

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
Copy link

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
Copy link

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

@alvarlagerlof
Copy link

@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
Copy link

@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
Copy link

JaneSmith commented Nov 16, 2021

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
Copy link

tunix commented Nov 17, 2021

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
Copy link

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
Copy link

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
Copy link

iam-cult commented Dec 11, 2021

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
Copy link

Amanse commented Jan 26, 2022

is it available publically for testing?

@JayDoubleu
Copy link

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
Copy link

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
Copy link
Contributor

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

@fmarier
Copy link
Member

fmarier commented Apr 7, 2022

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

@mihaiplesa
Copy link
Contributor

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

@Rots
Copy link

Rots commented Apr 9, 2022

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
Copy link

239 commented Apr 11, 2022

Developer != Publisher (package maintainer)

@fmarier
Copy link
Member

fmarier commented Apr 12, 2022

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests