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 _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev