01/26/2012 02:18 PM, anonym:
> 01/21/2012 04:16 PM, anonym:
>> 01/20/2012 07:15 PM, intrigeri:
>>> Hi,
>>>
>>> I've pushed some robustness improvements to feature/tordate (forked
>>> from stable branch, targetted at 0.10.1).
>
> I have now tested the additional commits, i.e.:
>
> 35a88c3 Only HUP Tor after setting the system time to the release date.
> 3bd28e1 Better deal with very badly off clocks.
> cf679d5 Minor code simplification.
> fec3f37 Set time from Tor unverified-consensus if needed.
> deac77c Tiny optimization.
> 243b1c7 Make has_consensus take an optional file argument.
These have been merged into stable and devel now since the problem I
described is likely not related to them, but a Tor bug.
Next batch of tordate commits are:
2575a78 Start time synchronization notification helper from XDG
autostart.
ee3944f Only wait two times 5*30 seconds for a Tor consensus, restarting
Tor in between.
e572bee Start time sync notification helper much earlier.
I have reviewed and tested them with positive results, so they are now
merged too. Hopefully ee3944f will prevent the problem reported in my
previous post if it ever occurs again (I didn't see it for 3-4 real
boots and 100 tries with different times set in a short simulation
script I ran inside a Tails session).
Just to make this tordate story a bit more never-ending I came up with a
one-liner improvement (wrap-warning!):
diff --git
a/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-tim
index b4e4515..80b8b34 100755
---
a/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh
+++
b/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh
@@ -167,7 +167,7 @@ maybe_set_time_from_tor_consensus() {
# Get various date points in Tor's format, and do some sanity checks
vstart=$(sed -n "/^valid-after \(${DATE_RE}\)"'$/s//\1/p; t q;
b; :q q'
vend=$(sed -n "/^valid-until \(${DATE_RE}\)"'$/s//\1/p; t q; b;
:q q' ${
- vmid=$(date -ud "${vstart} -0130" +'%F %T')
+ vmid=$(date -ud "${vstart} -0030" +'%F %T')
log "Tor: valid-after=${vstart} | valid-until=${vend}"
if ! date_points_are_sane "${vstart}" "${vend}"; then
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?
Cheers!
