Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-15T23:34:31Zhttps://gitlab.torproject.org/legacy/trac/-/issues/18800Remove localhost DNS lookup in nsProfileLock.cpp2020-06-15T23:34:31ZMark SmithRemove localhost DNS lookup in nsProfileLock.cppIn #18546, Mike said:
We should get rid of the damn DNS lookup for localhost in toolkit/profile/nsProfileLock.cpp.In #18546, Mike said:
We should get rid of the damn DNS lookup for localhost in toolkit/profile/nsProfileLock.cpp.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18799disable Network Tickler2020-06-15T23:34:31ZMark Smithdisable Network TicklerIn #18546, Mike said:
We should patch the "Network Tickler" to be disabled for real, since it looks like it may now apply to the desktop as well.In #18546, Mike said:
We should patch the "Network Tickler" to be disabled for real, since it looks like it may now apply to the desktop as well.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18791Fix for #13252 does not compile on ESR 452020-06-15T23:34:30ZGeorg KoppenFix for #13252 does not compile on ESR 45I tried to test our hardened builds setup with the latest branch Arthur posted (15197+11) and the build failed badly pretty early:
```
Reticulating splines...
Traceback (most recent call last):
File "./config.status", line 1061, in <mo...I tried to test our hardened builds setup with the latest branch Arthur posted (15197+11) and the build failed badly pretty early:
```
Reticulating splines...
Traceback (most recent call last):
File "./config.status", line 1061, in <module>
config_status(**args)
File "/home/debian/build/tor-browser/python/mozbuild/mozbuild/config_status.py", line 175, in config_status
definitions = list(definitions)
File "/home/debian/build/tor-browser/python/mozbuild/mozbuild/frontend/emitter.py", line 177, in emit
objs = list(self.emit_from_context(out))
File "/home/debian/build/tor-browser/python/mozbuild/mozbuild/frontend/emitter.py", line 608, in emit_from_context
for obj in self._process_sources(context, passthru):
File "/home/debian/build/tor-browser/python/mozbuild/mozbuild/frontend/emitter.py", line 797, in _process_sources
'exist: \'%s\'' % (symbol, full_path), context)
mozbuild.frontend.reader.SandboxValidationError:
==============================
ERROR PROCESSING MOZBUILD FILE
==============================
The error occurred while processing the following file or one of the files it includes:
/home/debian/build/tor-browser/xpcom/io/moz.build
The error occurred when validating the result of the execution. The reported error is:
File listed in UNIFIED_SOURCES does not exist: '/home/debian/build/tor-browser/xpcom/io/TorFileUtils.cpp'
*** Fix above errors and then restart with\
"make -f client.mk build"
make: *** [configure] Error 1
```
Not sure if that's a rebase issue or something different yet.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18777restore "black on black constrast fix" to ESR452020-06-15T23:34:25ZArthur Edelsteinrestore "black on black constrast fix" to ESR45brade and mcs's patch to prevent exposing system colors to CSS and canvas was partially upstreamed, but there is another part that needs to be rebased to ESR45. Because this task is somewhat more complicated, I am creating this ticket.
...brade and mcs's patch to prevent exposing system colors to CSS and canvas was partially upstreamed, but there is another part that needs to be rebased to ESR45. Because this task is somewhat more complicated, I am creating this ticket.
It would also be good to have a unit test under Tor Project's control that ensures that the upstreamed part and the non-upstreamed part are providing complete protection.
The original patch in TBB/ESR38 is
8b3d00b982db7a1b3101dc9318c1301bf944b161
The part upstreamed to mozilla (and now in ESR45) is
61c6a3b38353835315f2d1b9761de9c95ba83c8dMark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18770SVGs should not show in Page Info when disabled2020-06-15T23:34:24ZMark SmithSVGs should not show in Page Info when disabledWhen svg.in-content.enabled = false, SVGs should not be rendered in the Media tab within Page Info.
Also see ticket:15197#comment:32 and ticket:15197#comment:33.
We should fix this in the ESR45 timeframe (although it is an issue with ou...When svg.in-content.enabled = false, SVGs should not be rendered in the Media tab within Page Info.
Also see ticket:15197#comment:32 and ticket:15197#comment:33.
We should fix this in the ESR45 timeframe (although it is an issue with our ESR38-based browser too).Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18603failIfMajorPerformanceCaveat in a WebGL context might aid in fingerprinting2020-06-15T23:34:08ZGeorg KoppenfailIfMajorPerformanceCaveat in a WebGL context might aid in fingerprintinghttps://bugzilla.mozilla.org/show_bug.cgi?id=1164970 implemented `failIfMajorPerformanceCaveat` that makes the context creation fail when layer acceleration is not supported. We should investigate whether our WebGL normalizing is affecte...https://bugzilla.mozilla.org/show_bug.cgi?id=1164970 implemented `failIfMajorPerformanceCaveat` that makes the context creation fail when layer acceleration is not supported. We should investigate whether our WebGL normalizing is affected by this.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18602Make sure our SVG disabling patches work with SVG favicons2020-06-15T23:34:08ZGeorg KoppenMake sure our SVG disabling patches work with SVG faviconshttps://bugzilla.mozilla.org/show_bug.cgi?id=366324 landed the support for SVG favicons. We should make sure that these are disabled properly on level High on our Security Slider and that there are no crashes involved.https://bugzilla.mozilla.org/show_bug.cgi?id=366324 landed the support for SVG favicons. We should make sure that these are disabled properly on level High on our Security Slider and that there are no crashes involved.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18455modify Tor Browser packaging to avoid language prompt2020-06-15T23:33:44ZMark Smithmodify Tor Browser packaging to avoid language promptWe use a Tor Launcher with the language prompt feature included for hardened builds but must be careful not to included that feature in regular builds. I suspect this is causing some pain for Georg at least.
Kathy and I tried to modify ...We use a Tor Launcher with the language prompt feature included for hardened builds but must be careful not to included that feature in regular builds. I suspect this is causing some pain for Georg at least.
Kathy and I tried to modify Tor Launcher to skip the language prompt if there is only one choice of language, but that turns out to be difficult to do because (1) the language prompt is the first dialog opened, (2) we need to keep a modal dialog open to prevent Firefox from starting all the way, and (3) the API to enumerate the installed language packs is asynchronous (so we cannot call it until after we have a modal dialog open).
We thought of another, simpler solution: modify the gitian descriptors for the bundle step to add these two preferences to the extension-overrides.js file:
intl.locale.matchOS = false
extensions.torlauncher.prompt_for_locale = false
If other people think this is a good idea I will create a patch.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18371TorBrowser.app.meek-http-helper symlinks incompatible with Gatekeeper signing2020-06-15T23:33:39ZMark SmithTorBrowser.app.meek-http-helper symlinks incompatible with Gatekeeper signingExperimentation shows that the symlink approach that we currently use to create a meek-specific "copy" of Tor Browser on Mac OS is not compatible with Apple's Gatekeeper code signing. Apple's codesign command complains about an invalid I...Experimentation shows that the symlink approach that we currently use to create a meek-specific "copy" of Tor Browser on Mac OS is not compatible with Apple's Gatekeeper code signing. Apple's codesign command complains about an invalid Info.plist because it is checking that the application binary (firefox) is where the Info.plist says it is and symlinks are apparently not traversed.
One possible solution is to eliminate the TorBrowser.app.meek-http-helper linked app bundle and add support to firefox for a command line option that causes the application to run as a background app. See https://trac.torproject.org/projects/tor/ticket/11429#comment:8 for more info.
Perhaps if we make the call to TransformProcessType() very early during firefox startup the problem that occurred before (dock icon appearing briefly during startup of the meek browser) will not occur. Another possibility is to change the Info.plist for Tor Browser so that the dock icon is hidden by default and then un-hide it when *not* running as the meek helper browser.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18369Linux Tor Browser should not store data in the Browser (application) directory2020-06-15T23:33:38ZMark SmithLinux Tor Browser should not store data in the Browser (application) directoryWe want to move to a model on all platforms where user data is not stored in the application area. This is the Linux-specific ticket. See #13252 for the original, Mac-specific ticket.We want to move to a model on all platforms where user data is not stored in the application area. This is the Linux-specific ticket. See #13252 for the original, Mac-specific ticket.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18367Windows Tor Browser should not store data in the Browser (application) directory2020-06-15T23:33:37ZMark SmithWindows Tor Browser should not store data in the Browser (application) directoryWe want to move to a model on all platforms where user data is not stored in the application area. This is the Windows-specific ticket. See #13252 for the original, Mac-specific ticket.We want to move to a model on all platforms where user data is not stored in the application area. This is the Windows-specific ticket. See #13252 for the original, Mac-specific ticket.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18292staged updates fail on Windows2020-06-15T23:33:17ZMark Smithstaged updates fail on WindowsOn Windows, staged updates currently fail (I am not sure if they ever worked correctly, but I think they have not been working at least since MAR signing was introduced). The good news is that typically users do not notice the failure be...On Windows, staged updates currently fail (I am not sure if they ever worked correctly, but I think they have not been working at least since MAR signing was introduced). The good news is that typically users do not notice the failure because the updater silently falls back to doing an in-place update. The failure occurs after the user restarts their browser to apply the update: switching to the staged copy that is under Browser/updated fails because files are in use under the Browser directory, and Windows does not allow a directory to be renamed if any open handles point to files within the directory or if any DLLs located in the directory are in use (at least that is my understanding based on my limited knowledge of system behavior on Windows).
To fix this we will need to do two things:
1) Copy updater.exe and the DLLs it uses into a temporary directory and run it from there.
2) Modify the updater.exe code to not open and hold onto a handle for a log file that is located under Browser/TorBrowser.
Because these changes will not be trivial to implement and test, I propose that for the stable branch of Tor Browser (5.5) we disable staged updates on Windows. That is a safe thing to do and it will speed up updates since currently updates are applied twice (one time to stage the update, which then fails, and a second time to do an in-place update, which succeeds). Of course we should fix this correctly for TB 6.0 and test it during one or more of our alpha cycles.
One challenge is knowing which of our bundled DLLs the updater depends on. The set of DLLs might change over time, and some components such as NSS load DLLs at runtime (so it is not just a matter of checking DLL dependencies by dumping linker info from updater.exe).
This ticket was split off from #18170.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18199Firefox icon for browser after update2020-06-15T23:32:57ZcypherpunksFirefox icon for browser after updateAfter every update, when you restart tor browser it restarts with Firefox's icon instead of the default tor browser icon. Only if you close it and reopen again, it loads the default tor browser icon. From what I can see it still connects...After every update, when you restart tor browser it restarts with Firefox's icon instead of the default tor browser icon. Only if you close it and reopen again, it loads the default tor browser icon. From what I can see it still connects to tor even when it has the Firefox icon but is there any reason to be concerned about this?Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18170After an update to Tor Browser 5.5 only changelog tab is shown2020-06-15T23:32:46ZGeorg KoppenAfter an update to Tor Browser 5.5 only changelog tab is shownOn my Windows 7 test machine there is only the changelog tab shown after an upgrade from 5.0.7. No about:tor tab is visible as it should probably be.On my Windows 7 test machine there is only the changelog tab shown after an upgrade from 5.0.7. No about:tor tab is visible as it should probably be.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18168Iframe based AJAX call blocked by popup-blocker or opening in new tab2020-06-15T23:32:44ZTracIframe based AJAX call blocked by popup-blocker or opening in new tabIframe based AJAX call blocked by popup-blocker. After allowing popups, form submits to new tab instead of hidden iframe.
Issue appeared in TBB 5.5. TBB 5.0.7 (previous stable) works with same code normally.
To reproduce go to http:...Iframe based AJAX call blocked by popup-blocker. After allowing popups, form submits to new tab instead of hidden iframe.
Issue appeared in TBB 5.5. TBB 5.0.7 (previous stable) works with same code normally.
To reproduce go to http://dmirrgetyojz735v.onion/d/#set-lang:en and try to make post with JS support enabled.
Code of submit and AJAX handlers can be found in http://dmirrgetyojz735v.onion/js/tinaib1.js , seek doPostForm func.
Trace is like
```
WARNING: content window passed to PrivateBrowsingUtils.isWindowPrivate. Use isContentWindowPrivate instead (but only for frame scripts).
pbu_isWindowPrivate@re[/gre/modules/PrivateBrowsingUtils.jsm:25:14](/gre/modules/PrivateBrowsingUtils.jsm:25:14)
nsBrowserAccess.prototype.openURI@chrome://browser/content/browser.js:15194:21
```
Depending of the exact code, call stack may contain func, which actually submitted form.
Tested on Ubuntu 14.04 x64.
**Trac**:
**Username**: sky_kohaiMark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18064Changelog after update is empty on Windows2020-06-15T23:32:20ZMark SmithChangelog after update is empty on WindowsThis is a spinoff from ticket #17917 (there are two different problems). On Windows, the about:tbupdate page will never display the change log. This is due to a path separator bug in the code. Yes, Kathy and I should have tested this on ...This is a spinoff from ticket #17917 (there are two different problems). On Windows, the about:tbupdate page will never display the change log. This is due to a path separator bug in the code. Yes, Kathy and I should have tested this on Windows! Patch coming soon.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/18019Update on non-en-US alpha bundles results in empty dialog being shown2020-06-15T23:32:12ZGeorg KoppenUpdate on non-en-US alpha bundles results in empty dialog being shownIf I update a germen 5.5a5 to 5.5a6 I am greeted with the attached image. There is even no button to cancel this dialog which is pretty confusing. Closing it, though, leads to the changelog being shown.
I guess this dialog pops up in th...If I update a germen 5.5a5 to 5.5a6 I am greeted with the attached image. There is even no button to cancel this dialog which is pretty confusing. Closing it, though, leads to the changelog being shown.
I guess this dialog pops up in the first place because of the do-you-want-to-use-english-for-this-site-question which is supposed to be shown.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/17917Changelog after update is empty if JS is disabled2020-06-15T23:31:58ZGeorg KoppenChangelog after update is empty if JS is disabledThere is no changelog shown after the update to 5.5a5-hardened and no link to the changelog on our blog either. I think this happens because it was the first changelog ever in this series. We might want to be a bit more lenient in this c...There is no changelog shown after the update to 5.5a5-hardened and no link to the changelog on our blog either. I think this happens because it was the first changelog ever in this series. We might want to be a bit more lenient in this case to have a future-proof mechanism for displaying the latest changes.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/17891Window classes change after update restart2020-06-15T23:31:54ZcypherpunksWindow classes change after update restartWhen Tor Browser restarts after an update its window classes change from "Navigator" and "Tor Browser" to "Navigator" and "Firefox". I've found these differences with the xprop tool.
I use the i3 window manager and have it configured to...When Tor Browser restarts after an update its window classes change from "Navigator" and "Tor Browser" to "Navigator" and "Firefox". I've found these differences with the xprop tool.
I use the i3 window manager and have it configured to make Tor Browser floating based on its window class. After the Tor Browser update restart its window was no longer floating.
The issue does not occur when Tor Browser restarts for a new identity.Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/17858Creating incremental MAR files for the hardened builds is broken2020-06-15T23:31:49ZGeorg KoppenCreating incremental MAR files for the hardened builds is brokenASan seems to break the creation of incremental MAR files. `mbsdiff` is basically frozen while trying to cope with libxul. Using a non-ASan MAR tools archive is working.ASan seems to break the creation of incremental MAR files. `mbsdiff` is basically frozen while trying to cope with libxul. Using a non-ASan MAR tools archive is working.Mark SmithMark Smith