Tor Browser 8.0a9 is ready for testing
Hello everyone! We are pleased to announce that we finally have a release candidate for Tor Browser 8.0a9 available for wider testing. After fixing a bunch of release relevant bugs during manual testing here are the bundles that could become Tor Browser 8.0a9: https://people.torproject.org/~gk/builds/8.0a9-build3/ Please give them a try if you can! Tor Browser 8.0a9 is the first alpha based in Firefox 60 ESR. We rebased all of our patches and updated our toolchains to pick up new requirements like Rust support. This alpha contains a bunch of new features which we hope to stabilize until Tor Browser 8 gets stable. Most notably we 1) improved our circuit display and moved it from the Torbutton menu to the identity box in the URL bar domain stressing its strong ties to the URL currently visited. 2) added support for .onion security indicators giving you a little onion icon instead/in addition to the padlock icon in the identity box. 3) added four new locales, da, he, sv-SE, and zh-TW to give users spekaing those languages an improved Tor Browser experience. The plan is to add even more locales once we are confident we can handle the additional load and disk space requirements. 4) replaced our old Torbutton icon with a shiny new one. That's the first step in redesigning our icons and making them compatible with Firefox's Photon UI. There is more to come in the next alphas. 5) are able to provide full content sandboxing support for 64bit Windows bundles thanks to the work done by Tom Ritter. Additionally, we updated a number of components we ship: Tor to 0.3.4.2-alpha, Torbutton to 2.0.1, TorLauncher to 0.2.16.1, HTTPS-Everywhere to 2018.06.21, and NoScript to 10.1.8.2. Expect more bugs than usual in this alpha. Which brings me to the known issues section. The most important ones are listed below: 1) We are still investigating why our generation of incremental update files are failing. We might not have fixed that in time for this release which means only the full update files might be available.[1] 2) Meek is currently broken. We need to update the browser part for make it compatible with ESR60.[2] 3) On Windows localized builds on first start the about:tor page is not shown, rather a weird XML error is visible.[3] 4) Maybe related to 3) NoScript does not seem to work properly on Windows builds right now.[4] 5) We are not done yet with reviewing the network code changes between ESR52 and ESR60. While I don't expect that proxy bypass bugs got introduced between those ESR series, I can't rule it out yet.[5] 6) We disable Stylo on macOS due to reproducibility issues we need to investigate and fix.[6] If any of you will find more issues (and I hope you do) please report them at https://bugs.torproject.org. We track all Tor Browser 8 related issues with the ff60-esr keyword. The full changelog since Tor Browser 8.0a8 is: Tor Browser 8.0a9 -- June 27 2018 * All platforms * Update Firefox to 60.1.0esr * Update Tor to 0.3.4.2-alpha * Update Libevent to 2.1.8 * Update Binutils to 2.26.1 * Update Torbutton to 2.0.1 * Bug 26100: Adapt Torbutton to Firefox 60 ESR * Bug 26430: New Torbutton icon * Bug 24309: Move circuit display to the identity popup * Bug 26128: Adapt security slider to the WebExtensions version of NoScript * Bug 23247: Show security state of .onions * Bug 26129: Show our about:tor page on startup * Bug 26235: Hide new unusable items from help menu * Bug 26058: Remove workaround for hiding 'sign in to sync' button * Bug 20628: Add locales da, he, sv, and zh-TW * Translations update * Update Tor Launcher to 0.2.16.1 * Bug 25750: Update Tor Launcher to make it compatible with Firefox 60 ESR * Bug 20890: Increase control port connection timeout * Bug 20628: Add more locales to Tor Browser * Translations update * Update HTTPS Everywhere to 2018.6.13 * Update NoScript to 10.1.8.2 * Bug 25543: Rebase Tor Browser patches for ESR60 * Bug 23247: Show security state of .onions * Bug 26039: Load our preferences that modify extensions * Bug 17965: Isolate HPKP and HSTS to URL bar domain * Bug 26365: Add potential AltSvc support * Bug 26045: Add new MAR signing keys * Bug 22564: Hide Firefox Sync * Bug 25090: Disable updater telemetry * Bug 26127: Make sure Torbutton and Tor Launcher are not treated as legacy extensions * Bug 26073: Migrate general.useragent.locale to intl.locale.requested * Bug 20628: Make Tor Browser available in da, he, sv-SE, and zh-TW * Bug 12927: Include Hebrew translation into Tor Browser * Bug 21245: Add danish (da) translation * Windows * Bug 26239+24197: Enable content sandboxing for 64bit Windows builds * Bug 22581: Fix shutdown crash * Bug 26424: Disable UNC paths to prevent possible proxy bypasses * Bug 26304: Update zlib to version 1.2.11 * OS X * Bug 24052: Backport fix for bug 1412081 for better file:// handling * Bug 24136: After loading file:// URLs clicking on links is broken on OS X * Bug 24243: Tor Browser only renders HTML for local pages via file:// * Bug 24263: Tor Browser does not run extension scripts if loaded via about:debugging * Bug 24632: Disable snowflake for now until its build is fixed * Bug 26438: Remove broken seatbelt profiles * Linux * Bug 24052: Backport fix for bug 1412081 for better file:// handling * Bug 24136: After loading file:// URLs clicking on links is broken on Linux * Bug 24243: Tor Browser only renders HTML for local pages via file:// * Bug 24263: Tor Browser does not run extension scripts if loaded via about:debugging * Bug 26153: Update selfrando to be compatible with Firefox 60 ESR * Bug 22242: Remove RUNPATH in Linux binaries embedded by selfrando * Bug 26354: Set SSE2 support as minimal requirement for Tor Browser 8 * Build System * All * Bug 26362: Use old MAR format for first ESR60-based alpha * Clean up * Windows * Bug 26203: Adapt tor-browser-build/tor-browser for Windows * Bug 26204: Bundle d3dcompiler_47.dll for Tor Browser 8 * Bug 26205: Don't build the uninstaller for Windows during Firefox compilation * Bug 26206: Ship pthread related dll where needed * Bug 26396: Build libwinpthread reproducible * Bug 25837: Integrate fxc2 into our build setup for Windows builds * Bug 25894: Get a rust cross-compiler for Windows * Bug 25554: Bump mingw-w64 version for ESR 60 * Bug 23561: Fix nsis builds for Windows 64 * Bug 23231: Remove our STL Wrappers workaround for Windows 64bit * Bug 26370: Don't copy msvcr100.dll and libssp-0.dll twice * Bug 26476: Work around Tor Browser crashes due to fix for bug 1467041 * Bug 18287: Use SHA-2 signature for Tor Browser setup executables * OS X * Bug 24632: Update macOS toolchain for ESR 60 * Bug 9711: Build our own cctools for macOS cross-compilation * Bug 25548: Update macOS SDK for Tor Browser builds to 10.11 * Bug 26003: Clean up our mozconfig-osx-x86_64 file * Bug 26195: Use new cctools in our macosx-toolchain project * Bug 25975: Get a rust cross-compiler for macOS * Bug 26475: Disable Stylo to make macOS build reproducible * Linux * Bug 26073: Patch tor-browser-build for transition to ESR 60 * Bug 25540: Stop building and distributing sandboxed tor browser * Bug 25481: Rust support for tor-browser and tor Georg [1] https://trac.torproject.org/projects/tor/ticket/26472 [2] https://trac.torproject.org/projects/tor/ticket/26477 [3] https://trac.torproject.org/projects/tor/ticket/26381 [4] https://trac.torproject.org/projects/tor/ticket/26381#comment:5 [5] https://trac.torproject.org/projects/tor/ticket/22176 [6] https://trac.torproject.org/projects/tor/ticket/26475
I tested torbrowser-install-win64-8.0a9_en-US.exe Upon the browser opening, the initial screen has an orange 'Tor Browser' in the address bar with an icon of a firefox next to it. The onion icon has a flashing triange icon. The banner about checking out the security slider goes away after visiting the first page; the icon stays flashing. When I click the icon and open the Security Settings dialog, the icon is still flashing. In the security settings dialog, clicking the labels directly works, but clicking in the grey space in between or nearby the labels does not. It would be nice if it did, so i didn't have to be so precise with my mouse. After closing the security slider dialog, the icon is still flashing the exclamation triangle. I typed in ritter.vg in the address bar, get redirected to https://ritter.vg but there is not lock icon and the doorhanger off the (i) says 'This connection is not secure. The Tor circuit dialog looks great, clicking the new circuit button worked; however it still says it's not secure. In a new tab, typing in https://ritter.vg directly works. In another new tab typing ritter.vg now shows the lock (this is probably due to HSTS info and a before-navigation upgrade rather than a redirect.) I typed in tomritterbassljd.onion/ (which redirects to SSL serving an expired-but-valid-EV-onion certificate) and got an intersitial saying my connection is not secure. The address bar shows the green lock+onion icon, but no EV indicator. Adding an exception and continuing works and the UI stays the same saying it's a secure connection. The triangle exclamation is still flashing. I realize at this point it's probably the erroneous 'update available' message. I think we should change whatever needs to be changed so that alpha/newer versions don't report they have an 'update' available. I go to youtube and watch a video. I try New Identity. I notice there is a 'New Window' and a 'New Private Window' menu buttons in the hamburger that do the same thing. No crashes, just some UI issues. Super awesome! -tom On 25 June 2018 at 05:41, Georg Koppen <gk@torproject.org> wrote:
Hello everyone!
We are pleased to announce that we finally have a release candidate for Tor Browser 8.0a9 available for wider testing. After fixing a bunch of release relevant bugs during manual testing here are the bundles that could become Tor Browser 8.0a9:
https://people.torproject.org/~gk/builds/8.0a9-build3/
Please give them a try if you can!
Tor Browser 8.0a9 is the first alpha based in Firefox 60 ESR. We rebased all of our patches and updated our toolchains to pick up new requirements like Rust support.
This alpha contains a bunch of new features which we hope to stabilize until Tor Browser 8 gets stable. Most notably we
1) improved our circuit display and moved it from the Torbutton menu to the identity box in the URL bar domain stressing its strong ties to the URL currently visited.
2) added support for .onion security indicators giving you a little onion icon instead/in addition to the padlock icon in the identity box.
3) added four new locales, da, he, sv-SE, and zh-TW to give users spekaing those languages an improved Tor Browser experience. The plan is to add even more locales once we are confident we can handle the additional load and disk space requirements.
4) replaced our old Torbutton icon with a shiny new one. That's the first step in redesigning our icons and making them compatible with Firefox's Photon UI. There is more to come in the next alphas.
5) are able to provide full content sandboxing support for 64bit Windows bundles thanks to the work done by Tom Ritter.
Additionally, we updated a number of components we ship: Tor to 0.3.4.2-alpha, Torbutton to 2.0.1, TorLauncher to 0.2.16.1, HTTPS-Everywhere to 2018.06.21, and NoScript to 10.1.8.2. Expect more bugs than usual in this alpha.
Which brings me to the known issues section. The most important ones are listed below:
1) We are still investigating why our generation of incremental update files are failing. We might not have fixed that in time for this release which means only the full update files might be available.[1]
2) Meek is currently broken. We need to update the browser part for make it compatible with ESR60.[2]
3) On Windows localized builds on first start the about:tor page is not shown, rather a weird XML error is visible.[3]
4) Maybe related to 3) NoScript does not seem to work properly on Windows builds right now.[4]
5) We are not done yet with reviewing the network code changes between ESR52 and ESR60. While I don't expect that proxy bypass bugs got introduced between those ESR series, I can't rule it out yet.[5]
6) We disable Stylo on macOS due to reproducibility issues we need to investigate and fix.[6]
If any of you will find more issues (and I hope you do) please report them at https://bugs.torproject.org. We track all Tor Browser 8 related issues with the ff60-esr keyword.
The full changelog since Tor Browser 8.0a8 is:
Tor Browser 8.0a9 -- June 27 2018 * All platforms * Update Firefox to 60.1.0esr * Update Tor to 0.3.4.2-alpha * Update Libevent to 2.1.8 * Update Binutils to 2.26.1 * Update Torbutton to 2.0.1 * Bug 26100: Adapt Torbutton to Firefox 60 ESR * Bug 26430: New Torbutton icon * Bug 24309: Move circuit display to the identity popup * Bug 26128: Adapt security slider to the WebExtensions version of NoScript * Bug 23247: Show security state of .onions * Bug 26129: Show our about:tor page on startup * Bug 26235: Hide new unusable items from help menu * Bug 26058: Remove workaround for hiding 'sign in to sync' button * Bug 20628: Add locales da, he, sv, and zh-TW * Translations update * Update Tor Launcher to 0.2.16.1 * Bug 25750: Update Tor Launcher to make it compatible with Firefox 60 ESR * Bug 20890: Increase control port connection timeout * Bug 20628: Add more locales to Tor Browser * Translations update * Update HTTPS Everywhere to 2018.6.13 * Update NoScript to 10.1.8.2 * Bug 25543: Rebase Tor Browser patches for ESR60 * Bug 23247: Show security state of .onions * Bug 26039: Load our preferences that modify extensions * Bug 17965: Isolate HPKP and HSTS to URL bar domain * Bug 26365: Add potential AltSvc support * Bug 26045: Add new MAR signing keys * Bug 22564: Hide Firefox Sync * Bug 25090: Disable updater telemetry * Bug 26127: Make sure Torbutton and Tor Launcher are not treated as legacy extensions * Bug 26073: Migrate general.useragent.locale to intl.locale.requested * Bug 20628: Make Tor Browser available in da, he, sv-SE, and zh-TW * Bug 12927: Include Hebrew translation into Tor Browser * Bug 21245: Add danish (da) translation * Windows * Bug 26239+24197: Enable content sandboxing for 64bit Windows builds * Bug 22581: Fix shutdown crash * Bug 26424: Disable UNC paths to prevent possible proxy bypasses * Bug 26304: Update zlib to version 1.2.11 * OS X * Bug 24052: Backport fix for bug 1412081 for better file:// handling * Bug 24136: After loading file:// URLs clicking on links is broken on OS X * Bug 24243: Tor Browser only renders HTML for local pages via file:// * Bug 24263: Tor Browser does not run extension scripts if loaded via about:debugging * Bug 24632: Disable snowflake for now until its build is fixed * Bug 26438: Remove broken seatbelt profiles * Linux * Bug 24052: Backport fix for bug 1412081 for better file:// handling * Bug 24136: After loading file:// URLs clicking on links is broken on Linux * Bug 24243: Tor Browser only renders HTML for local pages via file:// * Bug 24263: Tor Browser does not run extension scripts if loaded via about:debugging * Bug 26153: Update selfrando to be compatible with Firefox 60 ESR * Bug 22242: Remove RUNPATH in Linux binaries embedded by selfrando * Bug 26354: Set SSE2 support as minimal requirement for Tor Browser 8 * Build System * All * Bug 26362: Use old MAR format for first ESR60-based alpha * Clean up * Windows * Bug 26203: Adapt tor-browser-build/tor-browser for Windows * Bug 26204: Bundle d3dcompiler_47.dll for Tor Browser 8 * Bug 26205: Don't build the uninstaller for Windows during Firefox compilation * Bug 26206: Ship pthread related dll where needed * Bug 26396: Build libwinpthread reproducible * Bug 25837: Integrate fxc2 into our build setup for Windows builds * Bug 25894: Get a rust cross-compiler for Windows * Bug 25554: Bump mingw-w64 version for ESR 60 * Bug 23561: Fix nsis builds for Windows 64 * Bug 23231: Remove our STL Wrappers workaround for Windows 64bit * Bug 26370: Don't copy msvcr100.dll and libssp-0.dll twice * Bug 26476: Work around Tor Browser crashes due to fix for bug 1467041 * Bug 18287: Use SHA-2 signature for Tor Browser setup executables * OS X * Bug 24632: Update macOS toolchain for ESR 60 * Bug 9711: Build our own cctools for macOS cross-compilation * Bug 25548: Update macOS SDK for Tor Browser builds to 10.11 * Bug 26003: Clean up our mozconfig-osx-x86_64 file * Bug 26195: Use new cctools in our macosx-toolchain project * Bug 25975: Get a rust cross-compiler for macOS * Bug 26475: Disable Stylo to make macOS build reproducible * Linux * Bug 26073: Patch tor-browser-build for transition to ESR 60 * Bug 25540: Stop building and distributing sandboxed tor browser * Bug 25481: Rust support for tor-browser and tor
Georg
[1] https://trac.torproject.org/projects/tor/ticket/26472 [2] https://trac.torproject.org/projects/tor/ticket/26477 [3] https://trac.torproject.org/projects/tor/ticket/26381 [4] https://trac.torproject.org/projects/tor/ticket/26381#comment:5 [5] https://trac.torproject.org/projects/tor/ticket/22176 [6] https://trac.torproject.org/projects/tor/ticket/26475
_______________________________________________ tor-qa mailing list tor-qa@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-qa
Tom Ritter:
I tested torbrowser-install-win64-8.0a9_en-US.exe
Upon the browser opening, the initial screen has an orange 'Tor Browser' in the address bar with an icon of a firefox next to it.
The onion icon has a flashing triange icon.
The banner about checking out the security slider goes away after visiting the first page; the icon stays flashing.
When I click the icon and open the Security Settings dialog, the icon is still flashing.
That's expected as 8.0a9 is not a recommended version yet.
In the security settings dialog, clicking the labels directly works, but clicking in the grey space in between or nearby the labels does not. It would be nice if it did, so i didn't have to be so precise with my mouse.
Well, you can click anywhere on the slider to adjust the slider level, no need to click on the exact label. I am inclined to think that's enough and we don't need to cover the space between the labels.
After closing the security slider dialog, the icon is still flashing the exclamation triangle.
Yeah, no 8.0a9 yet.
I typed in ritter.vg in the address bar, get redirected to https://ritter.vg but there is not lock icon and the doorhanger off the (i) says 'This connection is not secure.
Interesting, this might be a Windows-only thing? Because it works for me on Linux.
The Tor circuit dialog looks great, clicking the new circuit button worked; however it still says it's not secure. In a new tab, typing in https://ritter.vg directly works. In another new tab typing ritter.vg now shows the lock (this is probably due to HSTS info and a before-navigation upgrade rather than a redirect.)
I typed in tomritterbassljd.onion/ (which redirects to SSL serving an expired-but-valid-EV-onion certificate) and got an intersitial saying my connection is not secure. The address bar shows the green lock+onion icon, but no EV indicator. Adding an exception and continuing works and the UI stays the same saying it's a secure connection.
That might be Richard's https://trac.torproject.org/projects/tor/ticket/26456.
The triangle exclamation is still flashing. I realize at this point it's probably the erroneous 'update available' message. I think we should change whatever needs to be changed so that alpha/newer versions don't report they have an 'update' available.
No, it's not saying you have an update available but rather that the version you are using is not recommended (yet). I think the respective text on about:tor might be misleading, though. I am fine modifying the text as needed but why should we not warn users once they run an unrecommended Tor Browser version? What we could do to avoid this problem is maybe for the alpha approving the upcoming release earlier?
I go to youtube and watch a video. I try New Identity.
I notice there is a 'New Window' and a 'New Private Window' menu buttons in the hamburger that do the same thing.
Yes. What would you suggest we do? Hide the first one in case we are in permanent Private Browsing Mode? Georg
On 27 June 2018 at 12:57, Georg Koppen <gk@torproject.org> wrote:
The triangle exclamation is still flashing. I realize at this point it's probably the erroneous 'update available' message. I think we should change whatever needs to be changed so that alpha/newer versions don't report they have an 'update' available.
No, it's not saying you have an update available but rather that the version you are using is not recommended (yet). I think the respective text on about:tor might be misleading, though. I am fine modifying the text as needed but why should we not warn users once they run an unrecommended Tor Browser version? What we could do to avoid this problem is maybe for the alpha approving the upcoming release earlier?
Hrm. So flashing because it's not a recommended release makes sense... I guess my attitude towards Alphas and Nightlies (especially if Alpha has it's own Update Channel) is to make Alpha Tor Browser visually and runtime distinct (different icon, process name, profile dir, etc) from the release channel of TB; like other browsers do. Then you can tell people who aren't on the latest Alpha that their version is incorrect; but the latest Alpha will be correct.
I go to youtube and watch a video. I try New Identity.
I notice there is a 'New Window' and a 'New Private Window' menu buttons in the hamburger that do the same thing.
Yes. What would you suggest we do? Hide the first one in case we are in permanent Private Browsing Mode?
Yea, hide one of them. Arthur mentioned a patch he was working on included hiding one. -tom
Tom Ritter:
On 27 June 2018 at 12:57, Georg Koppen <gk@torproject.org> wrote:
The triangle exclamation is still flashing. I realize at this point it's probably the erroneous 'update available' message. I think we should change whatever needs to be changed so that alpha/newer versions don't report they have an 'update' available.
No, it's not saying you have an update available but rather that the version you are using is not recommended (yet). I think the respective text on about:tor might be misleading, though. I am fine modifying the text as needed but why should we not warn users once they run an unrecommended Tor Browser version? What we could do to avoid this problem is maybe for the alpha approving the upcoming release earlier?
Hrm. So flashing because it's not a recommended release makes sense...
I guess my attitude towards Alphas and Nightlies (especially if Alpha has it's own Update Channel) is to make Alpha Tor Browser visually and runtime distinct (different icon, process name, profile dir, etc) from the release channel of TB; like other browsers do. Then you can tell people who aren't on the latest Alpha that their version is incorrect; but the latest Alpha will be correct.
We are telling users who are using the latest alpha that their alpha is correct. But, yes, I agree with the other suggestion. That's #25023. Georg
participants (2)
-
Georg Koppen -
Tom Ritter