Feature #16337

Upgrade to Tor Browser 8.5

Added by anonym about 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Target version:
Start date:
2019-03-15
Due date:
% Done:

100%

Feature Branch:
feature/16337-tor-browser-8.5+force-all-tests
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Browser
Deliverable for:

Description

The Tor Browser roadmap has useful bits about this: https://pad.riseup.net/p/tbb-roadmap-2018-19


Subtasks

Feature #16561: Upgrade doc to Tor Browser 8.5 Resolved

0


Related issues

Related to Tails - Feature #15807: Define & apply clear criteria for including dictionaries, fonts and language packs Resolved 2018-08-18
Related to Tails - Bug #16706: NoScript gets disabled after a while Resolved
Related to Tails - Bug #16727: Update doc to Tor Browser 8.5, take 2 Resolved
Has duplicate Tails - Bug #16690: Upgrade to Tor Browser based on Firefox 60.7 Duplicate
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by anonym about 6 years ago

  • Status changed from Confirmed to In Progress
  • Assignee set to anonym
  • Feature Branch set to feature/16337-tor-browser-8.5+force-all-tests

Initial testing looks great, no problems found at all actually. But the upstream changes for Bug #15709 and Bug #16048 has not landed upstream yet, and they definitely will require some work on our side.

#2 Updated by anonym about 6 years ago

#3 Updated by intrigeri about 6 years ago

8.5a7 is available but I don’t think it has any of the big changes yet. See subtasks for the ongoing communication with upstream, which is basically the only thing we can do at the moment.

#4 Updated by intrigeri about 6 years ago

  • Target version changed from Tails_3.13 to Tails_3.14

See email from geko on tails-dev.

#5 Updated by intrigeri about 6 years ago

  • Due date set to 2019-03-17
  • Target version changed from Tails_3.14 to Tails_3.13
  • Start date deleted (2018-07-03)

After some more discussion with Georg, it appears that the big changes that were initially meant to land in TB 8.5, and that we expected would require substantial amounts of work on our side, are all postponed to TB 9.0. I’ve updated all our corresponding tickets accordingly. So there’s a good chance that the upgrade to 8.5 does not require too much work on our side :) Now, it postpones big chunks of work to August-September (latest), which is not ideal as we’ll have to deal with Firefox 68 and Buster too, but we’ll cope.

And regarding the timing of this work, the conclusion is that we don’t know yet when we’ll need to ship Tor Browser 8.5:

  • Worst case, we might have to do that at any unscheduled time between the last week of March (Pwn2Own) and mid-May (scheduled 3.14 release) if there’s an emergency release and 8.5 is ready for prime time.
  • Best case, we have to do that in Tails 3.14.

So I think we should:

  • Keep the branch up-to-date with the latest Tor Browser 8.5 pre-releases.
  • Keep an eye on test suite results.
  • At some point, I would say by mid-March, “run” the parts of the manual test suite that are affected by this upgrade.

… and then we should be ready to switch to 8.5 at any time dictated by external circumstances.

anonym, segfault: does this make sense to you? Can you handle this by yourselves or will you need help from other FT people?

#6 Updated by intrigeri about 6 years ago

@anonym, I’m working on Bug #16177 and I’m curious about what exact problem commit:aca28cec16287befd7dbadbfee7834c153936b04 solved for you. If that was about mksquashfs getting killed:

  • gzip compression or xz?
  • Building in RAM or not?
  • Please try to revert this commit and retry with bugfix/16177-limit-mksquashfs-memory-usage merged into your branch.

If that’s really about “disk” space, then fine, forget this.

#7 Updated by anonym about 6 years ago

Note to self: I already replied to the above comment on the relevant ticket.

I’ve updated to 8.5a8 and booted an image and done some rudimentary testing. The only change I’ve noticed is the new Tor Browser icon (but we don’t even use it in our test suite!) which agrees with my reading of the changelogs. Tor Browser 8.5.x seems like it will be an easy bump for us.

Let’s see what Jenkins thinks: https://jenkins.tails.boum.org/job/test_Tails_ISO_feature-16337-tor-browser-8.5-force-all-tests/7

#8 Updated by anonym about 6 years ago

  • % Done changed from 0 to 20

Jenkins likes 8.5a8!

(The only browser related failure is the “Watching a WebM video over HTTPS” scenario, but it is fragile and is failing on other +force-all-tests branches too.)

#9 Updated by intrigeri about 6 years ago

  • Assignee changed from anonym to intrigeri

