Tails

#11 Updated by intrigeri 2018-05-22 16:29:36

FTR a first TB Linux nightly based on ESR 60 is planned for this week :)

#12 Updated by intrigeri 2018-05-24 10:39:45

… and the 60.2 release date has changed again. It’s now later than planned initially which will make things easier for us! :)

#14 Updated by intrigeri 2018-06-25 11:36:59

The first TB alpha based on ESR60 is there: https://lists.torproject.org/pipermail/tor-qa/2018-June/000942.html :)

#19 Updated by intrigeri 2018-06-30 21:48:24

Got an ISO that builds! First issues identified via random manual testing:

• missing icon in the apps menu
• “Something Went Wrong! Tor is not working in this browser”, fixed by allowing GETINFO net/listeners/socks in onion grater
• no circuits display in the onion menu
• ublock is not enabled, possibly the way we patch stuff in apply_extension_code_signing_hacks is broken
• default search engine is YouTube, maybe that’s what people want these days but I’d rather stick to DDG like Tor Browser upstream
• a few AppArmor denials that might explain some of the above
• in about:addons → Languages, all language packs are flagged as “could not be verified”. I guess we’ll have to live with it.
• our custom homepage is not loaded: about:tor is
• ERROR: ld.so: object 'libmozsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. (after patching the AppArmor profile to allow reading /etc/ld.so.conf,{.d,.d/*}; looks like we need to teach Tor Browser where its libraries live; next step: look at changes in the start-tor-browser script that we should import

#20 Updated by intrigeri 2018-07-01 12:41:23

intrigeri wrote:
> * missing icon in the apps menu

Fixed in Git.

> * “Something Went Wrong! Tor is not working in this browser”, fixed by allowing GETINFO net/listeners/socks in onion grater

Fixed in Git.

> * no circuits display in the onion menu

Actually, that’s because this has been moved to the identity box in the URL bar domain and there it works fine.

> * ublock is not enabled, possibly the way we patch stuff in apply_extension_code_signing_hacks is broken

Later.

> * default search engine is YouTube, maybe that’s what people want these days but I’d rather stick to DDG like Tor Browser upstream
> * our custom homepage is not loaded: about:tor is

It looks like /etc/tor-browser/locale-profiles/ is not considered anymore, which explains these 2 issues.

> * ERROR: ld.so: object 'libmozsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. (after patching the AppArmor profile to allow reading /etc/ld.so.conf,{.d,.d/*}; looks like we need to teach Tor Browser where its libraries live; next step: look at changes in the start-tor-browser script that we should import

Later. Next step: reproduce with pristine Tor Browser 8.0aN outside of Tails.

#21 Updated by intrigeri 2018-07-01 13:15:02

intrigeri wrote:
> > * ublock is not enabled, possibly the way we patch stuff in apply_extension_code_signing_hacks is broken
>
> Later.

> > * default search engine is YouTube, maybe that’s what people want these days but I’d rather stick to DDG like Tor Browser upstream
> > * our custom homepage is not loaded: about:tor is
>
> It looks like /etc/tor-browser/locale-profiles/ is not considered anymore, which explains these 2 issues.

Fixed in Git.

> > * ERROR: ld.so: object 'libmozsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. (after patching the AppArmor profile to allow reading /etc/ld.so.conf,{.d,.d/*}; looks like we need to teach Tor Browser where its libraries live; next step: look at changes in the start-tor-browser script that we should import
>
> Later. Next step: reproduce with pristine Tor Browser 8.0aN outside of Tails.

Also, localized search engines, that we install in /usr/local/lib/tor-browser/distribution/searchplugins/locale/, are not taken into account. So for non-English languages the default search engine remains YouTube. Note that pristine Firefox already ships localized Wikipedia search engines (browser/locales/searchplugins/) and has a per-locale list (browser/locales/search/list.json), that Tor Browser patches to remove localized search engines. This makes sense to me in terms of not leaking the user’s locales unless they explicitly choose to do so. Given this area has been a recurring PITA to maintain accross major upgrades, I’m very tempted to just drop the ball and stick to Tor Browser’s defaults.

#23 Updated by intrigeri 2018-07-01 14:34:45

intrigeri wrote:
> intrigeri wrote:
> > > * ublock is not enabled, possibly the way we patch stuff in apply_extension_code_signing_hacks is broken
> >
> > Later.

Should be fixed in Git (locally, will push after testing).

