[Git][NTPsec/ntpsec][master] 2 commits: Make pyntpq handle IO errors more gracefully.
Eric S. Raymond
gitlab at mg.gitlab.com
Fri Oct 28 11:20:28 UTC 2016
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
Commits:
65aa94aa by Eric S. Raymond at 2016-10-28T07:19:34-04:00
Make pyntpq handle IO errors more gracefully.
- - - - -
b40828e7 by Eric S. Raymond at 2016-10-28T07:19:34-04:00
Remove and/or fix obsolete references in the documentation.
- - - - -
9 changed files:
- docs/authentic.txt
- docs/discover.txt
- docs/includes/assoc-auxcommands.txt
- docs/includes/misc-options.txt
- docs/includes/mon-commands.txt
- docs/index.txt
- docs/pic/time1.gif
- docs/warp.txt
- ntpq/pyntpq
Changes:
=====================================
docs/authentic.txt
=====================================
--- a/docs/authentic.txt
+++ b/docs/authentic.txt
@@ -59,32 +59,30 @@ discarded.
The +auth+ flag controls whether new associations or remote
configuration commands require cryptographic authentication. This flag
can be set or reset by the +enable+ and +disable+ commands and also by
-remote configuration commands sent by a {ntpqman} program
-running in another machine. If this flag is enabled, which is the
-default case, new broadcast client and symmetric passive associations
-and remote configuration commands must be cryptographically
-authenticated using either symmetric key or public key cryptography. If
+remote configuration commands sent by a {ntpqman} program running in
+another machine. If this flag is enabled, which is the default case,
+new broadcast client and symmetric passive associations and remote
+configuration commands must be cryptographically authenticated. If
this flag is disabled, these operations are effective even if not
-cryptographic authenticated. It should be understood that operating with
-the +auth+ flag disabled invites a significant vulnerability where a rogue
-hacker can masquerade as a falseticker and seriously disrupt system
-timekeeping. It is important to note that this flag has no purpose other
-than to allow or disallow a new association in response to new broadcast
-and symmetric active messages and remote configuration commands and, in
-particular, the flag has no effect on the authentication process
-itself.
+cryptographic authenticated. It should be understood that operating
+with the +auth+ flag disabled invites a significant vulnerability
+where a cracker can masquerade as a falseticker and seriously disrupt
+system timekeeping. It is important to note that this flag has no
+purpose other than to allow or disallow a new association in response
+to new broadcast and symmetric active messages and remote
+configuration commands and, in particular, the flag has no effect on
+the authentication process itself.
An attractive alternative where multicast support is available is
manycast mode, in which clients periodically troll for servers as
described in the 'Automatic NTP Configuration Options' page of the Web
-documentation. Either symmetric key or public key cryptographic
-authentication can be used in this mode. The principle advantage of
-manycast mode is that potential servers need not be configured in
-advance, since the client finds them during regular operation, and the
-configuration files for all clients can be identical.
+documentation. Authentication can be used in this mode. The principle
+advantage of manycast mode is that potential servers need not be
+configured in advance, since the client finds them during regular
+operation, and the configuration files for all clients can be
+identical.
The security model and protocol schemes for symmetric key
-//and public key cryptography
are summarized below; further details are in the
briefings, papers and reports at the {project-fullname} page linked from
{project-website}.
@@ -293,9 +291,6 @@ for the +{ntpq}+ utility.
//users. Therefore, this flag should be used only for a dedicated server
//with no clients other than MS-SNTP.
-[[pub]]
-== Public Key Cryptography ==
-
'''''
include::includes/footer.txt[]
=====================================
docs/discover.txt
=====================================
--- a/docs/discover.txt
+++ b/docs/discover.txt
@@ -317,9 +317,9 @@ advance and all clients throughout the network can have the same
configuration file.
The use of cryptographic authentication is always a good idea in any
-server discovery scheme. Both symmetric key and public key cryptography
-can be used in the same scenarios as described above for the
-broadcast/multicast scheme.
+server discovery scheme. Cryptographic authentication can be used in
+the same scenarios as described above for the broadcast/multicast
+scheme.
[[pool]]
== Server Pool Scheme ==
=====================================
docs/includes/assoc-auxcommands.txt
=====================================
--- a/docs/includes/assoc-auxcommands.txt
+++ b/docs/includes/assoc-auxcommands.txt
@@ -8,8 +8,8 @@
server, then enters the broadcast client mode, in which it
synchronizes to succeeding broadcast messages. Note that, in order to
avoid accidental or malicious disruption in this mode, both the server
- and client should operate using symmetric-key or public-key
- authentication as described on the "Authentication Options" page.
+ and client should operate using authentication as described on the
+ "Authentication Options" page.
+manycastserver+ _address..._::
This command enables reception of manycast client messages to the
@@ -19,8 +19,7 @@
span of the reply and avoid a possibly massive implosion at the
original sender. Note that, in order to avoid accidental or malicious
disruption in this mode, both the server and client should operate
- using symmetric-key or public-key authentication as described on the
- "Authentication Options" page.
+ using authentication as described on the "Authentication Options" page.
+multicastclient+ _address..._::
This command enables reception of multicast server messages to the
@@ -30,8 +29,8 @@
server, then enters the broadcast client mode, in which it
synchronizes to succeeding multicast messages. Note that, in order to
avoid accidental or malicious disruption in this mode, both the server
- and client should operate using symmetric-key or public-key
- authentication as described on the "Authentication Options" page.
+ and client should operate using authentication as described on the
+ "Authentication Options" page.
+mdnstries+ _number_::
If we are participating in mDNS, after we have synched for the first
=====================================
docs/includes/misc-options.txt
=====================================
--- a/docs/includes/misc-options.txt
+++ b/docs/includes/misc-options.txt
@@ -42,8 +42,8 @@ and that file system links, symbolic or otherwise, should be avoided.
+auth+;;
Enables the server to synchronize with unconfigured peers only if
- the peer has been correctly authenticated using either public key or
- private key cryptography. The default for this flag is +enable+.
+ the peer has been correctly authenticated. The default for this
+ flag is +enable+.
+bclient+;;
Enables the server to listen for a message from a broadcast or
multicast server, as in the +multicastclient+ command with default
=====================================
docs/includes/mon-commands.txt
=====================================
--- a/docs/includes/mon-commands.txt
+++ b/docs/includes/mon-commands.txt
@@ -22,7 +22,7 @@ clock in decoded ASCII format, where meaningful. In some clock drivers
a good deal of additional information can be gathered and displayed as
well. See information specific to each clock for further details.
- +cryptostats+;;
+ +cdcryptostats+;;
This option requires the OpenSSL cryptographic software library. It
enables recording of cryptographic public key protocol information.
Each message received by the protocol module appends a line of the
=====================================
docs/index.txt
=====================================
--- a/docs/index.txt
+++ b/docs/index.txt
@@ -275,8 +275,7 @@ link:access.html[Access Control Support]::
Describes the access control mechanisms that can be used to limit
client access to various time and management functions.
link:authentic.html[Authentication Support]::
- Describes the authentication mechanisms for symmetric-key and
- public-key cryptography.
+ Describes the cryptographic authentication mechanisms.
link:rate.html[Rate Management]::
Describes the principles of rate management to minimize network load
and defend against DoS attacks.
=====================================
docs/pic/time1.gif
=====================================
Binary files a/docs/pic/time1.gif and b/docs/pic/time1.gif differ
=====================================
docs/warp.txt
=====================================
--- a/docs/warp.txt
+++ b/docs/warp.txt
@@ -39,9 +39,7 @@ Research Project] web site.
NTP time synchronization services are widely available in the public
Internet. The public NTP subnet currently includes several thousand
servers in most countries and on every continent of the globe, including
-Antarctica, and sometimes in space and on the sea floor. These servers
-support, directly or indirectly, a total population estimated at over 25
-million computers in the global Internet.
+Antarctica, and sometimes in space and on the sea floor.
The NTP subnet operates with a hierarchy of levels, where each level is
assigned a number called the stratum. Stratum 1 (primary) servers at the
@@ -97,22 +95,24 @@ link:leap.html[Leap Second Processing] page.
image:pic/time1.gif[]
-Figure 1. NTP Data Formats
-
-Figure 1 shows two NTP time formats, a 64-bit _timestamp_ format and a
-128-bit _datestamp_ format. The datestamp format is used internally,
-while the timestamp format is used in packet headers exchanged between
-clients and servers. The timestamp format spans 136 years, called an
-_era_. The current era began on 1 January 1900, while the next one
-begins in 2036. Details on these formats and conversions between them
-are in the white paper {millshome}y2k.html[The NTP
-Era and Era Numbering]. However, the NTP protocol will synchronize
-correctly, regardless of era, as long as the system clock is set
-initially within 68 years of the correct time. Further discussion on
-this issue is in the white paper
-{millshome}time.html[NTP Timestamp Calculations].
-Ordinarily, these formats are not seen by application programs, which
-convert these NTP formats to native formats.
+Figure 1. NTP Timestamp format
+
+Figure 1 shows the timestamp format used in packet headers exchanged
+between clients and servers. Ordinarily, this timestamp format is not
+seen by application programs, which converts it to native formats such
+as ISO8601 or RFC822-style Gregorian-calendar dates.
+
+The timestamp format spans 136 years, called an _era_. Conceptually,
+it is helpful to think of an absolute dates as being a tuple of one of
+these timestamps and an era number. The current era, era 0, began on 1
+January 1900, while the next one begins in 2036.
+
+Details on converting between era-timestamp pairs and timestamps are
+in the white paper {millshome}y2k.html[The NTP Era and Era
+Numbering]. The NTP protocol will synchronize correctly, regardless of
+era, as long as the system clock is set initially within 68 years (a
+half-era) of the correct time. Further discussion on this issue is in
+the white paper {millshome}time.html[NTP Timestamp Calculations].
[[arch]]
== 3. Architecture and Algorithms ==
@@ -132,7 +132,7 @@ server using the _on-wire protocol_ described in the white paper
the NTP On-Wire Protocols]. The protocol is resistant to lost, replayed
or spoofed packets.
-The poll process sends NTP packets at intervals ranging from 8 s to 36
+The poll process sends NTP packets at intervals ranging from 1 s to 36
hr. The intervals are managed as described on the link:poll.html[Poll
Process] page to maximize accuracy while minimizing network load. The
peer process receives NTP packets and performs the packet sanity tests
=====================================
ntpq/pyntpq
=====================================
--- a/ntpq/pyntpq
+++ b/ntpq/pyntpq
@@ -174,6 +174,9 @@ usage: help [ command ]
except Mode6Exception as e:
print(e.message)
return False
+ except IOError as e:
+ print(e.strerror)
+ return False
if len(self.peers) == 0:
if self.chosts:
@@ -295,6 +298,9 @@ usage: help [ command ]
except Mode6Exception as e:
print(e.message)
return
+ except IOError as e:
+ print(e.strerror)
+ return
if not variables:
if len(self.chosts) > 1:
self.warn("server=%s ", self.session.hostname)
@@ -435,6 +441,9 @@ usage: help [ command ]
except Mode6Exception as e:
print(e.message)
return False
+ except IOError as e:
+ print(e.strerror)
+ return False
if len(self.chosts) > 1:
self.say("server=%s " % self.session.hostname)
if not variables:
@@ -481,6 +490,9 @@ usage: timeout [ msec ]
except Mode6Exception as e:
print(e.message)
return
+ except IOError as e:
+ print(e.strerror)
+ return
if decodestatus:
if associd == 0:
statype = TYPE_SYS
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/84bd1d882185715cd858f88a5f7f0b8343f31b40...b40828e7f1768c61086566bb748fbf3c8fc12153
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/vc/attachments/20161028/f67ce51b/attachment.html>
More information about the vc
mailing list