#10 Updated by intrigeri about 6 years ago

  • related to Feature #15807: Define & apply clear criteria for including dictionaries, fonts and language packs added

#11 Updated by intrigeri about 6 years ago

There’s nothing newer than 8.5a8 tagged in Git at the moment and the master branch of builders/tor-browser-build.git has almost only Android-related changes since tbb-8.5a8-build2.

The output of git diff tbb-8.0.6-build1.. -- projects/firefox/abicheck.cc projects/firefox/start-firefox projects/tor-browser/RelativeLink/start-tor-browser is empty.

Reverted the installation of additional dictionaries: commit:353dd4d3ae6aa5defb821ba2b537df999d648087 explains why.

Tested “Watching a WebM video over HTTPS” manually, works fine.

Next step (perhaps after 8.5a9 or beta or RC something is out?): “run” our manual test suite on an image built from this branch. Our automated tests coverage is rather low for Tor Browser and we’ve often found issues only via manual testing.

#12 Updated by intrigeri about 6 years ago

intrigeri wrote:
> Next step (perhaps after 8.5a9 or beta or RC something is out?): “run” our manual test suite on an image built from this branch. Our automated tests coverage is rather low for Tor Browser and we’ve often found issues only via manual testing.

Actually this must happen sooner rather than later due to the risk Pwn2Own decides when Tor Browser 8.5 is released as stable (Feature #16337#note-5).

@sajolida: note that the Tor Browser icon is brand new in this release, so we’ll probably need some doc update; I’m told the security slider is getting a redesign but I didn’t check if this got merged yet nor whether it affects our doc. Our tech writers can start this work right now if you want, using https://nightly.tails.boum.org/build_Tails_ISO_feature-16337-tor-browser-8.5-force-all-tests/lastSuccessful/archive/build-artifacts/. Feel free to push doc updates directly to the topic branch for this ticket. Ideally this would be ready by March 23, in case we have to ship this in the last week of March due to Pwn2Own.

#13 Updated by intrigeri about 6 years ago

Update after attending the Tor Browser weekly meeting: the post-Pwn2Own release won’t be 8.5. There’ll be some other 8.5 alphas, perhaps a last one near the end of March, and then ~1 week before the release. So we “only” need all this ready, to be on the safe side, by the end of March, so that we are ready to ship Tor Browser 8.5 in Tails 3.14 (best case) or 3.13.x (worst case; could happen that we need this any time between end of March and 3.14).

#14 Updated by intrigeri about 6 years ago

  • Due date changed from 2019-03-17 to 2019-03-31
  • Priority changed from Elevated to High
  • Target version changed from Tails_3.13 to Tails_3.14

#15 Updated by intrigeri about 6 years ago

Next step: upgrade to 8.5a9 and “run” our manual test suite on an image built from this branch.

#16 Updated by intrigeri about 6 years ago

intrigeri wrote:
> Next step: upgrade to 8.5a9

Done, let’s see what Jenkins thinks.

#17 Updated by intrigeri about 6 years ago

> upgrade to 8.5a9 and “run” our manual test suite on an image built from this branch.

Done, manual test suite passes.

#18 Updated by intrigeri about 6 years ago

intrigeri wrote:
> intrigeri wrote:
> > Next step: upgrade to 8.5a9
>
> Done, let’s see what Jenkins thinks.

Passes the full test suite (except a few fragile tests that are unrelated to Tor Browser) locally.

So I think we’re as ready as we can be at this point. Let’s wait for the next upstream alpha/beta/RC.

#19 Updated by intrigeri about 6 years ago

#20 Updated by intrigeri about 6 years ago

  • blocked by deleted (Feature #15507: Core work 2019Q1: Foundations Team)

#21 Updated by intrigeri about 6 years ago

  • Assignee changed from intrigeri to anonym

#22 Updated by intrigeri about 6 years ago

GeKo says:

  • “8.5a10 should have all the desktop things modulo a fixup for ”$“:https://bugs.torproject.org/25658”
  • “one thing i heard on the comments were folks complaining about the removed noscript button; because if they want to customize their scripts etc. they now need to put the noscript button back to the toolbar first, every time”

#23 Updated by intrigeri about 6 years ago

GeKo plans to start building 8.5a11 on Thursday.

#24 Updated by intrigeri about 6 years ago

  • Priority changed from Normal to Elevated

#25 Updated by segfault about 6 years ago

  • Assignee changed from anonym to segfault

#26 Updated by segfault about 6 years ago

I upgraded Tor Browser to 8.5a11 according to the documentation (https://tails.boum.org/contribute/release_process/tor-browser) and made sure that it builds.

#28 Updated by intrigeri about 6 years ago

I’ve lurked at the Tor Browser team meeting today and they’re currently aiming at building 8.5 final on May 2. If that doesn’t work, the alternative is to build it for the May 14 scheduled release.

#29 Updated by intrigeri about 6 years ago

  • blocks Bug #16690: Upgrade to Tor Browser based on Firefox 60.7 added

#30 Updated by intrigeri about 6 years ago

anonym, segfault, can one of you — i.e. those of us with most experience wrt. Tails integration of Tor Browser — be around on May 13-14, to help fix any critical regression that could be spotted at the last minute during the 3.14 release process? I won’t be available.

I really don’t think any such thing will happen (we should “run” the manual test suite before merging the Tor Browser 8.5 branch) but it would be more relaxing to know that the RM won’t be left alone to deal with any such critical issue in an area of Tails he’s not super familiar with.

I’m insisting on “critical”: there are plenty of regressions that are acceptable, or in any case less critical than the security fixes the Tor Browser update will bring.

#31 Updated by segfault about 6 years ago

intrigeri wrote:
> anonym, segfault, can one of you — i.e. those of us with most experience wrt. Tails integration of Tor Browser — be around on May 13-14, to help fix any critical regression that could be spotted at the last minute during the 3.14 release process? I won’t be available.

Yes, I can be on call to help with that.

#32 Updated by segfault about 6 years ago

intrigeri wrote:
> I’ve lurked at the Tor Browser team meeting today and they’re currently aiming at building 8.5 final on May 2. If that doesn’t work, the alternative is to build it for the May 14 scheduled release.

I can’t find a 8.5 final tarball on any of the sites linked on https://tails.boum.org/contribute/release_process/tor-browser/#index2h1, so I guess they didn’t build it yet.

#33 Updated by intrigeri about 6 years ago

> I can’t find a 8.5 final tarball on any of the sites linked on https://tails.boum.org/contribute/release_process/tor-browser/#index2h1, so I guess they didn’t build it yet.

Indeed.

Another way to track progress is to look for tags in these two repos:

(There’s no tag for final 8.5 yet.)

Also, talking with upstream on IRC tends to yield more up-to-date info/plans :)

#34 Updated by intrigeri about 6 years ago

segfault will import a12, run +force-all-tests, and “run” the browser bits of the manual test suite on it.

#35 Updated by segfault about 6 years ago

Next step: Upgrade to 8.5a12-build2 (https://people.torproject.org/~boklm/builds/8.5a12-build2), run +force-all-tests, manually test browser bits of the manual test suite, check that Bug #16706 is fixed.

#36 Updated by intrigeri about 6 years ago

  • Target version changed from Tails_3.14 to Tails_3.15

8.5 will only be released after next week’s release. Still, IMO it’s worth doing the QA mentioned above, so we’re ready for the worst case (emergency release that has to include 8.5).

#37 Updated by intrigeri about 6 years ago

  • blocked by deleted (Bug #16690: Upgrade to Tor Browser based on Firefox 60.7)

#38 Updated by intrigeri about 6 years ago

  • blocks Bug #16691: Upgrade to Tor Browser based on Firefox 60.8 added

#39 Updated by segfault about 6 years ago

intrigeri wrote:
> 8.5 will only be released after next week’s release.

Which version will we ship in 3.14 then?

#40 Updated by intrigeri about 6 years ago

> Which version will we ship in 3.14 then?

I guess 8.0.10 (Bug #16690). I’ve just updated contribute/calendar accordingly.

#41 Updated by segfault about 6 years ago

segfault wrote:
> Next step: Upgrade to 8.5a12-build2 (https://people.torproject.org/~boklm/builds/8.5a12-build2)

I upgraded to 8.5a12 (https://people.torproject.org/~gk/builds/8.5a12/)

> run +force-all-tests

Running

> manually test browser bits of the manual test suite

Will do that now

> check that Bug #16706 is fixed.

It’s fixed, but the NoScript button is not shown in the toolbar anymore.

#42 Updated by segfault about 6 years ago

8.5~build2 (https://people.torproject.org/~boklm/builds/8.5-build2/) is ready, upgrading now

#43 Updated by CyrilBrulebois about 6 years ago

FWIW, there’s even a 8.5-build3 now → https://people.torproject.org/~boklm/builds/8.5-build3/

#44 Updated by intrigeri about 6 years ago

8.5 final is ready for testing. I’ve asked GeKo if that’ll be the one released on Tuesday or if there’ll be another 8.0.x.

#45 Updated by intrigeri about 6 years ago

  • Assignee changed from segfault to intrigeri
  • Priority changed from Elevated to High
  • Target version changed from Tails_3.15 to Tails_3.14

Given the doubts expressed above and the fact segfault is not available today, I’ll assume the “worst” case i.e. we have to ship 8.5 in Tails 3.14, will import 8.5 final, trigger CI jobs, so segfault and I have more data in hand tomorrow.

#46 Updated by intrigeri about 6 years ago

  • QA Check set to Ready for QA

Gah, I misread stuff. 8.5-build2, that segfault imported already, is good enough for us. build3 only fixes stuff for Android. So if our CI is happy with 8.5-build2, we could merge that and ship it in Tails 3.14.

I’ll run the relevant bits of our manual + automated test suites on an ISO built from the topic branch and will merge if happy.

#47 Updated by intrigeri about 6 years ago

  • has duplicate Bug #16690: Upgrade to Tor Browser based on Firefox 60.7 added

#48 Updated by intrigeri about 6 years ago

  • related to Bug #16706: NoScript gets disabled after a while added

#49 Updated by intrigeri about 6 years ago

  • blocked by deleted (Bug #16691: Upgrade to Tor Browser based on Firefox 60.8)

#50 Updated by segfault about 6 years ago

  • Assignee changed from intrigeri to segfault
  • Priority changed from High to Elevated
  • Target version changed from Tails_3.14 to Tails_3.15
  • QA Check deleted (Ready for QA)

Manual tests pass for 8.5-build2

#51 Updated by intrigeri about 6 years ago

  • Priority changed from Elevated to High
  • Target version changed from Tails_3.15 to Tails_3.14
  • QA Check set to Ready for QA

(Reverting change that was probably unintentional, except assignee since segfault says the WebGL fingerprint differs from another system.)

#52 Updated by intrigeri about 6 years ago

Relevant automated tests pass locally (fragile tests included): features/unsafe_browser.feature features/torified_browsing.feature features/tor_stream_isolation.feature features/tor_enforcement.feature features/pidgin.feature features/localization.feature features/documentation.feature.

So I think we can merge once the WebGL thing is clarified!

#53 Updated by segfault about 6 years ago

> segfault says the WebGL fingerprint differs from another system

I asked about that in #tor-dev:

> segfault: While testing Tor Browser 8.5-build2 in Tails, we noticed that the WebGL fingerprint shown by Panopticlick differs between Tor Browser in Tails and another system we tested it in (Debian Sid). Is this expected? In Tor Browser 8.0.9 there was no WebGL fingerprint (all 0 in Panopticlick).
>
> GeKo: hm, the only thing we did was putting webgl as click-to-play on the safer level instead of starting already so by default
> do you see the same if you allow webgl in 8.0.9?
> GeKo: another intersting test would be to see what happens with a vanilla tor browser in tails compared to the other system

I tried to run vanilla Tor Browser 8.5-build2 in Tails, but it doesn’t start (because it tries to start its own tor instance I think).

My WebGL fingerprint in the image built from the feature branch is f9a0f737691a9b57f5294121fc58a2df. It stays the same when I restart Tor Browser / trigger New Identity.

#54 Updated by segfault about 6 years ago

> GeKo: hm, i am not sure whether that’s actually easy to test, see https://bugs.torproject.org/27290
> see the commit message for the torbutton patch; it should contain instructions on what to do
> commit 7d98f3bd4348aa79efe040118763c77c84745173 in git.torproject.org/torbutton

#55 Updated by intrigeri about 6 years ago

On Jenkins, over the last 3 runs, all relevant tests passed at least once. Only one failed once. So from a CI PoV we’re good here!

#56 Updated by intrigeri about 6 years ago

I forgot: the branch does not build reproducibly on Jenkins but stable doesn’t either (likely due to outdated PO files since some VeraCrypt-related branch was merged, I’ve pushed a tentative fix). I’ll merge stuff and update PO files as needed to fix that and will ensure we don’t merge something that breaks reproducibility.

#57 Updated by intrigeri about 6 years ago

With 8.5-build2 outside of Tails (Debian sid) “Hash of WebGL fingerprint” is 2ef68bcd75e09a41aea04bae556f3ecc. Same in an ISO built from this branch, started in a libvirt/QEMU VM with virtio + virgl 3D acceleration enabled, i.e. basically rendering is offloaded to the host’s GPU, which may explain why I see the same fingerprint in both tests. Note that it’s a different fingerprint than the one you see in Tails.

What fingerprint do you see for 8.5-build2 outside of Tails?

In any case, this sounds like some hardware capabilities are exposed to the browser and could be used to fingerprint users more easily. I guess that’s a direct, expected consequence of Torbutton now setting webgl.min_capability_mode to false at the standard security level.

The course of action I suggest is: first, check if the fingerprints we see outside of Tails differ. If they do, then it’s an upstream issue => make sure upstream is aware of it and it’s intended. If they don’t differ outside of Tails, since they do differ inside of Tails, then we have a Tails-specific problem.

#58 Updated by segfault about 6 years ago

intrigeri wrote:
> With 8.5-build2 outside of Tails (Debian sid) “Hash of WebGL fingerprint” is 2ef68bcd75e09a41aea04bae556f3ecc. Same in an ISO built from this branch, started in a libvirt/QEMU VM with virtio + virgl 3D acceleration enabled, i.e. basically rendering is offloaded to the host’s GPU, which may explain why I see the same fingerprint in both tests. Note that it’s a different fingerprint than the one you see in Tails.

I booted an ISO built from this branch (commit bd9331292c) in a libvirt/QEMU VM with Virtio 3d acceleration enabled, but with SPICE OpenGL support disabled, which I suspect means that my host GPU isn’t actually used for rendering. Maybe the latter is different from your setup?

> What fingerprint do you see for 8.5-build2 outside of Tails?

The same as you, 2ef68bcd75e09a41aea04bae556f3ecc.

#59 Updated by segfault about 6 years ago

When I boot the ISO with the OpenGL setting enabled, I also get a WebGL fingerprint hash of 2ef68bcd75e09a41aea04bae556f3ecc.

#60 Updated by intrigeri about 6 years ago

> When I boot the ISO with the OpenGL setting enabled, I also get a WebGL fingerprint hash of 2ef68bcd75e09a41aea04bae556f3ecc.

So, to sum up (and adding another test result of mine):

  • inside Tails built from this branch (in VMs):
    • both intrigeri and segfault, with OpenGL enabled: 2ef68bcd75e09a41aea04bae556f3ecc
    • both intrigeri and segfault, with OpenGL disabled: f9a0f737691a9b57f5294121fc58a2df
  • outside of Tails: both intrigeri and segfault get 2ef68bcd75e09a41aea04bae556f3ecc

tl;dr: we see only 2 different fingerprints, one for system with hardware OpenGL support, and the other one for systems without it. This sounds reasonable. I’ll mention it to GeKo right away but IMO we should not block on it.

Merge?

(There’s a new subtask about follow-up doc updates but this should not block the merge IMO.)

#61 Updated by segfault about 6 years ago

I looked at the JS code used by panopticlick to calculate this hash, and printed the values which go into the hash. The only difference I could find is that antialiasing is enabled iff OpenGL is enabled. (That’s exposed via the antialias bool of gl.getContextAttributes(), see https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/getContextAttributes).

#62 Updated by segfault about 6 years ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

Applied in changeset commit:tails|e48c12e8375659ade6a11d3c38a811450bec3e1e.

#63 Updated by intrigeri about 6 years ago

  • related to Bug #16727: Update doc to Tor Browser 8.5, take 2 added

#64 Updated by intrigeri about 6 years ago

  • Assignee deleted (segfault)
  • QA Check changed from Ready for QA to Pass

#65 Updated by intrigeri about 6 years ago

@segfault, after discussing the WebGL thing a bit with GeKo, I’ve reported your findings on https://trac.torproject.org/projects/tor/ticket/30531. Thanks!

#66 Updated by intrigeri about 6 years ago

  • Status changed from Fix committed to In Progress
  • Assignee set to intrigeri

Oops, I forgot to import Tor Browser 8.5 into our own archive.

#67 Updated by intrigeri about 6 years ago

  • Status changed from In Progress to Fix committed

This time we should be good to go.

#68 Updated by intrigeri about 6 years ago

  • Assignee deleted (intrigeri)

#69 Updated by CyrilBrulebois about 6 years ago

  • Status changed from Fix committed to Resolved