commit a29d6956a440aa5a29f071076f29dce48fd61680 Author: Jacob Appelbaum <jacob@appelbaum.net> 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",