[tor-commits] [tlsdate/master] after a certain point time_map should not be zero

[ioerror@xxxxxxxxxxxxxx]

commit a29d6956a440aa5a29f071076f29dce48fd61680
Author: Jacob Appelbaum <jacob@xxxxxxxxxxxxx>
Date:   Fri Apr 26 19:25:29 2013 -0700

    after a certain point time_map should not be zero
    
    While porting tlsdate to Debian GNU/Hurd 7.0 I noticed that we would return
    zero as a valid server time. This happens as a result of some strange mmap and
    memcpy interactions on the Hurd. This could happen if the server was a false ticker
    or as a result of some other strange flukes, so we should never accept it and
    if time_map is zero, we should stop trying to use this server. We die when we
    encounter zero and it is probably the case that a smart administrator who
    wanted to mess with tlsdate users would return 32bits of zeros. We consider
    this useful as it is wrong and detectable as such.
---
 src/tlsdate-helper.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/tlsdate-helper.c b/src/tlsdate-helper.c
index d6a9d4b..311a377 100644
--- a/src/tlsdate-helper.c
+++ b/src/tlsdate-helper.c
@@ -1189,6 +1189,10 @@ main(int argc, char **argv)
 #else
   server_time_s = ntohl (*time_map);
 #endif
+  // We should never have a time_map of zero here;
+  // It either stayed zero or we have a false ticker.
+  if (0 == time_map)
+    die ("child process failed to update time map; weird platform issues?\n");
   munmap (time_map, sizeof (uint32_t));
 
   verb ("V: server time %u (difference is about %d s) was fetched in %lld ms\n",



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits