the ntp timestamp wrapping in 2036.

terminated by a null pointer.
ok rzalamena@ reyk@

case the dup2() would fail silently and the descriptor would remain with
the CLOEXEC flag causing the exec*()d child process to have unexpected
behavior.
ok guenther@

ok reyk@, bcook@

OK from the original author Alexander Guy

and actually not a "logging" function.  No functional change.

Original fix from Romuald Delavergne. ok henning@

time from HTTPS servers, by parsing the Date: header, and use the
median constraint time as a boundary to verify NTP responses.  This
adds some level of authentication and protection against MITM attacks
while preserving the accuracy of the NTP protocol; without relying on
authentication options for NTP that are basically unavailable at
present.  This is an initial implementation and the semantics will be
improved once it is in the tree.
Discussed with deraadt@ and henning@
OK henning@

ok jsing@ phessler@ naddy@

ok guenther@

This basically adds the "rtable %d" keyword to "listen on", "server",
"servers" keywords, to specify which routing table to use.
OK henning@ claudio@ sthen@
manpage reviewed by jmc@

but this might increase portability since some other systems do not
grok negative tv_usec well. ok henning@

time, and make ntpd use that to send the next uery to an ntp peer and the
like. this has the advantage that changes to the clock do not interfere
with the intervals. for example, when we start on machines without an
RTC and the initial settime (-s) kicks in, intervals were strange.
idea from amandal@entrisphere.com, this implementation by me
tested ckuethe, phessler, mbalmer, ok mbalmer

overcompensating. From DragonFly, uses recent adjtime(2) changes,
so you'll need a recent kernel. ok henning@

* Respond to the query with a reasonable received time (which
will help clients get better accuracy).
* Consolidate the server response code in preparation for a
completely 'proper' response to the client.
tips and ok from henning@

adjtime() when necessary to keep the local clock in sync
yes, that means ntpd syncs the local clock now.

ok henning@