[Tails-dev] tordate issue in Tails 0.14~rc1

Delete this message

Reply to this message
Autor: anonym
Data:  
Dla: The T(A)ILS public development discussion list
Temat: [Tails-dev] tordate issue in Tails 0.14~rc1
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