Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:01:49Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29872Searching from about:tor cause a NoScript XSS warning popup2020-06-16T01:01:49ZboklmSearching from about:tor cause a NoScript XSS warning popupUsing the duckduckgo search box on the about:tor page is causing a NoScript XSS warning window to open.Using the duckduckgo search box on the about:tor page is causing a NoScript XSS warning window to open.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/29848"optionaly" typo in go config2020-06-16T01:01:45ZJeremyRand"optionaly" typo in go configThe comments in http://jqs44zhtxl2uo6gk.onion/builders/tor-browser-build.git/tree/projects/go/config#n24 include a typo; "optionaly" should be "optionally".The comments in http://jqs44zhtxl2uo6gk.onion/builders/tor-browser-build.git/tree/projects/go/config#n24 include a typo; "optionaly" should be "optionally".https://gitlab.torproject.org/legacy/trac/-/issues/29809TBA: Only ship one tor binary per apk2020-06-16T01:01:39ZMatthew FinkelTBA: Only ship one tor binary per apkOrbot bundles all the binaries into a single apk and ships that, this means they only produce one apk for all the platforms they support. Unfortunately, with fennec, we must create one apk per arch. However, we didn't modify orbot's buil...Orbot bundles all the binaries into a single apk and ships that, this means they only produce one apk for all the platforms they support. Unfortunately, with fennec, we must create one apk per arch. However, we didn't modify orbot's build system so it only includes one binary for the target architecture, therefore our apks include tor binaries for armeabi, armeabi-v7a, and x86.
This causes a little bloat and we can avoid this, but the more problematic result is it confuses Google Play such that Google Play thinks each apk supports all of those architectures, therefore we can't upload one apk for armv7-only and x86-only, because one of them will override the other.https://gitlab.torproject.org/legacy/trac/-/issues/29798build1 for Tor Browser 8.5a9 is broken in mobile packaging step2020-06-16T01:01:37ZGeorg Koppenbuild1 for Tor Browser 8.5a9 is broken in mobile packaging stepWhen packaging mobile Firefox an error occurs:
```
0:00.63 fa:
0:00.63 changed: 2104
0:00.63 changed_w: 10959
0:00.63 keys: 41
0:00.63 missing: 23
0:00.63 missingInFiles: 48
0:00.63 missing_w: 580
0:00.63 obsolete: 23
0:00.63 unc...When packaging mobile Firefox an error occurs:
```
0:00.63 fa:
0:00.63 changed: 2104
0:00.63 changed_w: 10959
0:00.63 keys: 41
0:00.63 missing: 23
0:00.63 missingInFiles: 48
0:00.63 missing_w: 580
0:00.63 obsolete: 23
0:00.63 unchanged: 87
0:00.63 unchanged_w: 102
0:00.63 93% of entries changed
0:00.69 \nGenerating: search-jar
0:00.76 Traceback (most recent call last):
0:00.76 File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
0:00.76 "__main__", fname, loader, pkg_name)
0:00.76 File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
0:00.76 exec code in run_globals
0:00.76 File "/var/tmp/build/firefox-16cd9b21911c/python/mozbuild/mozbuild/action/jar_maker.py", line 17, in <module>
0:00.76 sys.exit(main(sys.argv[1:]))
0:00.76 File "/var/tmp/build/firefox-16cd9b21911c/python/mozbuild/mozbuild/action/jar_maker.py", line 13, in main
0:00.76 return mozbuild.jar.main(args)
0:00.76 File "/var/tmp/build/firefox-16cd9b21911c/python/mozbuild/mozbuild/jar.py", line 608, in main
0:00.76 jm.makeJar(infile, options.d)
0:00.76 File "/var/tmp/build/firefox-16cd9b21911c/python/mozbuild/mozbuild/jar.py", line 333, in makeJar
0:00.76 self.processJarSection(info, jardir)
0:00.76 File "/var/tmp/build/firefox-16cd9b21911c/python/mozbuild/mozbuild/jar.py", line 388, in processJarSection
0:00.76 self._processEntryLine(e, outHelper, jf)
0:00.76 File "/var/tmp/build/firefox-16cd9b21911c/python/mozbuild/mozbuild/jar.py", line 460, in _processEntryLine
0:00.76 ', '.join(src_base)))
0:00.76 RuntimeError: File "google-b-m.xml" not found in /var/tmp/build/firefox-16cd9b21911c/mobile/locales/searchplugins, /var/tmp/build/firefox-16cd9b21911c/obj-arm-linux-androideabi/mobile/locales/.deps/generated_fa, /var/tmp/build/firefox-16cd9b21911c/obj-arm-linux-androideabi/mobile/locales/.deps/generated_fa, /var/tmp/build/firefox-16cd9b21911c/obj-arm-linux-androideabi/mobile/locales
0:00.76 Makefile:117: recipe for target 'searchplugins' failed
0:00.76 make[3]: *** [searchplugins] Error 1
0:00.76 Makefile:144: recipe for target 'chrome-fa' failed
0:00.76 make[2]: *** [chrome-fa] Error 2
0:00.76 Makefile:66: recipe for target 'chrome-fa' failed
0:00.76 make[1]: *** [chrome-fa] Error 2
0:00.76 /var/tmp/build/firefox-16cd9b21911c/mobile/android/build.mk:60: recipe for target 'chrome-fa' failed
0:00.76 make: *** [chrome-fa] Error 2
```
That's due to https://bugzilla.mozilla.org/show_bug.cgi?id=1510296 backporting a search engine related patch that changes the google search engine on mobile from `google` to `google-b-m` without providing a respective .xml file.
And as Mozilla does not build Firefox for mobile on ESR 60 this remained undetected.https://gitlab.torproject.org/legacy/trac/-/issues/29794Update TBA built-in bridges2020-06-16T01:01:37ZMatthew FinkelUpdate TBA built-in bridgesAfter #28802, we should update the built-in bridges provided by tor browser on android.After #28802, we should update the built-in bridges provided by tor browser on android.https://gitlab.torproject.org/legacy/trac/-/issues/29733Disable NoSript XSS protection for now due to bug 15325302020-06-16T01:01:30ZGeorg KoppenDisable NoSript XSS protection for now due to bug 1532530It seems there is a Firefox bug in relation to NoScript's XSS feature that makes large uploads stall which is bad for SecureDrop, Onionshare and others. We'll therefore disable the XSS feature for now until this gets fixed.It seems there is a Firefox bug in relation to NoScript's XSS feature that makes large uploads stall which is bad for SecureDrop, Onionshare and others. We'll therefore disable the XSS feature for now until this gets fixed.https://gitlab.torproject.org/legacy/trac/-/issues/29675Nightly build should fail if "make fetch" fails2020-06-13T17:41:20ZboklmNightly build should fail if "make fetch" failsWe run `make fetch` during the nightly builds to fetch the latest commits before starting the build. However we ignore the exit code from `make fetch`, so if there an error in the middle of fetching, then we build with old commits.
Inst...We run `make fetch` during the nightly builds to fetch the latest commits before starting the build. However we ignore the exit code from `make fetch`, so if there an error in the middle of fetching, then we build with old commits.
Instead we should make the build fail if there was an error in `make fetch`, so we can know there was something wrong and can fix it.cypherpunkscypherpunkshttps://gitlab.torproject.org/legacy/trac/-/issues/29667Add android-x86 to nightly builds2020-06-13T17:41:20ZboklmAdd android-x86 to nightly builds#27210 added support to `tor-browser-build` for android-x86. We should now add it to our nightly builds.#27210 added support to `tor-browser-build` for android-x86. We should now add it to our nightly builds.cypherpunkscypherpunkshttps://gitlab.torproject.org/legacy/trac/-/issues/29660TorBrowser > 8.0.2, XMPP - can not connect to socks5 anymore2020-06-16T01:01:24ZTracTorBrowser > 8.0.2, XMPP - can not connect to socks5 anymoreHi,
I set up my xmpp client to use a SOCKS5 proxy on 127.0.0.1 with ports 9050 or 9150 (see https://riseup.net/en/chat/clients/adium#using-tor) for years is could connect to TOR. This stopped working in any version of the TorBrowser > 8...Hi,
I set up my xmpp client to use a SOCKS5 proxy on 127.0.0.1 with ports 9050 or 9150 (see https://riseup.net/en/chat/clients/adium#using-tor) for years is could connect to TOR. This stopped working in any version of the TorBrowser > 8.0.2.
**Trac**:
**Username**: o9491020https://gitlab.torproject.org/legacy/trac/-/issues/29626TBA: Application name is now "Always-On Notifications"2020-06-16T01:01:20ZMatthew FinkelTBA: Application name is now "Always-On Notifications"Why? eighthave noticed this, too. It seems like this is coming from Orbot's `pref_use_persistent_notifications_title` string? Something changed between 8.5a7 and 8.5a8.Why? eighthave noticed this, too. It seems like this is coming from Orbot's `pref_use_persistent_notifications_title` string? Something changed between 8.5a7 and 8.5a8.https://gitlab.torproject.org/legacy/trac/-/issues/29554about:preferences hash urls do not work properly in Tor Browser2020-06-16T01:01:08Zrichardabout:preferences hash urls do not work properly in Tor BrowserFirefox allows you to access various sub-sections of the various pages in about:preferences by accessing urls in the form about:preferences#$(pane)-$(section). Ie, to access the Privacy -> Reports section you can navigate to: about:prefe...Firefox allows you to access various sub-sections of the various pages in about:preferences by accessing urls in the form about:preferences#$(pane)-$(section). Ie, to access the Privacy -> Reports section you can navigate to: about:preferences#privacy-reports
In latest version of vanilla Firefox this navigates to the Privacy pane and then scrolls down to the Reports section. In Tor Browser, it only navigates to the Privacy pane, without scrolling down the the Reports section.
This feature is required for the 'Advanced Security Settings...' button to work correctly in the new security UI.
The relevant place to start looking is in the init_all() and gotoPref() methods in /browser/components/preferences/in-content/preferences.jsrichardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/29049Backport JS Poison Patch2020-06-16T01:00:04ZTom Rittertom@ritter.vgBackport JS Poison Patchhttps://bugzilla.mozilla.org/show_bug.cgi?id=981991
This will make reading a freed object crash instead of succeeding.https://bugzilla.mozilla.org/show_bug.cgi?id=981991
This will make reading a freed object crash instead of succeeding.https://gitlab.torproject.org/legacy/trac/-/issues/27485Onboarding: user not taught *how* to open the security-slider dialog2020-06-16T00:50:10ZdmrOnboarding: user not taught *how* to open the security-slider dialog"Security" / "Choose your experience" / "Review Settings" Onboarding screen doesn't direct the user how open the security-slider dialog outside of the Onboarding screen.
A user may want to open this dialog again, and potentially knowing..."Security" / "Choose your experience" / "Review Settings" Onboarding screen doesn't direct the user how open the security-slider dialog outside of the Onboarding screen.
A user may want to open this dialog again, and potentially knowing how to return to Onboarding, they may take a very inefficient path through the Onboarding functionality instead of the simple means.
(Encountered in TB 8.0)https://gitlab.torproject.org/legacy/trac/-/issues/27484Onboarding: unintuitive not-navigation buttons, starting with "Circuit Displa...2020-06-16T00:50:10ZdmrOnboarding: unintuitive not-navigation buttons, starting with "Circuit Display" / "See My Path"The "See My Path" button's effects are unintuitive for a user at that point in sequence, and the button click may get skipped by people utilizing a different form of navigation through Onboarding.
Prior to "See My Path", each button was...The "See My Path" button's effects are unintuitive for a user at that point in sequence, and the button click may get skipped by people utilizing a different form of navigation through Onboarding.
Prior to "See My Path", each button was essentially a "go to next" button.
Nothing in the "Circuit Display" paragraph indicates it will have a different effect than that.
Furthermore, the button doesn't advance the Onboarding screen (unlike prior buttons) - it just marks "Circuit Display" as done, thus leaving either of these navigation paths:
* user directly clicking on "Security" (or later)
* closing the Onboarding window and re-opening it (which "advances" the Onboarding because "Circuit Display" was marked as done)
A user may thus //also// try to click the button again, being so far trained to expect the button to cause navigation.
A similar thing happens for "Security" / "Review Settings" and "Experience Tips" / "See FAQs". However, for "Security", the text in the paragraph does indicate that something else will happen in response to the button click.
(Encountered in TB 8.0)https://gitlab.torproject.org/legacy/trac/-/issues/23359WebExtensions icons are not shown on first start but on restart2020-06-15T23:47:04ZGeorg KoppenWebExtensions icons are not shown on first start but on restartWhen testing the release candidate for 7.0.5 I realized that with the WebExtensions-based HTTPS-Everywhere the icon is not shown anymore on the toolbar on first start. After a restart it is visible again.When testing the release candidate for 7.0.5 I realized that with the WebExtensions-based HTTPS-Everywhere the icon is not shown anymore on the toolbar on first start. After a restart it is visible again.richardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/13747Block non .onion content on .onion addresses (mixed content blocking)2020-06-15T23:22:13ZWilliam BudingtonBlock non .onion content on .onion addresses (mixed content blocking)The .onion URL for a given THS instance is a fingerprint of the public key, thus ensuring authenticity of the service. For this reason, some assume the same security assurances for .onion addresses as they would for https, with the adde...The .onion URL for a given THS instance is a fingerprint of the public key, thus ensuring authenticity of the service. For this reason, some assume the same security assurances for .onion addresses as they would for https, with the added assurances that hidden services provide. For instance, the major browsers have chosen to not load http resources when accessing an https site, blocking mixed content. However, there is no protection against mixed content being loaded in the TBB for .onion addresses when they include resources from http URLs. For any .onion URL which includes http resources, an attacker controlling an exit node could perform a Man in the Middle attack, providing malicious javascript which modifies the content of the DOM.
One would hope that an http THS would never include remote resources from an http site if they would like to protect their users. In fact, one would hope that a THS would never load any resources at all from a source they do not control. But this is no guarantee that they won't. It seems like a good security measure to disallow http resources from being loaded in TBB.