05/02/11 16:55, intrigeri:
> Hi,
>
> anonym wrote (04 Feb 2011 13:38:11 GMT) :
>> New patch.
>
> Great work!
>
> I've tried building a .deb with this patch applied but:
>
> - I had to edit the patch to set the strip level to -p1 as the
> emailed one had paths starting with ../../ and quilt does not like
> this
Sorry about that.
> - the patch changes the same files as our good old
> amnesia-remove-useless-controls.patch
>
> => I've not applied amnesia-remove-useless-controls.patch. Someone
> should dig whether it is still relevant + functionally compatible with
> the bridges patch, and act accordingly.
I like the removal of the start/stop button/menu item since they are
conceptually wrong in our situation (system wide Tor instance).
> Also, I would be delighted if this option could be submitted upstream
> so that we don't have to maintain the diff and messages translations
> ourselves.
> Maybe the popup text could be written in a more generic way so that it
> applies to non-T(A)ILS systems as well, maybe even if doing so we
> would need a few more lines specific to T(A)ILS => a setting could be
> added to allow us to set a postfix to the popup message. What do you
> think?
My patch is essentially an ugly workaround (just think about the whole
concept of loopback IP addresses being regarded as "bogus" bridges) for
Tor but #2355. I don't think it can be made much more generic and
acceptable due to that, so IMHO sending it upstream isn't viable at this
point. Or do you have any ideas?
I'm looking into fixing #2355 myself (as Nick didn't seem to
enthusiastic about implementing it himself and I assume none of the
other devs are). What I'm thinking is this:
* "UseBridges 0" completely disabled bridges -- direct connection to the
Tor network no matter what.
* "UseBridges 1" enforces bridges, so Tor will never try to contact the
Tor network directly. If no bridge is configured, Tor will wait
inactively until one or more are added through the control port.
* "UseBridges auto" will make Tor use bridges if there's at least one
configured, but if there are none it will connect to the Tor network
directly.
Vidalia can then be made to react accordingly, i.e. when it starts with
the -bridgeconf parameter set (or maybe it should be default
behaviour?), it will check if UseBridges is 1 and if there's zero
bridges configured. If that is the case, Vidalia opens the network
configuration etc. just like my patch does. That's the patch I think we
should send upstream.
Cheers!
[1]
https://trac.torproject.org/projects/tor/ticket/2355