> > > * ERROR: ld.so: object 'libmozsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. (after patching the AppArmor profile to allow reading /etc/ld.so.conf,{.d,.d/*}; looks like we need to teach Tor Browser where its libraries live; next step: look at changes in the start-tor-browser script that we should import
> >
> > Later. Next step: reproduce with pristine Tor Browser 8.0aN outside of Tails.

Unchanged.

> Also, localized search engines, that we install in /usr/local/lib/tor-browser/distribution/searchplugins/locale/, are not taken into account. So for non-English languages the default search engine remains YouTube. Note that pristine Firefox already ships localized Wikipedia search engines (browser/locales/searchplugins/) and has a per-locale list (browser/locales/search/list.json), that Tor Browser patches to remove localized search engines. This makes sense to me in terms of not leaking the user’s locales unless they explicitly choose to do so. Given this area has been a recurring PITA to maintain accross major upgrades, I’m very tempted to just drop the ball and stick to Tor Browser’s defaults.

Done.

Also, the Unsafe Browser window is entirely black.

#24 Updated by intrigeri 2018-07-01 15:15:06

intrigeri wrote:
> > > > * ERROR: ld.so: object 'libmozsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. (after patching the AppArmor profile to allow reading /etc/ld.so.conf,{.d,.d/*}; looks like we need to teach Tor Browser where its libraries live; next step: look at changes in the start-tor-browser script that we should import
> > >
> > > Later. Next step: reproduce with pristine Tor Browser 8.0aN outside of Tails.
>
> Unchanged.

> Also, the Unsafe Browser window is entirely black.

Fixed locally in Git but it lacks some of our customization:

• it’s listed as “Tor Browser” in the taskbar and in the window title
• it has search engines (I thought we disabled them, got to check that)
• it has the default Firefox bookmarks (not sure what we have usually, maybe not a problem)

And we need to check that our prefs are taken into account, both for the Unsafe Browser and for Tor Browser:

• config/chroot_local-includes/etc/tor-browser/profile/preferences/0000tails.js, e.g. extensions.torbutton.lastUpdateCheck seems to be ignored
• config/chroot_local-includes/etc/xul-ext/tor-launcher.js
• all calls to set_mozilla_pref
  • destination file (some are now ignored)
  • adding the user_pref optional argument may be needed in some cases

#25 Updated by intrigeri 2018-07-01 18:35:34

intrigeri wrote:
> intrigeri wrote:
> > > > > * ERROR: ld.so: object 'libmozsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. (after patching the AppArmor profile to allow reading /etc/ld.so.conf,{.d,.d/*}; looks like we need to teach Tor Browser where its libraries live; next step: look at changes in the start-tor-browser script that we should import
> > > >
> > > > Later. Next step: reproduce with pristine Tor Browser 8.0aN outside of Tails.
> >
Unchanged.
>
> > Also, the Unsafe Browser window is entirely black.
>
> Fixed locally in Git but it lacks some of our customization:
>
> * it’s listed as “Tor Browser” in the taskbar and in the window title
> * it has search engines (I thought we disabled them, got to check that)
> * it has the default Firefox bookmarks (not sure what we have usually, maybe not a problem)
>
> And we need to check that our prefs are taken into account, both for the Unsafe Browser and for Tor Browser:

I think I’ve fixed it all in Git, but it would be good to double-check.

#34 Updated by intrigeri 2018-07-10 16:00:53

intrigeri wrote:
> * sandboxing improvements require unprivileged user namespaces to be enabled + some AppArmor tweaks: is the risk/benefit worth it? this does not have to be solved as part of this ticket but it’s something to keep in mind and if not dealt with here, a follow-up ticket shall be created

Starting the discussion on Bug #15725.

#38 Updated by segfault 2018-07-30 21:07:45

I reviewed up to b959708bebf61e502c3f7bb6720ce41a921bf5c1 today.

My comments so far:

b55fff9f89c623b707d8c2a4e0fe893702d31785:

• inconsistent indentation in apply_extension_prefs_hacks
• I would put tbb_timestamp in a global variable instead of assigning it the same value in multiple functions

8b7dbd13d58c6e89cc9d3b5f69a9153347ea1ad6:

• Are you sure it is safe to edit to prefs.js directly? Maybe we should set our default settings in a all-tails.js file instead. Quoting from https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences:
  > prefs.js is automatically generated by the application and should not be edited manually

> Do NOT edit prefs.js directly.

