Autore: anonym Data: To: The Tails public development discussion list Oggetto: Re: [Tails-dev] Please review and test feature/tordate
01/30/2012 01:41 AM, intrigeri: > anonym wrote (29 Jan 2012 21:46:56 GMT) :
>> Setting it to fresh-until (time error 0 to 60 minutes in the future)
>> or up to one hour later would be safe though. I guess it's best to
>> have a margin in both ways, so our old middle of
>> [valid-after,valid-until] seems like the safest choice.
>
>> If everyone agree, let's revert.
>
> Please do.
Done.
> As far as I have understood, it seems to me the probability of seeing
> this problem happening in the wild is not big enough to warrant
> pushing back the imminent release of Tails 0.10.1 (with the
> problematic change in), is it?
Sure, even though it's a bit annoying. Even if htpdate fails, it seems
very unlikely to cause issues; here's the log from my updated script
that tests whether Tor still works when the issue is detected:
Sun Jan 29 23:59:48 UTC 2012:
valid-after: 2012-01-30 00:00:00
fresh-until: 2012-01-30 01:00:00
valid-until: 2012-01-30 03:00:00
Snap! Current time is before valid-after so the consensus is not valid yet!
Using htpdate [with --dont_set_date and our normal pools etc.] to check
if Tor works any way...
Tor works at 23:59:54
Existing circuits are still ok to use, which explains this. So it seems
the following things need to happen for a user to experience the issue:
1. tordate succeeds and get a clock that is E minutes backwards. (p = 0.5)
2. our new awesome htpdate fails. (p = 0.001 or something :))
3. Tor downloads a consensus update at some time H:X:00 where X >= 60-E.
(p = (E-D)/60 where D is the delay for the consensus to hit the chosen
directory mirror)
4. All current circuits will expire before the new hour (p = ?).
I wouldn't be surprised if our forum gets flooded by reports of this
issue since our time syncing terror never seems to go away :).
> (anonym: I think you forgot to send your last email to Maxim.)