[tor-bugs] #6940 [TorBirdy]: analyze thunderbird HTTP proxy behaviour

[Tor Bug Tracker & Wiki]

#6940: analyze thunderbird HTTP proxy behaviour
----------------------+-----------------------------------------------------
 Reporter:  tagnaq    |          Owner:  sukhbir 
     Type:  task      |         Status:  assigned
 Priority:  normal    |      Milestone:          
Component:  TorBirdy  |        Version:          
 Keywords:            |         Parent:          
   Points:            |   Actualpoints:          
----------------------+-----------------------------------------------------

Comment(by ioerror):

 Replying to [comment:19 mikeperry]:
 > Replying to [comment:18 ioerror]:
 > > I've opened a ticket about the HTTP proxy in javascript: #6958
 >
 > I agree that Moxie needs mad props for bending XPCOM to his will with
 that JS HTTP proxy thing. However, I think a direct SOCKS patch for GPG
 (#2846) has less vulnerability surface and should be simpler code in
 total.

 We don't ship GPG as part of TorBirdy - we have to go with what we have
 and that is an older gpg, without a currently non-existent SOCKS patch or
 SOCKS support.

 >
 > The reason I think that the direct SOCKS patch reduces the vulnerability
 surface is nuanced. It probably doesn't matter unless we actually disable
 jsctypes in our own builds of Thunderbird (#6152).
 >
 > So for now, my recommendation is:
 >
 > 0. Disable GPG network activity by setting the proxy to garbage for now.

 That will break Enigmail for everyone. We're setting it to what should be
 a Torified HTTP proxy and if it fails, it fails. We won't break it for
 everyone.

 > 1. Try Moxie's code from #6958. If you can get it to work out of the box
 within an hour, use it for now

 That is the goal.

 > 2. If Moxie's code takes more than an hour to get it to work, you should
 try to provide a patch for SOCKS support to GPG (#2846). It's possible
 someone may have already written one already, somewhere...

 Such a patch is worthwhile but it will not help us until it is tested,
 merged, and then deployed to everyone. Thus, we'll still be waiting for a
 long long time. We should do both but first, we'll make a local HTTP proxy
 somehow.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6940#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online