Tails

#3 Updated by intrigeri 2019-02-08 18:03:35

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.

#6 Updated by intrigeri 2019-02-11 16:04:15

@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 2019-02-25 13:10:44

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

#11 Updated by intrigeri 2019-03-11 17:09:45

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 2019-03-11 17:15:57

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 2019-03-11 18:59:46

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).

#15 Updated by intrigeri 2019-03-17 15:46:40

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

#16 Updated by intrigeri 2019-03-18 09:42:50

intrigeri wrote:
> Next step: upgrade to 8.5a9

Done, let’s see what Jenkins thinks.

#17 Updated by intrigeri 2019-03-18 12:15:58

> 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 2019-03-18 17:35:26

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.

#22 Updated by intrigeri 2019-04-08 17:46:40

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 2019-04-08 18:02:24

GeKo plans to start building 8.5a11 on Thursday.

#26 Updated by segfault 2019-04-27 19:12:03

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.

#27 Updated by segfault 2019-04-28 15:06:54

The Tor Browser related tests passed on Jenkins: https://jenkins.tails.boum.org/job/test_Tails_ISO_feature-16337-tor-browser-8.5-force-all-tests/lastCompletedBuild/cucumberTestReport/

#28 Updated by intrigeri 2019-04-29 18:26:26

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.

#30 Updated by intrigeri 2019-05-03 17:16:24

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 2019-05-04 11:08:42

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 2019-05-04 16:03:49

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 2019-05-04 17:23:45

> 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:

• https://gitweb.torproject.org/builders/tor-browser-build.git/log/?h=maint-8.5
• https://gitweb.torproject.org/tor-browser.git/

(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 2019-05-06 14:11:47

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

#35 Updated by segfault 2019-05-06 14:14:15

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.

#39 Updated by segfault 2019-05-07 10:23:02

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 2019-05-08 07:44:55

> 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 2019-05-10 16:24:30

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 2019-05-16 15:51:46

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

#43 Updated by CyrilBrulebois 2019-05-17 12:58:01

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

#44 Updated by intrigeri 2019-05-17 13:57:01

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.

#52 Updated by intrigeri 2019-05-17 16:15:19

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 2019-05-17 17:55:00

> 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 2019-05-17 17:59:21

> 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 2019-05-18 06:58:11

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 2019-05-18 06:59:26

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 2019-05-18 07:17:51

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 2019-05-18 11:29:37

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 2019-05-18 11:33:03

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

#60 Updated by intrigeri 2019-05-18 11:57:26

> 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 2019-05-18 12:06:46

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).

#65 Updated by intrigeri 2019-05-18 12:53:35

@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!