Hi,
anonym wrote (03 Feb 2011 16:07:52 GMT) :
> That's nice, but nickm responded to two of the bugs [1][2], and it
> seems like there won't be anything happening there soon that will be
> of help to us. I detailed a workaround in bug #2355 [3] which we
> might use in the meantime:
>> The only alternative workaround I can think of is to add
>> "UseBridges 1" and a bogus bridge (e.g. "Bridge 127.0.0.1:12345")
>> to torrc which will prevent the Tor client from connecting to the
>> Tor network until the user adds a proper bridge through vidalia.
>> This seems to work fine, but users might get confused when they see
>> that strange bridge turn up in vidalia.
> As implied, I've tested this. No leaks seem to happen with restart
> of Tor so I guess it's good. Also, adding a bridge seems to make Tor
> bootstrap quickly, so the bogus mirror doesn't seem to interfere.
He he, I had implemented this a few days ago, but had had no time to
commit and push it.
My implementation is meant to be a preliminary one that can be used as
a basis for further work. At least it should allow those who do know
at least one existing bridge address to use it by:
- passing the "bridge" option on the kernel command line
- using Vidalia to replace the buggy 127.0.0.1 bridge with known
working ones... or just adding bridges to the list.
Bye,
--
intrigeri <intrigeri@???>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Do not be trapped by the need to achieve anything.
| This way, you achieve everything.
