The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-30T09:22:28Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/21939start-tor-browser.desktop hack will soon stop working2024-01-30T09:22:28ZMicah Leestart-tor-browser.desktop hack will soon stop workingThe Linux version of Tor Browser is made more usable by a kind of hacky `start-tor-browser.desktop` file. Users can both execute it in a terminal to launch Tor Browser, and also double-click it from a GUI file manager like nautilus.
How...The Linux version of Tor Browser is made more usable by a kind of hacky `start-tor-browser.desktop` file. Users can both execute it in a terminal to launch Tor Browser, and also double-click it from a GUI file manager like nautilus.
However, `.desktop` files can be used to hide malware. See this upstream nautilus bug [1], which has already been resolved. Also see this blog post [2] for more about how this bug allows attackers to compromise Subgraph OS.
Once this patch makes it to the versions of nautilus that Linux users have installed on their computers, the Tor Browser desktop file will break. Instead of saying "Tor Browser" with the Tor icon, it will say "start-tor-browser.desktop" with a default icon, and when the user tries double-clicking it it will pop up an "Untrusted application launcher" warning that the user has to click through.
One possible solution to this problem is to start distributing Tor Browser as a real Linux package that can be installed system-wide, with a `.desktop` file installed to `/usr/share/applications` like other software. I discussed this idea a bit in this thread [3].
[1] https://bugzilla.gnome.org/show_bug.cgi?id=777991
[2] https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/
[3] https://lists.torproject.org/pipermail/tor-meeting/2017-March/000162.htmlhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/21565Clean up hardening wrapper flags used in tor-browser-build2021-08-16T20:38:47ZGeorg KoppenClean up hardening wrapper flags used in tor-browser-buildWe set `export DEB_BUILD_HARDENING=1` to activate GCC hardening flags but we export other *HARDENING flags, too. The latter seems to be unnecessary as the former should already be activating all flags available. We should clean that up.We set `export DEB_BUILD_HARDENING=1` to activate GCC hardening flags but we export other *HARDENING flags, too. The latter seems to be unnecessary as the former should already be activating all flags available. We should clean that up.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/21448Identify what build flags we should be using for security, and use them2023-01-05T13:54:10ZArthur EdelsteinIdentify what build flags we should be using for security, and use themI think we may be able to add some configure/compiler/linker flags in Tor Browser that can improve security without many downsides. Let's figure out what those are and add them.I think we may be able to add some configure/compiler/linker flags in Tor Browser that can improve security without many downsides. Let's figure out what those are and add them.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/21032Creating some public database of "reproduced builds"2021-08-16T20:38:19ZboklmCreating some public database of "reproduced builds"The process of checking that our builds have been reproduced by multiple people is currently mostly manual. In order to make this process easier, more automated (to be able to use it in the updater or some launcher) and possible to use a...The process of checking that our builds have been reproduced by multiple people is currently mostly manual. In order to make this process easier, more automated (to be able to use it in the updater or some launcher) and possible to use at a larger scale (checking that some large number of people reproduced a build), we could have some tool indexing the builds created by various people.
This could be done by adding the generation of some `buildinfo` files (similar to the Debian's buildinfo files) to our build process, containing important informations about the build, such as its inputs and outputs, and indexing them with their signatures in some database.
This database would contain the following types of builds or operations, signed by various builders:
- the build of a bundle from a git tag
- the creation of a signed mar file, from an unsigned mar (or the reverse operation)
- the creation of an OSX code-signed mar file, from an unsigned mar (or the reverse operation)
- the creation of an incremental mar file, from two full mar fileshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/20743Suggestion for additional checks on Tor browser bundle startup script2021-08-16T20:34:25ZTracSuggestion for additional checks on Tor browser bundle startup scriptIn addition to ticket #200100 (bug) - a new ticket for a suggestion.
Another libxul.so oddity. Fresh system, stock Debian using TBB now. This one affects tor-browser-linux64-6.0.6_en-US.tar.xz
Fresh unpack and run of TBB. Crashes afte...In addition to ticket #200100 (bug) - a new ticket for a suggestion.
Another libxul.so oddity. Fresh system, stock Debian using TBB now. This one affects tor-browser-linux64-6.0.6_en-US.tar.xz
Fresh unpack and run of TBB. Crashes after surfing to a popular website.
Here only one byte changed:
before crash: 1d66170 -- bytes: e800 f39a fec4 8948 48ea c389 8948 4cc7
after crash: 1d66170 -- bytes: e900 f39a fec4 8948 48ea c389 8948 4cc7
0xe8 turned 0xe9 (elf64-x86-64 format)
1d66171: e8 9a f3 c4 fe callq 9b5510 <moz_xmalloc@plt>
1d66171: e9 9a f3 c4 fe jmpq 9b5510 <moz_xmalloc@plt>
I have to ask: is it normal for libxul.so binaries to change when run? (not a coder here, sorry)
If not, maybe TBB could implement a integrity checker on the libs?
I believe there's an issue with libxul in general, which also may affect the Tor Browser Bundle, Tails, etc.
The difference here is 1 byte. It didn't expand like in other settings. With JMPQ there's no need for the CALL routine to return using RET, JMPQ discards proper control using addresses pushed on the stack. This behaviour could explain the segfaults in the other configurations.
Right now TBB startup scripts don't check hashes of packaged libs. And why not? It's an easy feat to add to the start-tor-browser-desktop script. Call it an early warning system if you will. Now TBB runs REGARDLESS if a modded libxul.so is residing in the Browser/ directory. This is also a way to find users with similar problems (in case of no segfault, when TBB appears to "just" exit)
Just my 2 cts
ronvandaal
**Trac**:
**Username**: ronvandaal_https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/20361Investigate CFI means for usage in Tor Browser2023-06-01T16:35:21ZGeorg KoppenInvestigate CFI means for usage in Tor BrowserChrome uses CFI for some parts in its code: https://www.chromium.org/developers/testing/control-flow-integrity and Mozilla is about to add CFI support to the build system (https://bugzilla.mozilla.org/show_bug.cgi?id=1302891). We should ...Chrome uses CFI for some parts in its code: https://www.chromium.org/developers/testing/control-flow-integrity and Mozilla is about to add CFI support to the build system (https://bugzilla.mozilla.org/show_bug.cgi?id=1302891). We should investigate whether we can leverage that at least in our hardened-builds as wellhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/20322SafeSEH support for mingw-w64 for Tor Browser on Windows2023-01-05T12:46:12ZbugzillaSafeSEH support for mingw-w64 for Tor Browser on WindowsNot only SEH, because of www.fuzzysecurity.com/tutorials/expDev/3.html
Even YASM can do it https://www.tortall.net/projects/yasm/manual/html/objfmt-win32-safeseh.htmlNot only SEH, because of www.fuzzysecurity.com/tutorials/expDev/3.html
Even YASM can do it https://www.tortall.net/projects/yasm/manual/html/objfmt-win32-safeseh.htmlhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/20254Update marsigning-check.sh to cope with signed OS X MAR files2023-10-23T10:40:22ZGeorg KoppenUpdate marsigning-check.sh to cope with signed OS X MAR filesNow that the fix for legacy/trac#19410 landed our `marsigning-check.sh` script can't check the correctness of our MAR file signatures easily anymore as we use the SHA256 sums of the unsigned MAR files currently. We should adapt the script.Now that the fix for legacy/trac#19410 landed our `marsigning-check.sh` script can't check the correctness of our MAR file signatures easily anymore as we use the SHA256 sums of the unsigned MAR files currently. We should adapt the script.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/20135OSX: fail during bundling if any symlinks are used2022-08-02T15:18:54ZMark SmithOSX: fail during bundling if any symlinks are usedIn legacy/trac#19410, mcs said: Regarding the symlink issue, as a failsafe we could check to make sure no symlinks are used, but we would need to do that as we create the dmg.In legacy/trac#19410, mcs said: Regarding the symlink issue, as a failsafe we could check to make sure no symlinks are used, but we would need to do that as we create the dmg.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/19182Find a better place for the Mac OS X SDK we need for our Tor Browser builds2022-08-02T14:24:37ZGeorg KoppenFind a better place for the Mac OS X SDK we need for our Tor Browser buildsRight now we host the OS X SDK we use for our Tor Browser builds on our infrastructure. We might want to find a better solution for that.Right now we host the OS X SDK we use for our Tor Browser builds on our infrastructure. We might want to find a better solution for that.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/19181Firefox >= 48 ships with an ICU pre-compiled blob2023-01-05T14:10:02ZGeorg KoppenFirefox >= 48 ships with an ICU pre-compiled blobIn https://bugzilla.mozilla.org/show_bug.cgi?id=1239083 Mozilla implemented build changes that resulted in an ICU related binary being shipped in the source tree. It is a pre-compiled thing to avoid generating it twice e.g. in a cross-co...In https://bugzilla.mozilla.org/show_bug.cgi?id=1239083 Mozilla implemented build changes that resulted in an ICU related binary being shipped in the source tree. It is a pre-compiled thing to avoid generating it twice e.g. in a cross-compilation scenario. We should investigate whether we want to ship that blob.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/18867Ship auto-updates for Tor Browser nightly channel2020-10-25T12:54:44ZGeorg KoppenShip auto-updates for Tor Browser nightly channelWe want to get more users to test our nightly builds. The main hurdle currently is the missing auto-update. This is the parent ticket that tracks this task.We want to get more users to test our nightly builds. The main hurdle currently is the missing auto-update. This is the parent ticket that tracks this task.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/18497Check that MAR signing is done properly on the files available in the update ...2023-01-31T20:39:12ZboklmCheck that MAR signing is done properly on the files available in the update responsesIn legacy/trac#18405 we are adding a script to be used during the release process to check that the MAR files are properly signed. We could have an other one that is doing the same things on the files currently proposed as an update. Thi...In legacy/trac#18405 we are adding a script to be used during the release process to check that the MAR files are properly signed. We could have an other one that is doing the same things on the files currently proposed as an update. This would allow someone to easily check (maybe as a cron job) that the updates currently available are the same as the ones in the sha256sums-unsigned-build files.
In tools/update-responses/check_update_responses_deployement we have a script that currently check that the update responses xml provides the expected version. I think I could extend it to also download the mar files it provides, unsign them and check that they match sha256sums-unsigned-build.txt.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/18326Creating incremental MAR files should not include Tor Browser version in meta...2023-01-05T13:59:01ZGeorg KoppenCreating incremental MAR files should not include Tor Browser version in meta dataWhile trying to build the incrementals for 5.5.2 on a machine that had older mar-tools I ended up with them not matching incrementals built on other machines. Upon investigation it turned out that the browser versions gets embedded in th...While trying to build the incrementals for 5.5.2 on a machine that had older mar-tools I ended up with them not matching incrementals built on other machines. Upon investigation it turned out that the browser versions gets embedded in the MAR files' metadata. There is no need for doing that actually.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/18325We should not depend on rebuilding Firefox to get a new Tor Browser version out2022-12-08T15:15:24ZGeorg KoppenWe should not depend on rebuilding Firefox to get a new Tor Browser version outIn case we need to bump OpenSSL or think about just rebundling for a new release we need to rebuild Firefox too, currently, as the Tor Browser version is getting set there. We should find a way to avoid that.In case we need to bump OpenSSL or think about just rebundling for a new release we need to rebuild Firefox too, currently, as the Tor Browser version is getting set there. We should find a way to avoid that.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/18130Fold in pre 3.0 Tor Browser changelogs2023-02-09T09:50:44ZGeorg KoppenFold in pre 3.0 Tor Browser changelogsWe should fold in the pre 3.0 Tor Browser changelogs for reference purposes. They are right here: https://gitweb.torproject.org/torbrowser.git/tree/?h=maint-2.4. Might be a bit of work to sort all the things out and get that into the for...We should fold in the pre 3.0 Tor Browser changelogs for reference purposes. They are right here: https://gitweb.torproject.org/torbrowser.git/tree/?h=maint-2.4. Might be a bit of work to sort all the things out and get that into the format we use today, but it's worthwhile.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/17382Using tor to download all build dependencies2021-08-16T20:30:13ZboklmUsing tor to download all build dependenciesThe current Tor Messenger build process does not use tor to download the various build dependencies. We should add an option (on by default) to do that and allow anonymous builders.The current Tor Messenger build process does not use tor to download the various build dependencies. We should add an option (on by default) to do that and allow anonymous builders.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/17381Adapting the gitian/*.sh release scripts2022-02-22T17:21:00ZboklmAdapting the gitian/*.sh release scriptsThe various gitian/*.sh scripts will need to be adapted.The various gitian/*.sh scripts will need to be adapted.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/17379Using the same build process in Tor Browser and Tor Messenger2021-08-16T20:28:30ZboklmUsing the same build process in Tor Browser and Tor MessengerThe current Tor Browser build process is using gitian to run the build inside virtual machines, with some shell scripts to download and verify dependencies.
Tor Messenger is using a different system to do that.
To make maintenance easi...The current Tor Browser build process is using gitian to run the build inside virtual machines, with some shell scripts to download and verify dependencies.
Tor Messenger is using a different system to do that.
To make maintenance easier, we should try to use the same tools in both projects.
I think one of the main advantages of the way we are building in tor-messenger is that we can do faster builds as we rebuild only what is necessary. All components are built separately, with all built components having an identifier in their filename that is a hash of all their dependencies (build script, commit hash, source tarballs,
distribution used in the container, additional packages installed). We only rebuild a component when its identifier has changed. We currently only have one branch on tor messenger, but with multiple branches (alpha, beta, nightly, etc ...) it would be possible to build the different branches from the same build repository and share the components that are identical.
An other advantage of splitting the build of each component is to be able to share them between different projects. For instance we are also building a Tor Mail bundle from the same repository and sharing some of the components. In the case of Tor Browser and Tor Messenger I think we could share the compilers. Components can also be built differently
depending on which project they are built for, for instance tor-launcher is patched to use a different control port for tor-mail and tor-messenger:
https://gitweb.torproject.org/tor-messenger-build.git/tree/projects/tor-launcher/controlport.patch.tmpl
https://gitweb.torproject.org/tor-messenger-build.git/tree/rbm.conf#n74
I will open child tickets to list all the tasks that need to be done if we want Tor Browser to use the same build process as Tor Messenger.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/17336consider re-dzip'ing language packs2023-05-04T07:11:52ZMark Smithconsider re-dzip'ing language packsWhile doing some MAR file generation experiments, Kathy and I found that running re-dzip.sh on the Firefox language packs resulted in smaller incremental MAR files. Unfortunately, we did not make a note of the number of bytes saved. We s...While doing some MAR file generation experiments, Kathy and I found that running re-dzip.sh on the Firefox language packs resulted in smaller incremental MAR files. Unfortunately, we did not make a note of the number of bytes saved. We should repeat this experiment to determine whether it is worthwhile to re-dzip the language packs.