Hola gentlemen,
On Thu, Jan 26, 2012 at 23:43, anonym <anonym@???> wrote:
> - vmid=$(date -ud "${vstart} -0130" +'%F %T')
> + vmid=$(date -ud "${vstart} -0030" +'%F %T')
>
> According to dir-spec.txt all directory authorities generates a new
> consensus every hour (see: fresh-until). Since we fetch a new consensus
> at every boot we can narrow the time points we set the time to to the
> middle of [valid-after, fresh-until], and since fresh until is always
> valid-after + 1 hour... yeah you get the picture. The benefit of this is
> that *if* htpdate fails (which should be much less likely these days)
> then the user still gets a time that is at most 30 minutes incorrect.
> This, incidentally, will prevent the known problem with hidden services
> refusing connections.
>
> Thoughts?
When writing and testing that script, I noticed that the incoming
valid-after is never more than an hour earlier from the current
(correct) time, but at that point it was all kind of black magic, and
I didn't know that (as you say) the reason is that the directory
authorities agree on a new consensus each hour. I think that in light
of that, it is fine to make this change, with following notes:
1. If /var/lib/tor/data is ever made persistent, this probably won't
cause *additional* complications wrt. tordate.
2. Isn't it best to use fresh-until instead of valid-until for vend as
well (and adjust vendchk accordingly)? I.e., if user's time is 1.5
hours off forward, you still want to put their time before
fresh-until, in case htpdate fails later (do hidden services want time
in valid-after..fresh-until range?)
3. If >50% of directory authorities die (as happened couple of weeks
ago), does it complicate the situation? I don't see how — remaining
authorities still have the old consensus, but thought to point out
this possibility anyway.
--
Maxim Kammerer
Liberté Linux (discussion / support:
http://dee.su/liberte-contribute)
