Feature #17221

Replace TorBirdy's sanitizeHeaders() function

Added by segfault 2019-11-10 13:49:23 . Updated 2019-11-30 14:55:40 .

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

0%

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

Starter:
Affected tool:
Email Client
Deliverable for:

Description

TorBirdy sanitizes the “Date” and “Content-Language” headers of outgoing emails, see https://gitweb.torproject.org/torbirdy.git/tree/components/torbirdy.js#n393.

We should assess whether we can replace that function somehow. I assume that this would require patching Thunderbird.

Subtasks

Related issues

Related to Tails - Feature #17283: Upstream our new Thunderbird patches Resolved
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by segfault 2019-11-10 14:01:57

  • Target version set to Tails_4.1

#2 Updated by intrigeri 2019-11-25 10:49:04

#3 Updated by segfault 2019-11-25 22:35:04

  • Status changed from New to Confirmed

Regarding the “Date” header:

sanitizeHeaders rounds down the “Date” header to the nearest minute. This is to prevent fingerprinting of small clock offsets (see [1]).

This was done as part of [2], the corresponding Thunderbird issue [3] was closed without upstreaming the patch because the TorBirdy devs found a way to do it via TorBirdy (via jsmime.headeremitter.addStructuredEncoder() that is used in sanitizeHeaders()).

Since extensions won’t be able to use this function anymore, we would have to patch Thunderbird.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=902573#c10
[2] https://trac.torproject.org/projects/tor/ticket/6314
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=902573

Regarding the “Content-Language” header:

sanitizeHeaders() sets the “Content-Language” header to “en-US”, to prevent leaking the user’s default dictionary, see the corresponding TorBirdy issue [4].

There is also a Thunderbird issue [5], where a maintainer said that a patch is welcome.

[4] https://trac.torproject.org/projects/tor/ticket/22484
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1370217

So we would have to create two patches to Thunderbird to keep the functionality of sanitizeHeaders(). I can try to prepare those patches - except if someone already familiar with the Thunderbird code base (looking at @anonym) wants to jump in… :)

#4 Updated by segfault 2019-11-27 23:22:34

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|51dbd18538a0f970fc03f6c22e77249e5353e37d.

#5 Updated by segfault 2019-11-27 23:22:58

  • Assignee set to segfault
  • Feature Branch set to feature/17219-replace-torbirdy

#6 Updated by segfault 2019-11-28 11:51:03

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

#7 Updated by segfault 2019-11-28 11:52:23

The commits with “refs: Feature #17221” are ready for review.

#8 Updated by segfault 2019-11-28 11:53:59

  • Status changed from Needs Validation to In Progress

Applied in changeset commit:tails|07ebcd454ceefc044525981f1d3aefecdeddd240.

#9 Updated by segfault 2019-11-28 14:57:44

  • Status changed from In Progress to Needs Validation

#10 Updated by intrigeri 2019-11-28 16:25:16

  • Assignee set to intrigeri

#11 Updated by intrigeri 2019-11-28 17:27:59

LGTM at first glance. I did not test this yet (waiting for a successful image build) so I’m leaving this assigned to me for now.

Only one question: are these patches based on existing ones, written by someone else? If they are, the we need to attribute copyright and to add licensing info.

#12 Updated by segfault 2019-11-28 17:39:03

intrigeri wrote:
> LGTM at first glance. I did not test this yet (waiting for a successful image build) so I’m leaving this assigned to me for now.
>
> Only one question: are these patches based on existing ones, written by someone else?

The name and comment of the mail.mime.avoid_fingerprinting pref are from this patch: https://bug902573.bmoattachments.org/attachment.cgi?id=8684089

> If they are, the we need to attribute copyright and to add licensing info.

Where exactly should I attribute copyright? In the patch file?

#13 Updated by intrigeri 2019-11-28 18:14:23

segfault wrote:
> intrigeri wrote:
> > If they are, the we need to attribute copyright and to add licensing info.
>
> Where exactly should I attribute copyright? In the patch file?

This would be good enough IMO.

#14 Updated by intrigeri 2019-11-28 18:28:38

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

> LGTM at first glance. I did not test this yet (waiting for a successful image build) so I’m leaving this assigned to me for now.

Wrt. the date header: works for me!

Wrt. the Content-Language header:

  • I could not find out how to test this, since only the English dictionary is available in Thunderbird on this branch. Is this a regression?
  • At least, when logged into a Tails session in French, the header is set to en-us as expected. But as I understand it, this would be the case even without this patch, right?

#15 Updated by segfault 2019-11-28 21:20:33

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

intrigeri wrote:
> Wrt. the date header: works for me!

Yay!

> Wrt. the Content-Language header:
>
> * I could not find out how to test this, since only the English dictionary is available in Thunderbird on this branch.

I tested it by installing an additional dictionary via the Thunderbird Add-ons (e.g. British English Dictionary (Marco Pinto)). (I first downloaded it and then installed it via “Install Add-on From File”.)

> Is this a regression?

Oh, indeed, in 4.0 a lot of dictionaries were available. I created Feature #17267 to track that.

> * At least, when logged into a Tails session in French, the header is set to en-us as expected. But as I understand it, this would be the case even without this patch, right?

Yes, the patch is about the spellchecker dictionary.

#16 Updated by intrigeri 2019-11-29 05:14:59

  • Affected tool set to Email Client

#17 Updated by intrigeri 2019-11-29 07:52:26

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

segfault wrote:
> intrigeri wrote:
>> Wrt. the Content-Language header:
>>
>> * I could not find out how to test this, since only the English dictionary is available in Thunderbird on this branch.

> I tested it by installing an additional dictionary via the Thunderbird Add-ons (e.g. British English Dictionary (Marco Pinto)). (I first downloaded it and then installed it via “Install Add-on From File”.)

>> Is this a regression?

> Oh, indeed, in 4.0 a lot of dictionaries were available. I created Feature #17267 to track that.

>> * At least, when logged into a Tails session in French, the header is set to en-us as expected. But as I understand it, this would be the case even without this patch, right?

> Yes, the patch is about the spellchecker dictionary.

In an image built from abc690987d33cba0d16575a4bb48e9a0726f5342:

  • Encrypted email: no Content-Language header. I’ll assume it’s Enigmail doing its best to avoid leaking info about the cleartext.
  • Unencrypted email: Content-Language: en-US, both with English and French spellchecking enabled ⇒ works!

So AFAICT, the only remaining thing to do here is documenting the copyright & license for the patches. Ooh yeah.

#18 Updated by segfault 2019-11-30 14:35:55

> So AFAICT, the only remaining thing to do here is documenting the copyright & license for the patches. Ooh yeah.

I pushed a commit which does that. I assumed that the patch, which the authors tried to upstream, is licensed under the same license as the code it patches.

#19 Updated by segfault 2019-11-30 14:36:34

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

#20 Updated by intrigeri 2019-11-30 14:55:40

  • Status changed from Needs Validation to Resolved
  • Assignee deleted (intrigeri)

Thanks. Technically, we should do extra work to include this in a “Larger Work” licensed under GPL v3: https://www.gnu.org/licenses/license-list.html#MPL-2.0.
But in this case I don’t think it’s worth it because:

  • The patch is pretty small and almost trivial. It would be simple to re-develop it independently.
  • I doubt Arthur would mind; if we asked nicely, I bet he would happily re-license the patch for us under GPL v3.

#21 Updated by segfault 2019-12-01 11:57:01

  • related to Feature #17283: Upstream our new Thunderbird patches added