-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Comments
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 |
Hello! Has there been any progress with this one? |
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. |
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 👍 |
July 2019, still no Flatpak. Come on guys, be Brave and do this for us! :) |
Brave availability is quite poor on Arch, Suse and other smaller distro's. |
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. |
cc: @rebron @bsclifton to add a priority to this |
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. |
@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. |
This document mentions:
The summary also seems clear:
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 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 |
Just posting to show interest in this, as it would enable the browser to be run in distributions not using glibc. |
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. |
+1 from @vikdevelop via #18190 |
@Zlopez - does it work with extensions.gnome.org ? |
@tunix It complains about native host connector on F35 Silverblue. |
Is there not a point in making it available if it works well enough? |
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. 👀 |
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. |
@TheCultLeader666 is there any Flatseal setting that I could modify to allow it? |
There are many issues, but see flathub/org.chromium.Chromium#52 |
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. |
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 |
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. 😄 |
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. |
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. |
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:
|
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. |
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 |
Brave should move to stable in Flathub this week flathub/com.brave.Browser#53 |
Once it's available, we should link to it from https://brave.com/linux/#unofficial-packages. |
Available now at https://flathub.org/apps/details/com.brave.Browser |
Emmmm...
And...
|
Developer != Publisher (package maintainer) |
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! |
The flatpak launch times are a lot longer than native package, any particular reason why? |
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
The text was updated successfully, but these errors were encountered: