workaround for docker clock getting out of sync on mac

CHANGES.md

@@ -32,7 +32,39 @@ Rebooting the Docker VM fixed the clock skew.
 
 Oh docker =p
 
-OK. Back to testing the release.
+Some more info here. I suspect it might be a problem with the latest MacOS Sierro.
+
+https://forums.docker.com/t/syncing-clock-with-host/10432/15
+
+OK. Back to testing the release...
+
+Ok. I'm getting the clock skew again. This seems to be a serious issue.
+
+More information here:
+
+https://docs.docker.com/docker-for-mac/troubleshoot/#issues
+
+It seems I need to solve this, because the drift seems to be quite severe on MacOS.
+
+Need to test this on Windows as well, in case a workaround is required there too.
+
+So indeed, on MacOSX fixing the time with this workaround does it:
+
+    docker run --rm --privileged alpine hwclock -s
+
+This is somewhat frustrating, but now I need to run this on each docker action in addition to other steps? Ouch. Docker...
+
+Added the action to sync time on each docker run. Frustrating, but seems I have to do this.
+
+I think it's still possible to desync time if the Mac sleeps while the matcher or server are running.
+
+In a production environment this would be no problem, since the server and matcher would have time synched via NTP.
+
+But for people testing out yojimbo, this is annoying. Make sure to test this on Windows, in case that has gone backwards as well.
+
+Also, added a note to print out connection request deny / challenge response deny logs, so we can see *why* a client connection request is denied by the server.
+
+Right now its a bit too silent and mysterious. This is not good when anything goes wrong, you *must* see why.
 
 
 Thursday October 20th, 2016

WOULD BE NICE

@@ -4,13 +4,13 @@ WOULD BE NICE
 
     AEAD idea. Protocol is currently vulnerable to being spammed invalid connect tokens.
 
-    Of course, an invalid connect token won't decrypt, but a connect token that is an old stale token (reply attack) *will* decrypt.
+    Of course, an invalid connect token won't decrypt, but a connect token that is an old stale token (replay attack) *will* decrypt.
 
     So I think the key way to avoid replay attacks being effective, is to store the timestamp in the additional data section of the AEAD of the connect token.
 
     That way a reused connect token can be discarded quickly, by just checking the timestamp. 
 
-    If the timestamp is modified, then the signature check will quickly reject before the decrypt. 
+    If the timestamp is modified to pass the trivial check, then the signature check will quickly reject before the decrypt. Signature check is much faster than decrypt.
 
     This way, attackers cannot force an expensive decrypt connect token without actaully getting a token from the matcher (in the last 30 seconds...)
 
@@ -110,4 +110,8 @@ WOULD BE NICE
     It would much be better if it logged these things all the time during client/server/connect tests. The only place it should not log is in unit tests, where lots of failures will occur intentionally, and we don't want to see those spammed to the console.
 
     ------------------
+
+    ^---- To solve this, provide a callback on connection request deny, challenge response denied, so the user can print out a callback, then print that out in shared.h but only if not in logging mode (unit tests).
+
+    ------------------
 

premake5.lua

@@ -178,7 +178,8 @@ if not os.is "windows" then
 		trigger     = "docker",
 		description = "Build and run a yojimbo server inside a docker container",
 		execute = function ()
-			os.execute "rm -rf docker/libyojimbo && mkdir -p docker/libyojimbo && mkdir -p docker/libyojimbo/tests && cp *.h docker/libyojimbo && cp *.cpp docker/libyojimbo && cp premake5.lua docker/libyojimbo && cp tests/* docker/libyojimbo/tests && cp -R rapidjson docker/libyojimbo && cp -R tlsf docker/libyojimbo && cd docker && docker build -t \"networkprotocol:yojimbo-server\" . && rm -rf libyojimbo && docker run -ti -p 40000:40000/udp networkprotocol:yojimbo-server"
+            os.execute "docker run --rm --privileged alpine hwclock -s" -- workaround for clock getting out of sync on macos. see https://docs.docker.com/docker-for-mac/troubleshoot/#issues
+            os.execute "rm -rf docker/libyojimbo && mkdir -p docker/libyojimbo && mkdir -p docker/libyojimbo/tests && cp *.h docker/libyojimbo && cp *.cpp docker/libyojimbo && cp premake5.lua docker/libyojimbo && cp tests/* docker/libyojimbo/tests && cp -R rapidjson docker/libyojimbo && cp -R tlsf docker/libyojimbo && cd docker && docker build -t \"networkprotocol:yojimbo-server\" . && rm -rf libyojimbo && docker run -ti -p 40000:40000/udp networkprotocol:yojimbo-server"
 		end
 	}
 
@@ -187,6 +188,7 @@ if not os.is "windows" then
         trigger     = "matcher",
         description = "Build and run the matchmaker web service inside a docker container",
         execute = function ()
+            os.execute "docker run --rm --privileged alpine hwclock -s" -- workaround for clock getting out of sync on macos. see https://docs.docker.com/docker-for-mac/troubleshoot/#issues
             os.execute "cd docker/matcher && docker build -t networkprotocol:yojimbo-matcher . && docker run -ti -p 8080:8080 networkprotocol:yojimbo-matcher"
         end
     }