Theo de Raadt wrote: > First off, what a weird example you found. > > But more on the matter. Is your change even good advice? pool.ntp.org > is attackable via unauthenticated DNS, and based upon past experience > who can say if their administrators can even keep their infrastructure > secure. Furthermore, the ntp protocol has no security and can be > man-in-the-middled to provide lies (in a ntp daemon one can listen to > many replies and get some confidence, but this rdate example is > one-shot). > > So at best this gives you a potentially correct answer about Germany, > not considering the leap second, and not considering TZ database changes > which seem to be happening continually and "Legally". > > So an alternative proposal: Should this weird EXAMPLES section be deleted?
Heh, I did that first, but then I thought there was some value here. Give the user a few hints about things to search for, although my own searching indicates that TAI time isn't legal time. So drop that noise. Here's a slightly simpler example that mentions lack of authentication. Index: rdate.8 =================================================================== RCS file: /cvs/src/usr.sbin/rdate/rdate.8,v retrieving revision 1.37 diff -u -p -r1.37 rdate.8 --- rdate.8 10 Feb 2015 13:10:27 -0000 1.37 +++ rdate.8 6 Jan 2019 04:05:19 -0000 @@ -93,18 +93,9 @@ Always show the adjustment. record of date resets and time changes .El .Sh EXAMPLES -To get the legal time in Germany, set the -.Pa /etc/localtime -symlink to -.Pa /usr/share/zoneinfo/right/Europe/Berlin -and issue the following command: +Print the time in Germany, from an unauthenticated public pool: .Pp -.D1 Li "# rdate -v ptbtime1.ptb.de" -.Pp -The command of course assumes you have a working internet connection -and DNS set up to connect to the server at -.Sy Physikalisch-Technische Bundesanstalt -in Braunschweig, Germany. +.D1 Li "$ env TZ=Europe/Berlin rdate -p pool.ntp.org" .Sh SEE ALSO .Xr date 1 , .Xr adjtime 2 ,
