tor-browser-build issueshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues2023-01-05T14:21:15Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40531Tor Browser requires D-Bus' /etc/machine-id on Arch Linux2023-01-05T14:21:15ZTracTor Browser requires D-Bus' /etc/machine-id on Arch LinuxHello Tor developers,
I have been playing with firejail to harden the Tor Browser on Arch Linux. And I've noticed, that when creating a private /etc folder with only the minimal required files, the file /etc/machine-id is necessary or t...Hello Tor developers,
I have been playing with firejail to harden the Tor Browser on Arch Linux. And I've noticed, that when creating a private /etc folder with only the minimal required files, the file /etc/machine-id is necessary or the Firefox in Tor Browser will segfault.
http://0pointer.de/public/systemd-man/machine-id.html
> The machine ID is usually generated from a random source during system installation and stays constant for all subsequent boots.
This could be a potential issue, when tor browser gets exploited and someone can uniquely identify the host machine with that ID.
Maybe it would be feasible to build Firefox without the D-Bus dependency on Linux to solve this?
Related firejail ticket:
https://github.com/netblue30/firejail/issues/955
Thanks for making Tor!
**Trac**:
**Username**: robotanarchyhttps://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/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/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/40535macOS Sierra Finder complains that 'tor' isn't signed2022-08-02T14:23:46ZteormacOS Sierra Finder complains that 'tor' isn't signedI have a macOS user with permissions set to allow apps downloaded from 'App Store and identified developers'.
This user is also a 'Parental Controls' account, which means each executable is checked separately on open.
When I open Tor B...I have a macOS user with permissions set to allow apps downloaded from 'App Store and identified developers'.
This user is also a 'Parental Controls' account, which means each executable is checked separately on open.
When I open Tor Browser, I get a message saying that tor (which on macOS is a shell script) is not signed. This seems to go away after the app is approved via parental controls.
(There might not be anything we can do to fix this issue.)https://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/22341Make sure to pick up zstd+lzma support for tor in Tor Browser2023-11-09T08:42:24ZGeorg KoppenMake sure to pick up zstd+lzma support for tor in Tor BrowserWe might need to adapt our descriptors to make sure tor in Tor Browser is built with zstd+lzma support as well.
This is the parent ticket and the work, if needed, is done in child tickets.We might need to adapt our descriptors to make sure tor in Tor Browser is built with zstd+lzma support as well.
This is the parent ticket and the work, if needed, is done in child tickets.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/22633Running ./start-tor-browser.desktop --detach --log creates two log files2022-08-03T14:52:38ZGeorg KoppenRunning ./start-tor-browser.desktop --detach --log creates two log filesAdding `--detach` explicitely creates two log files one inside the current working directory containing all the logs (which is okay) and an empty one in the parent directory (which is not okay).
This got reported on our blog: https://bl...Adding `--detach` explicitely creates two log files one inside the current working directory containing all the logs (which is okay) and an empty one in the parent directory (which is not okay).
This got reported on our blog: https://blog.torproject.org/comment/269202#comment-269157.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40576Fontconfig warning: remove 'blank' configuration2023-10-03T15:38:00ZcypherpunksFontconfig warning: remove 'blank' configurationIn the log:
> Fontconfig warning: line 145: blank doesn't take any effect anymore. please remove it from your fonts.conf
Quickly skimming fontconfig's changelog one finds:
> commit 46b2c62faa64250eec3981ee816e91a9a3dee857
> Author: Ak...In the log:
> Fontconfig warning: line 145: blank doesn't take any effect anymore. please remove it from your fonts.conf
Quickly skimming fontconfig's changelog one finds:
> commit 46b2c62faa64250eec3981ee816e91a9a3dee857
> Author: Akira TAGOH <akira@tagoh.org>
> Date: Wed Jun 17 16:29:08 2015 +0900
>
> Add a warning for blank in fonts.conf
>
> and remove the unnecessary code for parsing blanks
>
> src/fcxml.c | 7 +++++++
> 1 file changed, 7 insertions(+)Sponsor 131 - Phase 2 - Privacy BrowserPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/22917Use --disable-auto-import on mingw builds of TBB and tor2022-08-03T13:09:27ZArthur EdelsteinUse --disable-auto-import on mingw builds of TBB and torA cypherpunk [ticket:22563#comment:8 pointed out] that we could possibly use --disable-auto-import on our mingw builds of TBB and tor. This would probably require patching Firefox as well as stack protection in gcc/mingw.A cypherpunk [ticket:22563#comment:8 pointed out] that we could possibly use --disable-auto-import on our mingw builds of TBB and tor. This would probably require patching Firefox as well as stack protection in gcc/mingw.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23024Flags to increase hardening on Windows2022-10-06T01:14:43ZArthur EdelsteinFlags to increase hardening on WindowsWe can add `-fstack-protector-all` and `-D_FORTIFY_SOURCE=2` to our Windows build for some extra protection.We can add `-fstack-protector-all` and `-D_FORTIFY_SOURCE=2` to our Windows build for some extra protection.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23045Replace *.tlb with our own during build time2023-01-05T14:10:27ZGeorg KoppenReplace *.tlb with our own during build timemingw-w64 contains `oleacc.tlb` (see 7c90d5921bd2cb678eec09d05b10ce6fd13463bc) and `stdole2.tlb` (see 17e09279acf8b7f44d731c9a65541a474af4f1b5) which are binary blobs needed for compiling Tor Browser. We can do better, though, and get ri...mingw-w64 contains `oleacc.tlb` (see 7c90d5921bd2cb678eec09d05b10ce6fd13463bc) and `stdole2.tlb` (see 17e09279acf8b7f44d731c9a65541a474af4f1b5) which are binary blobs needed for compiling Tor Browser. We can do better, though, and get rid of the ones in the repo and build them ourselves.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23401Add option to download everything needed for the build2023-01-05T14:10:49ZboklmAdd option to download everything needed for the buildWe are currently downloading files in the order in which we use them.
Some files are downloaded early (files for which we need their checksum to compute some output files), while other files are downloaded just before their component is...We are currently downloading files in the order in which we use them.
Some files are downloaded early (files for which we need their checksum to compute some output files), while other files are downloaded just before their component is built (signature files, or files for which we already know the checksum).
We should add an option to download everything without starting the build, which should then allow someone to do the build offline.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23594Enable GitLab CI for Tor Browser Bundle2021-08-16T20:41:56ZTracEnable GitLab CI for Tor Browser BundleAs done for Tor, I'd like to propose GitLab CI integration for Tor Browser Bundle at https://gitlab.com/krichter/tor-browser-bundle/merge_requests/1. I currently fails with the same build error that I'm experiencing locally, so it might ...As done for Tor, I'd like to propose GitLab CI integration for Tor Browser Bundle at https://gitlab.com/krichter/tor-browser-bundle/merge_requests/1. I currently fails with the same build error that I'm experiencing locally, so it might have discovered an issue already or `.gitlab-ci.yml` is wrong.
**Trac**:
**Username**: krichterhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23631Improve sudo need2021-03-01T16:46:05ZTom Rittertom@ritter.vgImprove sudo needRight now the Tor Browser build takes a long time, and sudo is needed periodically throughout it. This means you have to either run it as root, babysit it, or set your user account up with passwordless sudo. All of those kinda stink.
It...Right now the Tor Browser build takes a long time, and sudo is needed periodically throughout it. This means you have to either run it as root, babysit it, or set your user account up with passwordless sudo. All of those kinda stink.
It's be cool if we could improve that a bit. Ideas:
- Write a setuid program that execs the necessary commands but provides input and directory filtering (directory path either compiled in or read from a root-owned file I guess)
- Same idea but instead of setuid, it's set up to be run with passwordless sudo
- Somehow request sudo access in the beginning and retain it through the whole script (without running everything as root)Tor Browser: 10.5boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23656Use .mozconfig files in tor-browser repo for rbm builds2022-10-24T07:09:56ZGeorg KoppenUse .mozconfig files in tor-browser repo for rbm buildsRight now, if we need to change .mozconfig files, we need to change them both in the tor-browser repository and in tor-browser-build (see the respective note in `README.HACKING`).
We should find a way to leave the .mozconfig files in th...Right now, if we need to change .mozconfig files, we need to change them both in the tor-browser repository and in tor-browser-build (see the respective note in `README.HACKING`).
We should find a way to leave the .mozconfig files in the tor-browser repository for local builds outside of `rbm` (and only change them there when writing tor-browser patches) but use them nevertheless for `rbm`-based builds (probably with some modifications if needed).Sponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23657Decide directories used for signed/unsigned builds in tor-browser-builds2022-02-22T17:22:29ZboklmDecide directories used for signed/unsigned builds in tor-browser-buildsWith gitian builds, all builds (signed and unsigned) were stored in the gitian directory directly.
I remember having issues when generating incremental mars which were done with unsigned osx mars instead of the signed ones. To avoid tha...With gitian builds, all builds (signed and unsigned) were stored in the gitian directory directly.
I remember having issues when generating incremental mars which were done with unsigned osx mars instead of the signed ones. To avoid that issue I have started with separating signed and unsigned builds in tor-browser-build. However it seems the new process is confusing and error-prone during the signing process, so we should think more about what directories we want to use in the different steps (or if we want to go back to using only one).
I think having different directories could also be useful if we want to add some scripts helping with the intermediate signing steps.
What we currently have is:
- the build target creates builds in the directory `unsigned`
- the incrementals target generates incremental mars in the `unsigned` directory. However it is using/downloading the mar files from the old version in the `unsigned` directory too, while it should be done from a signed build (for the osx ones). Maybe we should fix the incrementals step to use the old version from the `signed` directory instead.
- the dmg2mar target is using the `signed` directory. However at this point, only the dmg files are signed, so it is confusing to put all the files in the `signed` directory. Maybe an intermediate directory should be used instead?
- the update_responses target is using the `signed` directory. I think this one is correct as update responses should only be done from a fully signed build.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23688Add GitLab CI script2021-08-16T20:44:30ZTracAdd GitLab CI scriptAs [suggested and merged for tor](https://trac.torproject.org/projects/tor/ticket/22891) I'd like to propose a GitLab CI script for Tor Browser. My intention to be able to build `tor-browser-bundle` locally which I tried for some time an...As [suggested and merged for tor](https://trac.torproject.org/projects/tor/ticket/22891) I'd like to propose a GitLab CI script for Tor Browser. My intention to be able to build `tor-browser-bundle` locally which I tried for some time and failed because of error which I hope will be brought to the attention of devs automatically rather than after painful reports.
The script currently uses Ubuntu 17.04 only, but since GitLab CI is based on Docker images, the number of possible OS to test on is basically infinite.
**Trac**:
**Username**: krichterhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23707Enable "Sandbox 1" in the torrc for the Tor Browser for Linux builds2021-08-16T20:45:20ZcypherpunksEnable "Sandbox 1" in the torrc for the Tor Browser for Linux buildsFrom legacy/trac#23378 "Sandbox 1" seems to no longer be an experimental feature, and it may be good (or not?) to see it enabled for the little-t-tor that is bundled with alpha Tor Browser Linux buildsFrom legacy/trac#23378 "Sandbox 1" seems to no longer be an experimental feature, and it may be good (or not?) to see it enabled for the little-t-tor that is bundled with alpha Tor Browser Linux buildshttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40536Look into fuzzing our tor-browser patches2023-01-05T14:21:59ZGeorg KoppenLook into fuzzing our tor-browser patchesAs part of Sponsor4 and our switch to have specific debug builds which allow us to detect bugs earlier we should look into fuzzing our browser patches.
Mozilla already does fuzzing and we might learn something from them. Also, some of t...As part of Sponsor4 and our switch to have specific debug builds which allow us to detect bugs earlier we should look into fuzzing our browser patches.
Mozilla already does fuzzing and we might learn something from them. Also, some of the things mentioned in https://blog.mozilla.org/security/2012/06/20/7-tips-for-fuzzing-firefox-more-effectively/ might be a good starting point, too.