> The administrator may add an all-companyname.js preference file (install_directory/browser/defaults/preferences/all-companyname.js). This will be parsed last during the preference loading process.

• configure_xulrunner_app_locale() is writing pref(...) to prefs.js - should that be user_pref(...)? (based on that prefs.js seems to only contain user_pref lines and you changed other lines to use user_pref in the same commit)

b959708bebf61e502c3f7bb6720ce41a921bf5c1:

• webext-ublock-origin is back in buster since 2018-07-17 - should we install it from buster instead of sid?

#39 Updated by intrigeri 2018-08-08 08:10:09

Hi segfault!

> I reviewed up to b959708bebf61e502c3f7bb6720ce41a921bf5c1 today.

Thanks a lot!

> My comments so far:

> b55fff9f89c623b707d8c2a4e0fe893702d31785:

> * inconsistent indentation in apply_extension_prefs_hacks

Right. Thankfully this code was removed later.

> * I would put tbb_timestamp in a global variable instead of assigning it the same value in multiple functions

Good idea, done locally and I’ll now test it :)

> 8b7dbd13d58c6e89cc9d3b5f69a9153347ea1ad6:

> * Are you sure it is safe to edit to prefs.js directly?

Yes, as long as we do this before the browser is started. I’m basically following the lead of the Tor Browser build scripts do.

> Maybe we should set our
> default settings in a all-tails.js file instead. Quoting from
> https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences:
>> prefs.js is automatically generated by the application and should not be edited manually

>> Do NOT edit prefs.js directly.

I think that’s meant for users. We do lots of things that Mozilla would not want end-users to do :)

>> The administrator may add an all-companyname.js preference file
>> (install_directory/browser/defaults/preferences/all-companyname.js). This will be
>> parsed last during the preference loading process.

This mechanism is meant for administrators who are able to modify the installed Tor Browser directory. This code is run as the amnesia user so we can’t use this.

> * configure_xulrunner_app_locale() is writing pref(...) to prefs.js - should
> that be user_pref(...)? (based on that prefs.js seems to only contain user_pref
> lines and you changed other lines to use user_pref in the same commit)

Right. This was fixed in commit:ac81013029d4e617dc6263edf65e903d07a5462b already.

> b959708bebf61e502c3f7bb6720ce41a921bf5c1:

> * webext-ublock-origin is back in buster since 2018-07-17 - should we install it from buster instead of sid?

Debian testing has no security support; I prefer tracking a dist that gets the security fixes ASAP. Otherwise, for each package we pin to Buster, we need to track security issues & fixes manually.

#40 Updated by segfault 2018-08-08 08:16:20

6f6d798378d06064d3258273a0900d359d14702d:

I tested this and it’s enough to mount a tmpfs on the chroot’s /dev/shm, we don’t have give it access to the root filesystem’s /dev/shm.

#41 Updated by segfault 2018-08-08 08:41:50

2b521bc21581fe922782bb2e553b460c370da2d6:

Most of the Torbutton prefs removed here are still listed on https://www.torproject.org/docs/torbutton/en/design/index.html. Maybe we should create a ticket in the torproject trac if the prefs are not supported anymore.

#42 Updated by intrigeri 2018-08-08 08:51:26

> Most of the Torbutton prefs removed here are still listed on https://www.torproject.org/docs/torbutton/en/design/index.html. Maybe we should create a ticket in the torproject trac if the prefs are not supported anymore.

Yeah, the Tor Browser desing doc is awfully outdated. https://trac.torproject.org/projects/tor/ticket/25021 already tracks this.

#43 Updated by intrigeri 2018-08-08 09:14:32

> I tested this and it’s enough to mount a tmpfs on the chroot’s /dev/shm, we don’t have give it access to the root filesystem’s /dev/shm.

Great idea, implemented!

#44 Updated by segfault 2018-08-08 09:20:14

9757969e891054b2b259ea63b1d2a97c568a59ba:

I don’t see a Stop/Reload button in my test build. And browser.uiCustomization.state in about:config doesn’t include stop-reload-button.

#45 Updated by segfault 2018-08-08 09:46:23

> 9757969e891054b2b259ea63b1d2a97c568a59ba:
>
> I don’t see a Stop/Reload button in my test build. And browser.uiCustomization.state in about:config doesn’t include stop-reload-button.

Nevermind, that’s because my test build doesn’t include this commit (which is strange, because the commit is from July 3 and I built the branch last week, but whatever).

