Feature #12115
Migrate to Tor Browser based on FF52
100%
Description
Files
Subtasks
Related issues
Has duplicate Tails - |
Duplicate | 2015-02-18 | |
Blocked by Tails - |
Resolved | 2016-05-14 | |
Blocks Tails - Bug #11106: Improve test suite thanks to upstream Firefox fix for feedback when access to a local file is denied | Confirmed | 2016-02-11 | |
Blocks Tails - |
Resolved | 2015-02-18 |
History
#1 Updated by anonym 2017-01-06 12:17:49
- blocked by
Bug #11419: Deal with mandatory extension signing post FF45esr added
#2 Updated by anonym 2017-01-06 12:21:25
- Target version set to Tails_2.11
FF52 will be released at the same time as Tails 2.11. That’s the earliest we can expect a Tor Browser based on it, but historically the Tor Browser folks have needed a bit more time so we’ll see (probably it will be Tails 2.12 in the end).
#3 Updated by anonym 2017-01-06 12:34:21
- blocks Bug #11106: Improve test suite thanks to upstream Firefox fix for feedback when access to a local file is denied added
#4 Updated by anonym 2017-02-21 12:43:36
- Target version changed from Tails_2.11 to Tails_3.0
I’ve [asked for schedule](https://lists.torproject.org/pipermail/tbb-dev/2017-February/000472.html) and got:
- April 18 (Tails 2.12): first alpha
- June 13 (Tails 3.0): final release
So I’ll start working on this first thing during the 3.0 cycle.
#5 Updated by intrigeri 2017-04-18 15:12:28
Do we want to try sneaking this into 3.0~rc1? If yes, please set the corresponding target version :)
#6 Updated by anonym 2017-04-20 09:45:12
- Target version changed from Tails_3.0 to Tails_3.0~rc1
- Parent task set to
Feature #12464 - Feature Branch set to feature/12464-tor-browser-7.0
#7 Updated by anonym 2017-04-20 14:25:33
- Status changed from Confirmed to In Progress
anonym wrote:
> * April 18 (Tails 2.12): first alpha
The feature branch installs this one.
In the resulting image our unsigned extensions still work since xpinstall.signatures.required
is still effective because the alpha is based on a development release of Firefox — the final Tor Browser 7.0 release will be based on an actually (to be) released Firefox, where this pref won’t work. So for Bug #11419 we still have to do something. I’m currently investigating our options and discussing with geko.
#8 Updated by intrigeri 2017-05-16 09:02:59
- Parent task deleted (
)Feature #12464
#9 Updated by intrigeri 2017-05-16 09:03:33
- has duplicate
Feature #12464: Upgrade Tor Browser to 7.0 added
#10 Updated by intrigeri 2017-05-16 09:04:42
- blocks
Bug #8917: Spurious "permission denied" error when trying to upload files from Tor Browser added
#11 Updated by anonym 2017-05-18 18:08:47
- File unsafe-browser-e10s-failure.log added
- File tor-browser-e10s-failure.log added
- % Done changed from 10 to 30
In the current state of the branch, both Tor Browser and the Unsafe Browser works seemingly fine, but only when e10s (multi-process Firefox) is disabled. Also the test suite hasn’t been adjusted yet (there will at least be need for some image bumping).
I’m attaching the logs of the browsers’ e10s failure here just to store them somewhere for now. I’d like us to at least be able to enable e10s for Tor Browser, but then we’ll also have to make our branding add-on compatible with it (currently it automatically disables e10s in Tor Browser even if we’d try to enable it).
#12 Updated by anonym 2017-05-19 18:00:15
- Assignee changed from anonym to intrigeri
- % Done changed from 30 to 50
- QA Check set to Ready for QA
The current state of the branch is the best I can do for 3.0~rc1. Problems:
Bug #12568: Browser bookmarks persistence is broken if enabled for the first time in 3.0~rc1 (commit:9abc143e9b2aa3fed0e565523687ea4884ab28aa)Feature #12569: e10s is disabled for all browsers (commit:1a11e3924b7036868d3164c86e70a9b6f8f0c071)
Please review’n’merge!
#13 Updated by intrigeri 2017-05-19 18:16:47
Merged current feature/stretch in the topic branch otherwise the build would fail on Jenkins.
#14 Updated by intrigeri 2017-05-19 20:16:54
Great work, congrats!
Note: the comment in commit:1e8bec50fa864ac4e9d5d9d156b93a39a6506710 is wrong: for now, the pid
tunable matches all pids; see /etc/apparmor.d/tunables/kernelvars
for details. So I suggest you 1. revert this commit to ease maintenance; 2. send the patch upstream anyway, but with a correct rationale: it’s simply good practice to use pid
instead of reinventing the wheel, and whenever pid
does what you believed it did, this profile will benefit from the improved confinement.
Other than that, code review passes, I’m now going to build & test this branch :)
#15 Updated by intrigeri 2017-05-19 21:57:11
Seen all scenarios of features/torified_browsing.feature features/unsafe_browser.feature features/tor_bridges.feature pass at least once locally, some of them after a few retries.
#16 Updated by intrigeri 2017-05-19 21:58:33
- Status changed from In Progress to Fix committed
- % Done changed from 50 to 100
Applied in changeset commit:db72a85b59fe84808970661853dc0570ecb7df73.
#17 Updated by intrigeri 2017-05-19 21:59:35
- Assignee deleted (
intrigeri) - QA Check changed from Ready for QA to Pass
#18 Updated by intrigeri 2017-05-23 09:03:39
- Status changed from Fix committed to Resolved