Hi!
Thanks a lot for TorBirdy. I've been evaluating it in practice for
a while, low-intensity though, and noticed no obvious problem, but
this was in no way a serious audit.
Then, I just had a quick look at the code.
A few comments and questions follow.
About:
// Anything that would cause another proxy type to be used, we'll make them
// fail closed with the following - if it can fail closed, that is!
pref("network.proxy.ssl", "127.0.0.1");
pref("network.proxy.ssl_port", 8118);
pref("network.proxy.http", "127.0.0.1");
pref("network.proxy.http_port", 8118);
pref("network.proxy.ftp", "127.0.0.1");
pref("network.proxy.ftp_port", 8118);
I don't understand why 127.0.0.1:8118 should be equivalent to "fail
closed": there may very well be a non-torifying proxy (such as
Privoxy) behind this port.
About:
// XXX: TODO --hidden-recipient should be used for each person but perhaps
// --throw-keyids will be an OK stopgap?
In my experience, --hidden-recipient / --throw-keyids are a pain in
practice, especially for recipients that happen to handle a number of
contextual identities, and OpenPGP key pairs thereof. So, I doubt it's
TorBirdy's job to force this upon its users: IMHO, the (probably rare)
incursions of Torbirdy into areas that are not strictly related to the
stated "brings safe Tor support to Thunderbird" goal should be very
careful and consensual.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
_______________________________________________
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
