Tor Browser 14.0a2 is now available from the Tor Browser download page and also from our distribution directory.
This version includes important security updates to Firefox.
As discussed in our previous blog post, we are hard at work updating Tor Browser to the Firefox ESR-128. New in this version we have our first updated Tor Browser Android build, we have completed our Bugzilla issue triage and code-audits, reviewed various upstream changes discovered from this work, and fixed various issues.
Tor Browser Android always requiers a bit more extra attention each year to update. One of the reasons for this is that Mozilla has altered the project layout non-trivally on us with each of the major updates.
Firefox Android (and therefore Tor Browser Android) has historically consisted of several separate components spread across multiple git repos: application-services, android-components, fenix, and GeckoView (GeckoView is the same codebase used to build desktop Firefox).
Last summer we had to update our patches as upstream's android-components and fenix had been merged into a single firefox-android repo which meant we had to merge all of the patches we had applied to these projects into our own firefox-android fork, on top of also updating our patches to work with all the other changes made during the year.
This summer we have had to do a similar thing once more, as Mozilla merged firefox-android into GeckoView in Firefox 126. So again we had to move and update all of our Tor Browser Android patches.
All of this work requires a lot of attention to detail, and has the annoying property that the work cannot be done incrementally. Someone basically has to go do all of this work locally while our users and the rest of the team patiently wait for the end result. That can be a stressful spot to be in, and the fact that we have to do this is outside our control is also rather frustrating.
Fortunately, there is a silver lining. After Tor Browser 14.0 stabilises, almost all of our the code which makes Tor Browser different from Firefox will be in the same repo. This will greatly simplify both maintenance and new feature development because changes which may require updates to multiple components, can now be reviewed in a single merge-request instead of being scattered across multiple repos. It will also make our patchset easier to reason about for this same reason. A single repo also makes it much easier for new developers to become familiar with the codebase since all the source lives in just one place!
The other silver lining from all of this is that we shouldn't need to do this again as there are no more components to migrate! Well, almost. The application-services component could be next but we have long-term plans.
To help protect against various possible threats (release infrastructure compromise, toolchain attacks, rogue developers, etc) we have hard requirement that our releases are reproducible. We build our releases multiple times on multiple different machines on different networks and ensure the build outputs match byte-per-byte. Currently we are typically building on 3 different machines:
If all three machines (which are controlled and adminstered by different parties) build the exact same artifacts, then we sign and publish our builds. You can see this process in action in our 14.0a2 release-prep ticket on our Gitlab:
The kind of cool thing about this process is that users don't have to just trust our binaries, since they can be easily(ish) built locally. They can also make our builds and verify the build system does what we claim it does.
The other kind of cool thing about this setup is that we don't need to be super confident about the integrity of any one individual build machine. If any of the aforementioned machines were somehow compromised and inserting unknown code into our releases, it would be discovered immediately after building since the outputs would be different.
Another layer of assurance we have is that none of the the Tor Browser developers responsible for releases even have administrative access to the Mullvad build-server. We can only request a signed-tag be built and then it tells us the outputs.
As we've come to expect with a year's worth of toolchain updates, we uncovered some reproducibility problems in our Android apk generation. Fortunately, the problem was a well-understood one in the build-reproducibility space.
To summarise, groups of objects are often stored in some unordered set, and then enumerated to a list with a particular order. Depending on how these objects were originally stored and the method by which they are enumerated, one can get a differently ordered list (and therefore different build outputs) from run to run.
Fortunately, the solution is generally pretty simple: either sort the list afterward or change the underlying data-structure to be one which enumerates its contents deterministically (e.g. convert a HashSet<T>
to a BTreeSet<T>
).
We have triaged all of upstream Bugzilla issues closed by Mozilla in there releases from Firefox 116 through 128. From this massive list of literally thousands of issues, we have identified 256 particular issues developers need to investigate further. Of these we have investigated and potentially patched 56.
This work can be tracked in this Gitlab query.
We have also run out automated code-audit scripts on the entire relevant commit range and identified a handful of commits which should be looked at more closely.
If you find a bug or have a suggestion for how we could improve this release, please let us know.
There are a few known issues which we are aware of.
Our alpha release exceeds the Google Play Store's limit on APK size for x86 and x86_64 devices. This is being tracked here:
This issue will be fixed in the next alpha release. It is being tracked here:
The full changelog since Tor Browser 14.0a1 is:
first name
and last name
field in a credit card formisOnNewTabPage
patch--arrowpanel-
variables for tor circuit panel spacingmail
icon used in "Find more bridges"tor-bridges-provider-list
under "Find more bridges"lh
CSS unit