10/04/2011 05:25 PM, intrigeri:
> anonym wrote (04 Oct 2011 10:07:10 GMT) :
>
>> In 20-time.sh we're only looking at cached-consensus for the
>> valid-{after,before} values, but due to the outdated certs, the
>> consensus will be put in unverified-consensus. We *could* take that into
>> account, see attached patch. I'm not pushing it as I'm not sure we want
>> to do this. After all, the consensus hasn't been verified, so the time
>> could be arbitrarily chosen by a malicious authority. That can't be good.
>
> Indeed, I don't think we want to do that. Doing it would defeat the
> reasoning that allowed us to make the compromise this new
> implementation is:
> https://tails.boum.org/todo/remove_the_htp_user_firewall_exception/#index5h1
>
> I've thus brought back that functionality we've been shipping for a while:
>
> commit c4fbcf991d8473198fa619531f524980a1714f99
>
> NetworkManager time hook: better deal with badly off clocks.
>
> If (Tor is still not working after we've tried to set time from the Tor consensus
> and the clock is badly off),
>
> this is probably because all authority certificates are seen as invalid,
> so there's no valid consensus.
>
> In that case let's set the clock to the release date and retry.
>
> (Untested yet.)
This doesn't work:
In the "clock way in the future" case we'll only get an
unverified-consensus. When tor restarts it will read
unverified-consensus, see that it now is valid, and then start using it.
cached-consensus will never be written, so wait_for_tor_consensus() will
never terminate.
When I noticed this I talked about it with nickm and Sebastian on #tor.
The real fix is that Tor should rewrite unverified-consensus into
cached-consensus whenever it's reloaded and successfully verified. Until
that is fixed it should be safe to do the renaming when Tor is not running.
See 1319c1c for potential fix (that has been verified to work).
>>> - htpdate (now torified) seems to fail a bit too often to my taste;
>>> perhaps the shiny new Tor has a hard time establishing circuits,
>>> resolving DNS and retrieving files from the web; needs to be
>>> investigated; note to myself: if htpdate forwarded wget's stderr,
>>> things would get easier to debug. It may may make sense to wait
>>> for cached-descriptors (see tor_is_running function in 20-time.sh)
>>> before running htpdate / touch'ing $TORDATE_DONE_FILE.
>
>> Confirmed. Perhaps we could add a --retries X option to htpdate,
>> where each wget fetch is allowed to fail X times (duh!). Issue: the
>> retried fetches may use the same faulty circuit and just fail again.
>
> I implemented "wait for working Tor before moving on" (bfd48a5).
> I hope it will work good enough to prevent us from adding more
> complexity into the mix.
I guess it will work for now, but the assumption of tor_is_working()
will be incorrect when /var/lib/tor is made persistent as we may have a
cached-descriptors from a previous Tails run.
