At Brave Software, we are looking to provide everyone with a faster, more secure, and dynamically improving browser. Previous attempts at monetization models for internet content have resulted in an ecosystem with amoral incentives: one that trades user rights, rewards tracking, and encourages the unchecked collection of user data. You may have heard the expression that if you’re not paying for a service then you yourself must be the product. With Brave and an open ecosystem, we aim to circumvent traditional issues with the monetization of users by providing a new and sustainable model for how businesses and individuals will interact on the internet.
Right now we are working with community members to expand our services to support all Linux distributions. We have already successfully implemented integration with Debian, Ubuntu, and Red Hat and I am currently working on bringing support to Arch, OpenSUSE, Gentoo, and many many more. We’ve recently added a snap for Brave. We would like to provide each and every distro with the attention usually reserved for the largest system communities. Don’t forget about FreeBSD: I know I haven’t.
Initially, we began by bundling tar and zip files into DEB file for Ubuntu and RPM files for Red Hat, but we found this approach to be insufficient to the scope of our development goals. Because we were not seeing the system tested widely enough, we found that our initial approach caused some deficiencies. Now, mainly prioritized by community effort and the initiative of individual users and developers, we’ve begun to focus more attention on openSUSE and other less common systems.
For ease in multi-platform development, we employ a modified version of Electron called Muon. Muon is like Electron but specifically modified for the task of building a web browser. Muon tracks Chromium updates much more closely than Electron, to ensure that we always integrate the latest upstream security fixes. To enable rapid release cycles across a wide variety of distributions and platforms, we use Muon builder, which is an upgraded Electron builder. The new Muon builder has been paramount to our OpenSUSE packaging efforts, as well as our new preview releases for 32bit Linux systems, SNAP, AppImage, FreeBSD, and many other systems. You can find our preview bits here: https://storage.googleapis.com/posis-brave-mirror/. OpenSUSE directions can be found here: https://github.com/brave/browser-laptop/pull/10274.
We now have a more diversified and automated testing and distribution system for new releases of our browser. Pull requests to GitHub are automatically tested and checked against our core system by Travis. These requests are then merged with the master branch and any shipping release branches. Since many patches go into a single release, we trigger the next stage only on certain events. Generally, these events are: when we have enough new features, when there’s a new version of Chromium released, or when our release team decides to push a new release. Once we’ve decided to release a new version, we start the build process which assembles our version of Chromium with Muon. The repository we use for this phase of our build can be found here: https://github.com/brave/browser-laptop-bootstrap.
The output of this phase produces these files:
brave ← our version of Electron
chrome_100_percent.pak electron_resources.pak chrome_200_percent.pak ← libchromium
Icudtl.dat ← icu data
In this phase, the developer can use sccache to see which objects are built. This can help with understanding how verifiable our builds are and speed up that phase. The GitHub documentation of sccache can be found here: https://github.com/mozilla/sccache. Because any new objects not already cached by sccache give visibility to anything changed or enacted within the project, this process allows developers to independently build the same software from the same cache. The closer we get to universally reproducible builds, the more we can assure our delivery of thoroughly tested and secured bits to our users. After the first build, a draft is released to GitHub where it awaits a second round of testing and integration.
Once everything appears stable, phase two begins. In phase two, we take all input from phase one and apply it to the makeup of phase two. The repository for phase two can be found here: https://github.com/brave/browser-laptop. Then we copy our phase one artifacts by using one of the syncing options in the phase one bootstrap. This can be found here: https://github.com/brave/browser-laptop-bootstrap/blob/master/package.json#L16. Then we begin an “npm build” to build the Brave browser. Finally, we build the Linux packages. Those can be found here: https://github.com/brave/browser-laptop/blob/master/package.json#L12.
To build the packages we use a series of scripts adapted from Electron. These can be found here:
https://github.com/brave/electron-packager
https://github.com/brave/electron-prebuilt
Finally, for Windows and Mac as part of the Jenkins job we sign our releases using signtool and codesign, respectively. Once signing of the repository is complete, Jenkins publishes the packages and signed archives for our end users. Now we can release our GitHub draft.
Phase three begins with one of our “release” engineers unlocking our linux package signing keys. We maintain a restricted and locked down instance dedicated to the sole purpose of signing packages. We monitor relevant authentication events like logons, privilege escalation attempts, as well as cryptographic events like key unlock attempts and signatures. This dedicated signature node, or signator, is only accessed manually by a small group of authorized engineers. Next, we kick off a Jenkins job which uses the keys to sign our linux releases and update the package repositories we maintain. In order to allow Jenkins use of keys without direct access, the signator instance uses gpg-agent forwarding to empower a Jenkins build node. This setup gives us a similar property to that of hardware tokens, where the key can be used but not escape confinement. We are always looking to enhance security even further. In the future, we plan to transition towards using hardware tokens to store the signing keys themselves.
A point of note: recently, we’ve independently had users/devs take an interest in Linux Mint. This sort of attention has been hugely helpful to us and is truly a boon for Linux integration at Brave. I’d like to highlight this: https://github.com/brave/browser-laptop/pull/11241 as an absolutely stellar example of how our users/devs can be more involved with Brave. We want our users/devs to know just how meaningful their contributions are and we are now researching ways of giving those users/devs proper exaltations for their hard work.
If you’re interesting in talking more, feel free to reach out anytime @posix4e
Cheers,
Alex
Alex Newman is a freedom enthusiast with more than twenty years of experience with Linux and open-source software. Previously, he was an early engineer at Cloudera, developed lightweight databasing software for deployment in austere environments at OhmData, and managed engineering teams at Planet. Recently, he has gotten a truck and is enjoying the increased access to waterfronts.
