Feature #17219

Replace TorBirdy

Added by segfault 2019-11-10 13:18:19 . Updated 2019-12-01 11:35:23 .

Status:
Resolved
Priority:
Elevated
Assignee:
segfault
Category:
Target version:
Tails_4.1
Start date:
Due date:
% Done:

100%

Feature Branch:
feature/17219-replace-torbirdy
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

Description

TorBirdy is not compatible with Thunderbird 68.

Quoting from Feature #17149#note-6:

Thunderbird 68 already only supports MailExtensions, but legacy extensions can supposedly be converted to MailExtensions relatively easily: It requires converting the old RDF manifest to a JSON manifest, and then in the JSON manifest the legacy key can be used to load the legacy XUL extension.
https://developer.thunderbird.net/add-ons/tb68
https://developer.thunderbird.net/add-ons/tb68/overlays

In either Thunderbird 72 or 78, the support for loading a legacy XUL extension via the JSON manifest will be removed. I still don’t understand in which version that will be removed, the page is titled “Updating Legacy Extensions for Thunderbird 78” but it then says “it should be [removed] whitin the Thunderbird 72 time frame - so by end of 2019”.
https://developer.thunderbird.net/add-ons/tb78

So we could spend some time to convert the manifest and try getting TorBirdy to work in Thunderbird 68, but that would only work for a few months. I think that instead we should try to implement and test a Tails-specific solution ASAP.

It would be great if other privacy distributions could reuse our solution (we should communicate with them about this).

Subtasks

Feature #17220: Set Thunderbird preferences previously set by TorBirdy Resolved

0
Feature #17221: Replace TorBirdy's sanitizeHeaders() function Resolved

0
Feature #17222: Set Thunderbird account preferences previously set by TorBirdy Resolved

0
Feature #17259: Update Thunderbird design doc Resolved intrigeri

0
Feature #17270: Update doc wrt. the removal of Torbirdy Resolved sajolida

100

Related issues

Related to Tails - Feature #17149: Figure out what to do with Torbirdy vs. Thunderbird 78 ESR Rejected
Related to Tails - Feature #17281: Tell other privacy distributions how we replaced TorBirdy Resolved
Blocks Tails - Feature #16771: Upgrade to Thunderbird 68 Resolved
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by segfault 2019-11-10 13:18:56

  • related to Feature #17149: Figure out what to do with Torbirdy vs. Thunderbird 78 ESR added

#2 Updated by segfault 2019-11-10 13:19:05

#3 Updated by segfault 2019-11-10 13:19:26

#4 Updated by segfault 2019-11-10 13:30:57

  • Description updated

I set the Target version to 4.1, the same as Feature #16771. But that release is scheduled for December 3, three weeks from now, which is short time for this feature, so I hope that we can ship 60.x in that release. It would be very helpful to know how long 60.x receives security updates, but I couldn’t find anything about an end of life for 60.x. I remember that a few months ago, I was also unsuccessfully looking for Thunderbird release dates, but back then intrigeri was able to find something.

#5 Updated by intrigeri 2019-11-10 14:07:21

  • Priority changed from Normal to Elevated

> I set the Target version to 4.1, the same as Feature #16771. But that release is scheduled for December 3, three weeks from now, which is short time for this feature, so I hope that we can ship 60.x in that release.

AFAIK, technically nothing prevents us from shipping Thunderbird 60.x in Tails 4.1.

The main downside I see is that this version of Thunderbird will be affected by known security issues. One could argue that it’s not much worse than usual, as it’s always the case with the Thunderbird we ship: Thunderbird usually publishes security releases a few days/weeks after 1. they’ve been published in the corresponding Firefox MFSA; 2. we’ve released a Tails to fix said MFSA in Tor Browser. (In passing, this makes Thunderbird another good candidate for distributing app updates independently from the Tails release cycle.) It’ll be a bit worse than usual as we’ll ship vulns for a longer time post-publication than usual, which gives attackers more time to find an exploitation vector.

Speaking with my random-Tails-person hat: it would be really nice if we could avoid this security drawback.

Replying with my FT lead hat, IMO: yes, that’s should be one of our priorities for 4.1, but it’s not worth burning any one of us out. Let’s try, but if we have to delay the upgrade to 68.x to Tails 4.2, so be it. segfault, what do you think?

> It would very helpful to know how long 60.x receives security updates, but I couldn’t find anything about an end of life for 60.x.

