Hi,
When I ran the test suite for Tails 0.14~rc1 I seem to have made a
mistake by passing a test which didn't pass. The test in question is the
"Time" test:
<https://tails.boum.org/contribute/release_process/test/#index10h1>
While running the test suite I ran several tests in parallel (to be more
efficient :)) which resulted in me creating a new VM profile. In
VirtualBox, which I use, the default is to have it's Host-to-Guest time
syncing on by default, which is run every second or so. Of course I
happened to run the time test in this new VM, so when I messed with the
clock, it was set correctly again *by* *the* *VM* some seconds later,
which made our time sync stuff seem to work.
But running that test without Host-to-Guest time syncing will fail since
Tor won't write an unverified-microdesc-consensus like it used to write
a unverified-consensus prior to Tor 0.2.3.x. wait_on_tor_consensus()
will hence never succeed. The use of microdescriptors isn't the issue as
Tor now fails earlier, right after "Bootstrapped 10%: Finished handshake
with directory server" instead of (as earlier) "Bootstrapped 20%: Asking
for network consensus". It gives this warning:
Jan 01 01:07:38.000 [warn] Certificate not yet valid. Either their
clock is set wrong, or your clock is wrong.
Jan 01 01:07:38.000 [warn] (certificate lifetime runs from Oct 15
14:53:13 2012 GMT through Oct 15 14:53:13 2013 GMT. Your time is
Jan 01 01:07:38 2000 GMT.)
Jan 01 01:07:39.000 [warn] Certificate not yet valid. Either their
clock is set wrong, or your clock is wrong.
Jan 01 01:07:39.000 [warn] (certificate lifetime runs from Oct 15
15:16:39 2012 GMT through Oct 15 15:16:39 2013 GMT. Your time is
Jan 01 01:07:39 2000 GMT.)
For the record, I started Tor at this 16:18:46 UTC in real time.
I tried a small patch (see below) which, in essence, moves
wait_on_tor_consensus() until after the "is_clock_way_off" check + fix
(which actually makes sense in general). It worked, because the Tails
release date (today) was close enough (but still outside, I believe) to
the certificate's issue date. I faked the release date to that of
0.14~rc1 (almost a week ago) and that also worked, which is weird given
that the certificate definitely wasn't valid then. Finally I tried
setting the release date to something like a month back, and that made
it fail like before.
This means we're in trouble, and that there likely is no easy fix. I
suspect we need modifications in Tor if we want our current approach to
work again. :/ I don't really know what to make of all of this, but I
suppose I'll look into it further tomorrow. I'd appreciate any input
though :).
Cheers!
(For the record, here's the patch:)
--- 20-time.sh.orig 2012-09-01 00:08:53.765292730 +0000
+++ 20-time.sh 2012-09-01 00:09:25.116894099 +0000
@@ -226,16 +226,15 @@
if tor_is_working; then
log "Tor has already opened a circuit"
else
- wait_for_tor_consensus
# It may be that all authority certificates look "expired" due to
# a clock far off into the future. In that case let's set the clock
# to the release date.
if is_clock_way_off; then
log "The clock looks very badly off. Setting system time to the
release date, restarting Tor and fetching a new consensus..."
- date --set="$(release_date)" > /dev/null
- service tor reload
- wait_for_tor_consensus
+ date --set="20120901"
+ service tor restart
fi
+ wait_for_tor_consensus
maybe_set_time_from_tor_consensus
fi
