THIS IS NOT A BUG REPORT. HOWEVER, IF YOU ARE FROM THE BRAVE DEV TEAM, PLEASE READ ON.
Description of the issue:
I am currently looking into packaging a built-from-source version of Brave that could make it into Arch Linux Official Community Repo (currently the PKGBUILD file can be found in AUR). However, one thing that’s bothering me is that if Brave allows unofficially built binaries to be distributed by other individual or distros, just like the chromium package provided by Arch.
I hope someone from Brave dev team can clarify this. If this is not allowed or any how against the Brave ToS (which I did not find any entries specifying that distribution of self-compiled binaries is forbidden), then I would say we might consider giving up making Brave a part of the Community Repo.
I think it’s fine to build from source and distribute, but it’s important to make clear that it’s an unofficial distribution. If there’s someone publishing one claiming to be official please let us know
Only Brave Software has the signing keys and service keys used for downloading adblock list, components, etc. Without the service keys, folks using that binary will get ads and will lose a lot of value that Brave adds
Part of the official build process is the signing. We have our public signing keys shared so the binary that gets output can be verified by anyone as official
With --official_build enabled, there are going to be a lot of config values needed (Google keys for safe browsing, etc) which only the Brave Software owned official build servers have configured. You can stub those config values out (putting fake or empty values)- but the services that Brave consumes at runtime (Safe browsing, fetching extensions, fetching adblock rules, Brave Rewards, Brave News, etc) will fail and folks checking the binary against the signing keys will realize it’s not an official build
TL;DR: Only Brave Software produces the official builds for Brave browser
Well clarified, but I still have some questions on this.
Let’s take the Chromium builds on Arch Linux as an example. There’s actually an Google API key dedicated for Arch Linux “Official” build on the Arch side, which can be found on the official PKGBUILD. So, I don’t think that will be a problem.
In fact, if you list all the possible params for BUILD.gn of a Brave build, you will see that there’s an option with a default key (see code block below). Not sure if this is Brave’s Google API key.
brave_google_api_key
Current value = "**REDACTED**"
From //out/Release/args.gn:23
Overridden from the default = ""
From //brave/browser/net/BUILD.gn:8
Second, if Arch wants to provide the users with a distro-built Brave, while maintaining all the Brave features, would there be some official way or channel that other devs could apply for their own service keys to access Brave services? Just like how Chromium in Arch Linux did with Google service keys.
Finally, if someone figured out the built-in Brave service keys and endpoints by reverse engineering the official binary, would it be okay to use these keys to access Brave services (while claiming the build is unofficial)?
These service keys can be rotated at any given time; so if the specific key was discovered by reverse engineering, it would only be good for an unspecified amount of time. The concern here is that forks, etc can be making use of Brave Software owned/maintained services which have an ownership cost
wknapik has setup an internal discussion - we’re going to chat more about this case along with other cases. Will share updates here afterwards
I totally understand the situation you described where third-party forks uses the same key and therefore taking advantage of Brave officially maintained services, and I do appreciate it and hope that related issues can be discussed by Brave developers.
However, I would like to summarize my questions:
Does Brave allows other Linux distro ship distro-built packages of Brave browser (this means it’s not a fork)?
The distro-built version of Brave that we are talking about is Brave itself (not a fork, just vanilla Brave pulled from Brave’s GitHub codebase). There could be patches applied for compiling against other system libraries and toolchains but no changes to any Brave components or branding.
If Brave allows doing so, will there be any proper/official ways or platforms for the package maintainers of those Linux distros to apply for a Brave service key specifically for the purpose of packaging Brave for that distro (could be fixed or rotated) so that we can build distro-shipped Brave packages and conveniently provide it to respective users while not infringing or abusing Brave owned services?
I truely hope that these two questions can be discussed internally.
@clifton we need ad block services in our fork so is there any way that we can get services keys for that or can we build that service ourselves if the code is opensource ?
Also for a additional example, Discord, as a proprietary software, has given the license or permission to official Arch Repo for packaging Discord as a distro-built package. You can refer to the Arch official GitHub repo for the permission-granting letter and how it’s packaged. This works the same for another proprietary VoIP software called TeamSpeak, and you can check the permission-granting letter and how it’s packaged.
For a simpler solution, Arch can always package Brave browser from a prebuilt official binary, and ship it to the user. However, given that Brave itself is open source and licensed under a proper open-source license, I don’t really see the point of not compiling and packaging Brave from its source for Linux distro packages.
As you have mentioned, it was a potential problem for Brave owned services. Nevertheless, I sincerely hope that there could be a proper way for us packagers to properly obtain various service keys and configurations for distro packaging purposes.
Allowing distros to ship their own builds would make the Brave browser more popular among Linux uses, wo don’t need to install 3rd party repos but can install right via package manager from trusted distro repos.
Also much more likely builds for all supported platforms are provided or distro maintainers may help solving issues with them upstream. I remember the time it took for Brave to provide aarch64 builds: https://github.com/brave/brave-browser/issues/11836
It also potentially enables an additional code review instance, and one which collects and sorts bug reports and may send them upstream with high quality debug information, or even provide patches.
The common user <> distro <> developer model (as option) has quite some advantages on all sides.
Hi folks - sorry for the super long reply time. We did meet internally as we mentioned we would above. We went through all the services which require a key, etc and looked at substitutes. We ultimately came up with an idea that we could do a “Bravium” similar to Chromium, where Brave is buildable but it’s not the official build and doesn’t use our keys - but still works as intended.
@flattery6159 nothing stopping folks from compiling Brave. I compile non-official builds all the time without having signing keys, etc. When the binaries are not produced by us and are using our services (which are locked down, because they cost money to operate) there is a problem. But as shared above, we should be able to have a better experience (ex: “Bravium”).
I also hope you understand we have limited resources. We have a very small set of employees versus a company like Microsoft - and the folks we do have are focused on roadmap items. Separate of the discussion we had, we have at least one person that uses f-droid and several using Arch Linux who are advocates for them. But at the end of the day you can’t do everything - we have to prioritize and choose what we feel are the best items
I’ll ping some of our team members to see if we can share more information about what I mentioned as “Bravium”
Hey @clifton glad to see the reply from Brave team. Yes I think this could be a proper solution, but there needs to be more info regarding this. Here are some personal questions regarding this Bravium solution:
Who is responsible for the maintenance of the distribution? The Brave team or the community or together?
What are the possible Brave services that can be kept for Bravium? Or no Brave services at all for Bravium? (I would personally kindly ask Brave to keep Brave Sync )
If Brave eventually decided not to provide any of the Brave services at all for Bravium, will there be some self-hostable components (ex. custom Brave Sync server) that can be released under proper licenses?
How will Bravium be built? Would it be built by adding options to the current build system or by applying various patches?
There’s much to be discussed, and I am kinda excited to how this Bravium would turn out.
Thanks again for your update on this.
I’ve been monitoring this thread because I am the current maintainer of the brave package in the Arch Linux AUR and would love to sponsor it being migrated to the official repositories, but the API keys & permission to use them in an unofficial build is kind of a blocker.
As soon as there is a way to build Brave as Bravium with keys that make it a high-functional browser without breaking any TOS rules I’ll get it in the official repos.
)