There’s no plan to publish further security updates for 60.x (Feature #16771#note-6). One of the reasons for this is that it’s based on the shared codebase with Firefox (“mozilla-central”) v60, which is not supported anymore by Mozilla.

> So we could spend some time to convert the manifest and try getting TorBirdy to work in Thunderbird 68, but that would only work for a few months. I think that instead we should try to implement and test a Tails-specific solution ASAP.

+1

> It would be great if other privacy distributions could reuse our solution (we should communicate with them about this).

Agreed!

#6 Updated by segfault 2019-11-13 20:45:39

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|3fbd8b6e4c210a69591a9016c49a75200021f77f.

#7 Updated by segfault 2019-11-13 20:46:01

  • Status changed from In Progress to Confirmed
  • Feature Branch set to feature/17219-replace-torbirdy

#8 Updated by segfault 2019-11-13 20:46:19

  • Status changed from Confirmed to In Progress

#9 Updated by anonym 2019-11-19 10:44:54

AFAICT TorBirdy does only the following:

  1. It sets safe values for certain prefs, in particular the proxy settings
  2. It offers an alternative (non-automated) account setup wizard
  3. It enforces port 563 + SSL/TLS for NNTP
  4. It changes some hardcoded account defaults for RSS to disable automatic fetching on startup/periodically

We never used 2 since we always patched Thunderbird’s automated setup wizard so it’s safe and used it. 3 is for NNTP which we could disable it (e.g. hide via userChrome.css) if we care enough. 4 doesn’t feel so very serious — if someone profiles you via your subscribed RSS feeds automatic fetching would leak your approximately uptime (btw, did we care about this with Liferea?). We really care about the result of 1, however.

So dropping TorBirdy could be as simple as:

  • Convince ourselves that losing 3-4 is ok
  • Import the resulting prefs from a started Thunderbird with TorBirdy from an up-to-date Tails session (i.e. just copy its prefs.js and manicure it)

#10 Updated by segfault 2019-11-23 17:44:39

anonym wrote:
> AFAICT TorBirdy does only the following:
>
> # It sets safe values for certain prefs, in particular the proxy settings
> # It offers an alternative (non-automated) account setup wizard
> # It enforces port 563 + SSL/TLS for NNTP
> # It changes some hardcoded account defaults for RSS to disable automatic fetching on startup/periodically

I see some other things it does, like setting account preferences (Feature #17222), including:

  • Setting a local draft folder. I wasn’t able to set this by default via prefs.
  • Disabling fetching of emails on startup/periodically (that’s my understanding of the loginAtStartUp, doBiff, and downloadOnBiff settings, but I could be wrong and they are not documented).

And it also sanitizes email headers, see Feature #17221.

#11 Updated by intrigeri 2019-11-28 17:13:34

Hi segfault!

First of all: impressive work, congrats!

As you requested today on XMPP + on subtasks, I’ve reviewed the branch up to commit:07ebcd454ceefc044525981f1d3aefecdeddd240.
I’ll write my comments on the subtasks.

I’ve prepared a few fixes and minor improvements on top of the branch, which I’ll push once I’ve verified that the branch builds again; please review them.

I did not check test suite results yet, because the branch FTBFS’ed before I started my review. I’ve fixed that so we should have test results tomorrow.

#12 Updated by intrigeri 2019-11-29 05:14:34

  • Affected tool set to Email Client

#13 Updated by intrigeri 2019-11-29 07:28:17

Another thing that needs at least a cleanup, and possibly some porting work: extensions.torbirdy.defaultprotocol.

#14 Updated by intrigeri 2019-11-30 15:01:29

  • Status changed from In Progress to Needs Validation
  • Assignee set to segfault

(Like the remaining subtasks.)

#15 Updated by intrigeri 2019-11-30 15:02:33

  • Status changed from Needs Validation to In Progress
  • Assignee deleted (segfault)

Gah, no, there’s still the extensions.torbirdy.defaultprotocol to deal with.

#16 Updated by segfault 2019-11-30 19:07:19

intrigeri wrote:
> Another thing that needs at least a cleanup, and possibly some porting work: extensions.torbirdy.defaultprotocol.

I was confused by how this pref used to work in Tails with TorBirdy, because in the TorBirdy code it’s only being used in the custom account wizard, which we don’t use. Then I created a Thunderbird account on a 4.0 image with Thunderbird persistence enabled, and it was configured as IMAP - even though extensions.torbirdy.defaultprotocol was set to 0 (i.e. POP3). So it seems like this feature was not actually working in Tails.

#17 Updated by intrigeri 2019-12-01 07:21:42

  • Status changed from In Progress to Needs Validation
  • Assignee set to segfault

I’ve reviewed the whole branch and I’m go for it!
Reassigning because the last blocker for the merge (Feature #17269) is a review currently assigned to segfault.

#18 Updated by segfault 2019-12-01 11:35:23

  • Status changed from Needs Validation to Resolved

Applied in changeset commit:tails|0566449b05d05b3cc687b49e678da3c466a649e8.

#19 Updated by segfault 2019-12-01 11:45:45

  • related to Feature #17281: Tell other privacy distributions how we replaced TorBirdy added