Review and test Torbutton-birdy
I promised Jake that if he posted a pre-release of torbutton-birdy publicly to tor-talk I'd review and test it. He did, so I'll review his work and test it in wireshark and see what happens.
Activity
Trac:
Cc: N/A to g.koppen@jondos.deCurrently known/open issues: https://bugzilla.mozilla.org/show_bug.cgi?id=664633 https://bugzilla.mozilla.org/show_bug.cgi?id=669238 timestamp/timezone disclosure via date and message-id header fields.
Trac:
Cc: g.koppen@jondos.de to g.koppen@jondos.de, tagnaq@gmail.com
Yeah, I am downloaded the Thunderbird source to have a quick look at options today. I suspect that you can attack a XUL overlay binding to that damn autoconfig window and write some javascript to keep closing that fucker and/or navigate the user to the advanced window (which I think does not bypass proxy, right?)
I don't have time to write the code for you, but I'll see if I can find the names of the relevant XUL files you need to attach overlays to.
Replying to mikeperry:
Yeah, I am downloaded the Thunderbird source to have a quick look at options today. I suspect that you can attack a XUL overlay binding to that damn autoconfig window and write some javascript to keep closing that fucker and/or navigate the user to the advanced window (which I think does not bypass proxy, right?)
I don't have time to write the code for you, but I'll see if I can find the names of the relevant XUL files you need to attach overlays to.
This overlay is now in version 0.0.2 thanks to Sukhbir.
Replying to cypherpunks:
Currently known/open issues: https://bugzilla.mozilla.org/show_bug.cgi?id=664633 https://bugzilla.mozilla.org/show_bug.cgi?id=669238 timestamp/timezone disclosure via date and message-id header fields.
The timezone disclosure issue should now be fixed in version 0.0.2 as we set it to UTC. It's not fantastic by any means but it is certainly more uniform.
Version 0.0.2 is now out for testing/review: https://lists.torproject.org/pipermail/tor-talk/2012-May/024370.html
We still need to solve the message ID information leak and the reply_header_authorwrote issues. I suspect those are the two main issues left before we might consider a proper release.
-
How does Thunderbird handle attachments? Does it launch an external app for them automatically?
If so, you may also want to try to adapt the Torbutton component that warns users first: https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components/external-app-blocker.js
That thing works by hooking the components involved in app launching in Firefox. With any luck, they use the same component for Thunderbird.
Here's how it gets registered: https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome.manifest#l131
-
It could also be the case that Thunderbird's app launching is more controlled than Firefox. Firefox tries to have warning dialogs before auto-launching shit, it just fails miserably at it.
The prefs that are supposed to cause Firefox to launch a warning dialog are network.protocol-handler.warn*. There's also several other network.protocol-handler prefs that might be relevant.
Probably worth trying those out before trying to port that component over.
Replying to ioerror:
Version 0.0.2 is now out for testing/review: https://lists.torproject.org/pipermail/tor-talk/2012-May/024370.html
We still need to solve the message ID information leak and the reply_header_authorwrote issues. I suspect those are the two main issues left before we might consider a proper release.
The reply_header_authorwrote issue has been fixed now.
Replying to sukhbir:
Replying to ioerror:
Version 0.0.2 is now out for testing/review: https://lists.torproject.org/pipermail/tor-talk/2012-May/024370.html
We still need to solve the message ID information leak and the reply_header_authorwrote issues. I suspect those are the two main issues left before we might consider a proper release.
The reply_header_authorwrote issue has been fixed now.
I've released version 0.0.3: https://github.com/downloads/ioerror/torbirdy/torbirdy.xpi
So - I think that means we're not leaking directly from the proxy, not leaking language information, the autoconf wizard is blocked and now setting UTC for everything; what remains to be fixed before we suggest regular people use it?
We do enable warnings for external handlers: pref("network.protocol-handler.warn-external.http", true); pref("network.protocol-handler.warn-external.https", true);
What others look important?
We could easily register these as true as well:
network.protocol-handler.warn-external-default network.protocol-handler.warn-external.file network.protocol-handler.warn-external.ftpThoughts?
Can you get your own trac component torbirdy? That'd be better than having everything inside here in one thread.
Trac:
Cc: g.koppen@jondos.de, tagnaq@gmail.com, sukhbir.in@gmail.com to g.koppen@jondos.de, tagnaq@gmail.com, sukhbir.in@gmail.com, proper@secure-mail.biz-
Replying to proper:
Can you get your own trac component torbirdy? That'd be better than having everything inside here in one thread.
Yep, we should do this. I just created component TorBirdy and set ioerror as the owner of it for now. We should file all the known bugs there instead of in the TODO file+mailinglist.
Trac:
Component: Torbutton to TorBirdy