i recently noticed that torbirdy has been updated. but the new version of torbirdy still uses 192.168.0.10 for whonix settings.
edit: i’m assuming the transport functionality in play is surpassing the identity correlation protections offered if it was going through 10.152.152.10:9102 rather than 192.168.0.10:9102.
Thanks for the report.
It doesn’t circumvent stream isolation and it won’t use Tor’s TransPort, because icedove/torbirdy continue to work even with transparent proxying disabled.
Although not urgent, we should fix that anyhow. Submitted just now a pull request against torbirdy:
Looks like @greenbeans report still applies. (Thanks for posting it, once I figured out to search on icedove and proxy, was able to find and not duplicate the post. Do get a ‘do you really want to reply to a thread more than a year old’ caution, though.)
Couldn’t figure out where the 192.168.0.10:9102 traffic was coming from … seems to be icedove / internet / proxy settings socks.
I’m guessing most any other setting, none, auto, or system, makes more sense?
Perhaps this explains some of the rather delayed icedove performance / traffic I’ve been seeing?
Gave up on one provider at one point, fired up another, then a few days later the first one started coming in regularly. Puzzling.
If the presence of this non-existent proxy is indeed impacting performance / perception, perhaps the fixing priority should be bumped up.
It’s also in the torbirdy extension default socks settings.
icedove config shows 192.168.0.10 in:
extensions.torbirdy.custom.network.proxy.socks
network.proxy.socks
Yes. You can also manually set the proxy if that works better, but I think the performance impact is negligible. Since it’s fixed in TorBirdy git master branch, the fix will some day reach Debian. Good enough.
Interestingly, the setting keeps coming back. Not enabled, but present. e.g. Clear the 192.168… turn the setting off, then on, or exit and come back, 192.168… comes back. Irritating. Resetting (e.g. right click the variable set reset / clear the ‘user setting’) seems to finally do it. [Note, again, I didn’t say it’s effected, merely the default ip of 192.168… is repopulated.]
I take the point about torbirdy going forwards, but this is still in current installs. And icedove seems to go goofy / sluggish / delayed at times - I guess time will tell if this timing out on an the non-existent 92.168… proxy is a cause.
May be fixed in torbirdy, I’m guessing not in icedove itself.
TorBirdy enforces this setting once the WHONIX=1 environment variable is found. You’d need to start it while disabling that environment variable. Some start script. Try this from a terminal emulator (Konsole).
unset WHONIX
icedoveYou’re saying TorBirdy builds the setting, it’s not the base user set default at install / within TorBirdy itself?
e.g. Clearing it via resetting the config variable … it’s just going to come back at next restart?
In any case, doesn’t fix icedove’s default proxy setting (at install) within Whonix. Same issue?
TorBirdy enfoces these settings as long as the environment variable WHONIX=1 is set. When you clear it manually while that environemnt variable is set, it won’t persist restart of icedove.
Typing “unset WHONIX” once won’t persist. It only persists as long as the terminal window where you typed it is open. And only applies to that terminal window, not system wide. It can all be done. Linux environment variables work well. Until I write more on this perhaps it’s not needed, do you know how linux environment variables work?
There is no Whonix install time TorBirdy setting. This is only a feature of TorBirdy. Fixing this in Whonix before the TorBirdy update would require some cumbersome hack.
The version on mozilla addons and the torbirdy homepage is newer than the version in Debian stable. You can also try if this is fixed in the latest version. It works for me with 0.1.4.
I think you’re misunderstanding what I’m saying. You’re saying (I think) 192.168… is getting set by virtue of WHONIX=1 in environment / while I was saying / hoping / asking that unsetting the value permanently clears the problem going forwards?
If you’re saying it will keep coming back, regardless of what you’re doing (due to WHONIX=1) that isn’t entirely explicit.
[‘Simple’ work around would be to change menu entry to 'WHONIX=0 torbirdy - if the behaviour between 0/1 is that targeted.]
er/or, i.e. If none or system proxy setting is kept (vs manual), whether 192.168… is stuffed in there won’t matter.
``- actually … that’s doable within base whonix image. If torbirdy isn’t installed, wrapper will never get called. Once it is (presumably with newer ‘fixed’ version), wrapper will get replaced. In the mean time, updates to current installs would get ‘fixed’. (?)
[quote] Typing “unset WHONIX” … do you know how linux environment variables work?[/quote] Yep. Alternate workaround is, like the anondist’s … wrap icedove in a script / link. (Again, if WHONIX=0 is that surgical.)
[quote]There is no Whonix install time TorBirdy setting. This is only a feature of TorBirdy. Fixing this in Whonix before the TorBirdy update would require some cumbersome hack.
The version on mozilla addons and the torbirdy homepage is newer than the version in Debian stable. You can also try if this is fixed in the latest version. It works for me with 0.1.4.
[/quote]
Interesting, thank you / good to know.
Else I suppose I’d have to change the source within the current installation.
[I dislike going ‘non-standard’ … every customization is one more forgettable fiddly bit at every update, change, etc.]
To your point, a ‘bug’ … is. (It is what it is / situation unavoidable.)
Unsetting environment variable WHONIX for icedove starter isn’t a great solution for the distribution. -> Loss of stream isolation.