r6 - 2007-10-30 - 22:06:32 - HarlanStennYou are here: NTP >  Dev Web > DevelopmentIssues > LineEditingLibraries
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Line Editing Libraries

In ntp-4.2.4 and before, ntp searched for and used -ledit or -lreadline to provide line editing capabilities. This mechanism was incomplete, as described in bug_small.png Bug #764.

We now use the following argument to configure to show the order we search for line editing libraries (and readline must be manually provided because it is GPL code and not compatible with things like OpenSSL):


In ntp-4.2.5 (at least) and before, the line editing facilities were put directly into the source code of ntpdc.c and ntpq.c - pretty much duplicated code.

I'm wondering if it would be useful to create a new library, say ntpline, which would contain a library that ntpdc and ntp would call to handle all line input.

libntpline/Makefile.am would produce this convenience library, using one of the following files:

 stdio.c        for normal stdio
 readline.c     for -lreadline-compatible code
 edit.c         for -ledit-compatible

Additional 'methods' could be added easily.

This would reduce the #ifdef clutter in ntp{q,dc}.c and also give us a single point of service for these functions.

I'm thinking we'd need:


as the API (off the top of my head, as a first pass).

-- HarlanStenn - 20 Oct 2007

I'd like to suggest a slightly simpler interface which I believe achieves the same aims.

Rather than a library built from three different sources we simply use a common header file ntpline.h to provide the shim between the application and the different libraries. The header file would use the existing #ifdef configs to select the appropriate library header files and implement the interface functions as either #define macros or inline functions.

This requires no changes to the build system rather than adding optional includes of different sources.

A slight expansion on your api, I also think ntpline_gets() has an implied operation than might confuse some so have changed the name.

 #define MAXLINE 512                     /* The minimum input line length we are guaranteed to process */
  void ntpline_init(void);                   /* Initialise the interface (must be called first) */
  char *ntpline_readline(char *prompt);  /* See below */
  void *nptline_close(void);              /* Release memory and shutdown */

ntpline_readline() issues the prompt which may be zero length or NULL and then gathers a line of input. The returned line may use malloc() 'd memory or a static buffer, will be terminated with a NUL character and may be longer than MAXLINE characters.

-- BobDunlop - 22 Oct 2007

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r8 < r7 < r6 < r5 < r4 | More topic actions...
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback