Project

General

Profile

Bug #12460

Thunderbird doesn't use its dedicated SocksPort

Added by intrigeri 6 months ago. Updated about 1 month ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
04/19/2017
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Code
Blueprint:
Easy:
Affected tool:
Email Client

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.


Related issues

Blocks Tails - Feature #13244: Core work 2017Q4: Foundations Team Confirmed 06/29/2017

History

#1 Updated by u 6 months ago

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 6 months ago

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 u 6 months ago

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 6 months ago

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 6 months ago

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 5 months ago

  • 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 4 months ago

#8 Updated by intrigeri 3 months ago

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

#9 Updated by intrigeri 3 months ago

  • 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 #12705 and #12543. Adjusting Redmine metadata so it's sorted in way that reflects this on my plate.

#10 Updated by intrigeri about 1 month ago

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

Reprioritized in favour of #14612.

#11 Updated by intrigeri about 1 month ago

#12 Updated by intrigeri about 1 month ago

Also available in: Atom PDF