Hi,
anonym wrote (04 Oct 2011 10:07:10 GMT) :
>> - when the system time is way off: not tested yet
> Everything from the year 2000 up until some months into the future works
> for me. The problem is "way in the future", e.g. 2013. Then the all the
> authority certificates are invalid, so there's no valid consensus.
> 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.)
>> - 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.
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.
