Bug #12460

Thunderbird doesn't use its dedicated SocksPort

Added by intrigeri 2017-04-19 15:22:17 . Updated 2018-03-14 11:09:24 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_3.6
Start date:
2017-04-19
Due date:
% Done:

100%

Feature Branch:
bugfix/12460-drop-Thunderbird-SocksPort
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

Description

While testing 3.0~beta4 (TorBirdy 0.2.1-1 + some custom patches in tails.git), anonym noticed that icedove uses port 9050 while it should use 9061. So apparently extensions.torbirdy.custom.network.proxy.socks_port is not honored anymore.

I suspect one part of config/chroot_local-patches/0002-Allow-specifying-that-Enigmail-keyserver-communicati.patch (the added call to org.torbirdy.prefs.setProxyTor()) causes this problem.

Subtasks

Related issues

Blocks Tails - Feature #13245: Core work 2018Q1: Foundations Team Resolved 2017-06-29
Blocked by Tails - Bug #15132: devel branch FTBFS since aufs-dkms 4.14 is in sid Resolved 2017-12-29

History

#1 Updated by Anonymous 2017-04-19 15:34:58

When testing this, I suggest that you not only test fetching emails but also to update GPG keys over the keyserver. I suspect a similar problem.

#2 Updated by intrigeri 2017-04-19 17:17:41

> When testing this, I suggest that you not only test fetching emails but also to update GPG keys over the keyserver. I suspect a similar problem.

Good catch!

Sadly, I’ve got bad news. I don’t think we’ll be able to have GnuPG v2 use a different SOCKS port when run from Icedove than from the general case without doing a substantial amount of non-trivial work that risks breaking other stuff (e.g. smartcard support): I’ve solved the TorBirdy vs. GnuPG v2 situation by adding a TorBirdy pref that essentially says “don’t try to torify GnuPG yourself, it’s already torified and you don’t know how to do it with v2 anyway”, and enabling this pref in Tails. So there’s a trade-off to be found between how much time we want to spend on this (again) and how strong the circuit isolation we provide is.

IMO it’s acceptable that GnuPG always uses the same SOCKS port, regardless of who calls it, because we explicitly state that “Tails doesn’t magically separate your different contextual identities” (the circuit isolation we do is best effort, without any guarantee).

#3 Updated by Anonymous 2017-04-20 13:16:09

intrigeri wrote:
> > When testing this, I suggest that you not only test fetching emails but also to update GPG keys over the keyserver. I suspect a similar problem.
>
> Good catch!
>
> Sadly, I’ve got bad news. I don’t think we’ll be able to have GnuPG v2 use a different SOCKS port when run from Icedove than from the general case without doing a substantial amount of non-trivial work that risks breaking other stuff (e.g. smartcard support): I’ve solved the TorBirdy vs. GnuPG v2 situation by adding a TorBirdy pref that essentially says “don’t try to torify GnuPG yourself, it’s already torified and you don’t know how to do it with v2 anyway”, and enabling this pref in Tails. So there’s a trade-off to be found between how much time we want to spend on this (again) and how strong the circuit isolation we provide is.

When you say you added this preference, I suppose you mean that you added it to the upstream code as specified here: https://blog.torproject.org/blog/torbirdy-022-released with links to open bugs?

#4 Updated by emmapeel 2017-04-21 08:08:19

u wrote:
> When testing this, I suggest that you not only test fetching emails but also to update GPG keys over the keyserver. I suspect a similar problem.

Yeah I used to test while sending and receiving only, and it was always 9061 in previous versions.

#5 Updated by intrigeri 2017-04-29 12:07:00

> When you say you added this preference, I suppose you mean that you added it to the upstream code as specified here: https://blog.torproject.org/blog/torbirdy-022-released

Yes, I did implement this pref upstream, and enabled it in Tails.

> with links to open bugs?

What links/bugs are you referring to?

#6 Updated by intrigeri 2017-05-16 16:29:22

  • Target version changed from Tails_3.0~rc1 to Tails_3.1

We isolate the default SOCKS port based on IP and port anyway, so it’s no big deal.

#7 Updated by intrigeri 2017-06-29 10:22:21

#8 Updated by intrigeri 2017-07-23 15:08:12

  • Subject changed from Icedove doesn't use its dedicated SocksPort to Thunderbird doesn't use its dedicated SocksPort

#9 Updated by intrigeri 2017-07-25 06:51:52

  • Target version changed from Tails_3.1 to Tails_3.2

intrigeri wrote:
> We isolate the default SOCKS port based on IP and port anyway, so it’s no big deal.

… and thus IMO it’s lower priority than a number of other Foundations Team work such as Feature #12705 and Bug #12543. Adjusting Redmine metadata so it’s sorted in way that reflects this on my plate.

#10 Updated by intrigeri 2017-09-11 12:23:28

  • Target version changed from Tails_3.2 to Tails_3.3

Reprioritized in favour of Bug #14612.

#11 Updated by intrigeri 2017-09-11 12:24:32

  • blocked by deleted (Feature #13234: Core work 2017Q3: Foundations Team)

#12 Updated by intrigeri 2017-09-11 12:24:48

#13 Updated by intrigeri 2017-11-06 16:17:59

  • Target version changed from Tails_3.3 to Tails_3.5

I had to take over some work so let’s postpone this.

#14 Updated by intrigeri 2017-12-08 18:20:04

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

According to https://tails.boum.org/contribute/design/stream_isolation/ we use a dedicated SocksPort for the MUA as a trade-off: it gives poorer circuit isolation than if we used the default SocksPort, but we were ready to compromise on this in order to make POP-before-SMTP work. We’ve released Tails 3.0 with this change 4 months ago and I’ve not heard about anyone being harmed by the lack of POP-before-SMTP support, so I’ll simply drop the dedicated SocksPort and be done with it.

#15 Updated by intrigeri 2017-12-08 18:24:42

  • Feature Branch set to bugfix/12460-drop-Thunderbird-SocksPort

#16 Updated by intrigeri 2017-12-09 10:03:23

  • Assignee changed from intrigeri to anonym
  • Target version changed from Tails_3.5 to Tails_3.6
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

I could check email over IMAP, send over SMTP, and fetch a key from keyservers with Enigmail.

Assigning to anonym for QA with his Foundations Team hat (as per our new arrangement i.e. it’s not the RM’s job anymore).

If you feel comfortable taking this in a bugfix release, feel free to rebase on stable and merged there.

#17 Updated by intrigeri 2018-01-01 16:40:59

  • blocked by deleted (Feature #13244: Core work 2017Q4: Foundations Team)

#18 Updated by intrigeri 2018-01-01 16:41:04

#19 Updated by intrigeri 2018-01-01 17:09:57

  • Assignee changed from anonym to bertagaz

#20 Updated by intrigeri 2018-01-02 10:17:04

  • blocked by Bug #15132: devel branch FTBFS since aufs-dkms 4.14 is in sid added

#21 Updated by bertagaz 2018-01-31 13:40:39

  • Status changed from In Progress to Fix committed
  • Assignee deleted (bertagaz)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

intrigeri wrote:
> I could check email over IMAP, send over SMTP, and fetch a key from keyservers with Enigmail.

Build fine, automatic tests green, and I was able to fetch emails with POP or IMAP, send emails with SMTP and fetch OpenPGP keys with enigmail, so it’s now merged in devel, thanks for the fix!

#22 Updated by bertagaz 2018-03-14 11:09:24

  • Status changed from Fix committed to Resolved