18/11/12 14:08, intrigeri wrote:
> hi,
>
> anonym wrote (17 Nov 2012 15:07:35 GMT) :
>> True, but IMHO that loop is beneficial at every place restart-tor maybe
>> will restart Vidalia, so that's a better place for it. See commit:
>
>> c61392a Wait for the ControlPort to be up before starting Vidalia.
>
> The proposed set of changes seemed to perfectly make sense in theory,
> but I was seriously scared to see us go change things in that fragile
> area of Tails at post-RC time
True. I started that branch simpler, with just adding a manual restart
of Vidalia in tordate's restart_tor() routine. But then I started this
somewhat more involved thing (when I realized that the Unsafe Web
Browser also would benefit from it), and I guess I didn't realize when I
passed beyond the point of a "small post-freeze bugfix".
> so I've tested this in various
> situations. Only one failed, probably not due to the proposed
> changes -- see the last one bellow:
Thanks for these!
> * boot without network cable, clock totally off
> -> failed to connect to the Tor network:
> stuck in is_clock_way_off's sleep 1 loop, at bootstrap progress
> 10%, which means tor_cert_lifetime_invalid is returning false:
> the SSL handshake just fails, without the grep'ed string being
> written to the log.
After running a test with full debug logging on I noticed that this
inconsistency is due to difference in log severity. When using a bridge
the strings we grep for in the log have the (higher) "info" severity
which we don't log by default, compared to "notice" when no bridge is
involved. Very annoying. I don't think we want to log "info" by
default... but I see no other easy fix.
> I *guess* that's a regression from 0.13 due
> to incomplete hacks to match Tor 0.2.3.x. If it's not known yet
> (I admit I'm a bit lost in this area these times),
Yes, it's a regression since all worked well with Tor 0.2.2.x, as used
in Tails 0.13. So this regression was really introduced by Tails
switching to Tor 0.2.3.x, it's just that bugfix/tordate_vs_tor_0.2.3.x
didn't catch this particular case. The branch this thread is about,
bugfix/bridge_mode_vs_tor_restarts has nothing to do with it.
> it probably deserves a ticket.
Tracked in todo/bridge_mode:_handle_way_off_clocks where some fixes are
proposed.
> Merged this bugfix branch into testing and devel.
I trust your testing, but if we feel this merge is too risky I wouldn't
be against reverting the merge and instead adding the simpler fix to
testing, i.e. to restart vidalia in tordate's (20-time.sh) restart_tor()
procedure.
Cheers!
