IssueTracker

i noticed that tlsdate-helper.c mmaps a 32-bit value to hold time_t:

  time_map = mmap (NULL, sizeof (uint32_t),
                   PROT_READ | PROT_WRITE,
                   MAP_SHARED | MAP_ANONYMOUS, -1, 0);

which it passes to the child that makes the server connection:

static void
run_ssl (uint32_t *time_map, int time_is_an_illusion)
{
  ...
  // from /usr/include/openssl/ssl3.h
  //  ssl->s3->server_random is an unsigned char of 32 bits
  SSL_get_server_random(ssl, (unsigned char *)time_map, sizeof(uint32_t));

and this is because TLS 1.2 only encodes a 32-bit timestamp in the first 4 bytes.

if the server treats this as signed, then it means the limit is 2038. if it treats it as unsigned, it means the limit is 2106. i think our client side is OK because we're treating it as unsigned. so even if the server side treated it as signed 32-bit, if 2038 rolled around, it should be an easy fix on the server side and not require any client updates.

something to be aware of ... i could see this being a concern in the 2038 timeframe (based on devices going EOL), but i'd like to think we'd be on a completely diff system by 2106. i'll be long dead by then though, so i don't care so much. hence, P4.