Re: [Tails-dev] Please review and merge bugfix/bridge_mode_v…

Delete this message

Reply to this message
Autor: anonym
Data:  
A: The Tails public development discussion list
Assumptes nous: Re: [Tails-dev] bridge mode vs. clock way off [Was: Please review and merge bugfix/bridge_mode_vs_tor_restarts]
Assumpte: Re: [Tails-dev] Please review and merge bugfix/bridge_mode_vs_tor_restarts
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!