#46 Updated by segfault 2018-08-08 12:39:50

0bcdc8ad14374f5c4e91807a84ece82a20e684a0:

I don’t understand the purpose of the changed line. Can you explain the effect of that line?

#47 Updated by segfault 2018-08-08 12:43:20

segfault wrote:
> 0bcdc8ad14374f5c4e91807a84ece82a20e684a0:
>
> I don’t understand the purpose of the changed line. Can you explain the effect of that line?

Same for the change in 6d681cd90343bb4e7ef6e7d49241dbb744063b34.

#48 Updated by segfault 2018-08-08 13:33:23

f255a4ede6ab285287556e39e358110e513132b1:

In the recovery method, what’s the purpose of hitting Escape and then waiting for the reload button to vanish? I thought that maybe this should stop loading the page, but then it should be the stop button that vanishes.

#49 Updated by segfault 2018-08-08 13:54:56

I’m done with the review up to 85392012d5dc8b5934286fa92a3f3c7e6829998c (the currently most recent commit).

#50 Updated by intrigeri 2018-08-08 14:29:03

segfault wrote:
> 0bcdc8ad14374f5c4e91807a84ece82a20e684a0:
>
> I don’t understand the purpose of the changed line. Can you explain the effect of that line?

This was addressed over IM.

#51 Updated by intrigeri 2018-08-08 14:29:44

segfault wrote:
> Same for the change in 6d681cd90343bb4e7ef6e7d49241dbb744063b34.

This was resolved over IM.

#52 Updated by intrigeri 2018-08-08 14:30:48

> f255a4ede6ab285287556e39e358110e513132b1:

> In the recovery method, what’s the purpose of hitting Escape and then waiting for the reload button to vanish? I thought that maybe this should stop loading the page, but then it should be the stop button that vanishes.

Wow, good catch! It seems that I’ve cargo-culted this code from When /^I open the address "([^"]*)" in the (.*)$/ do |address, browser|, where it was introduced 3 years ago via commit:26d902fe90d68ab0fa58d4bd46b4c821a48e5277. That code does not make any sense to me so I’ve fixed it as you’re suggesting. I’m running the full test suite on it and we’ll see.

#53 Updated by segfault 2018-08-08 16:10:26

852ce14b81c00e6bb1bf0376e2d007c4dfb4e875:

I don’t like it that currently the icons of NoScript and HTTPS Everywhere are not shown during the first TB launch (FWIW, the uBlock Origin icon is still shown).

Which problems did you see that made you remove these preferences? I tried readding this single pref; it fixes the hidden icons and I don’t see any problems:

user_pref("extensions.torbutton.inserted_button", true);

#54 Updated by intrigeri 2018-08-09 05:27:28

intrigeri wrote:
> > f255a4ede6ab285287556e39e358110e513132b1:
>
> > In the recovery method, what’s the purpose of hitting Escape and then waiting for the reload button to vanish? I thought that maybe this should stop loading the page, but then it should be the stop button that vanishes.
>
> Wow, good catch! It seems that I’ve cargo-culted this code from When /^I open the address "([^"]*)" in the (.*)$/ do |address, browser|, where it was introduced 3 years ago via commit:26d902fe90d68ab0fa58d4bd46b4c821a48e5277. That code does not make any sense to me so I’ve fixed it as you’re suggesting. I’m running the full test suite on it and we’ll see.

The fix seems to work fine: commit:b6a409fe7057da5149df272a529bfa9b463faa0a :)

#55 Updated by intrigeri 2018-08-09 07:04:56

> I don’t like it that currently the icons of NoScript and HTTPS Everywhere are not shown during the first TB launch (FWIW, the uBlock Origin icon is still shown).

I don’t like it either but that’s an upstream bug (see bug link in the commit message and I can reproduce this with a pristine Tor Browser). Now, of course Tails users are affected more than others because on every boot of Tails they’re in the “first launch” situation.

> Which problems did you see that made you remove these preferences?

I don’t remember :/
My bad for not writing a better commit message, now I get to spend more time on it…

> I tried readding this single pref; it fixes the hidden icons and I don’t see any problems:
> user_pref("extensions.torbutton.inserted_button", true);

Interesting, I’ll take another quick look at it ⇒ I’ve filed Bug #15777.

#57 Updated by segfault 2018-08-09 09:13:47

Reviewed up to commit 7bdea0f2edd43eb1d91e619b53d88b911cffffbb, everything LGTM.