The aim of the NTPsec project is high security, availability, and assurance. The more code we can throw away, the fewer potential vulnerabilities and complexity issues we will have.
Accordingly, we have already removed many obsolete features, and have a schedule of more feature removals planned. If something on this list is important to you, tell us. If the complexity cost of keeping it is low, you win. If the complexity cost is high, then we will need a donation of engineering time or money to support keeping it in the codebase.
The Autokey public-key-based authentication system feature has been removed. It has been reported to have been broken for some time, and added a significant amount of complexity.
Autokey-like functionality has been provided by implementing the RFC8915 "Network Time Security" protocol.
The ntpdc utility has been entirely removed. (All its capabilities are available through ntpq with a similar user interface.) Support for Mode 7 packets in ntpd has been removed along with it, significantly reducing total attack surface and code complexity.
The ntpsnmpd daemon, being half-complete and not fully conformant with RFC 5907, has been removed. In a future release we would be open to replacing it with a conformant implementation.
The long-deprecated ntpdate program has been replaced with a shell wrapper around ntpdig.
We have removed the following refclock drivers, which were either broken and won’t compile on modern systems (12, 21), or irretrievably obsolete due to the WWVB modulation change (3, 19, 32, 34, 36), or had unfixable Y2K or GPS rollover issues (21, 37), or unfixable security issues (16, 39, 43, 45), or relied on hardware interfaces no longer found on modern systems (6, 7, 35, 41), or were deprecated in NTP Classic and had their documentation removed (13, 14, 17), or duplicate support in other drivers (38) or were EOLed more than 20 years ago without aftermarket activity or Web chatter in a decade (9), or we have been advised by their maintainers should go (27), or were obvious dorm-room stunts not corresponding to real hardware (33).
Type 3: PSTI/Traconex 1020 WWV/WWVH Receiver (WWV_PST) |
Type 6: IRIG Audio Decoder (IRIG_AUDIO) |
Type 7: Radio CHU Audio Demodulator/Decoder (CHU) |
Type 9: Magnavox MX4200 GPS Receiver (GPS_MX4200) |
Type 10: Austron 2200A/2201A GPS Receivers (GPS_AS2201) |
Type 12: KSI/Odetics TPRO/S IRIG Interface |
Type 13: Leitch CSD 5300 Master Clock Controller (ATOM_LEITCH) |
Type 14: EES M201 MSF Receiver (REFCLOCK_MSF_EES) |
Type 16: Bancomm GPS/IRIG Receiver (GPS_BANCOMM) |
Type 17: Datum Precision Time System (GPS_DATUM) |
Type 19: Heath WWV/WWVH Receiver (WWV_HEATH) |
Type 21: TrueTime GPS-VME Interface (GPS_VME) |
Type 27: Arcron MSF Receiver (MSF_ARCRON) |
Type 31: Rockwell Jupiter GPS (GPS_JUPITER) |
Type 32: Chrono-log K-series WWVB receiver (CHRONOLOG) |
Type 33: Dumb Clock (DUMBCLOCK) |
Type 34: Ultralink WWVB Receivers (ULINK) |
Type 35: Conrad Parallel Port Radio Clock (PCF) |
Type 36: Radio WWV/H Audio Demodulator/Decoder (WWV) |
Type 37: Forum Graphic GPS Dating station (FG) |
Type 38: hopf GPS/DCF77 6021/komp for Serial Line (HOPF_S) |
Type 39: hopf GPS/DCF77 6039 for PCI-Bus (HOPF_P) |
Type 41: TrueTime 560 IRIG-B Decoder (REFCLK_TT560) |
Type 43: RIPE NCC interface for Trimble Palisade |
Type 45: Spectracom TSync PCI |
In addition, support for WWVB (broken by the 2013 modulation change), OMEGA (shut down in 1997), and GOES (shut down in 2005) has been removed from the Type 5 (TrueTime) driver. Support for GPS has been retained.
You may be unable to build NTPsec on a sufficiently archaic big-iron Unix platform. Support for the native APIs of any version that last shipped in the last century has been removed. The codebase assumes full POSIX.1-2001 and C99 conformance including ANSI pthreads; in some cases you may be able to meet this requirement by upgrading to a modern GCC- or clang-based toolchain.
Platform-dependent kernel-space code that raised potential security issues has been removed. No programs access /dev/kmem directly any longer, and STREAMS support for the parse driver has been deleted.
Legacy Windows support has been removed; it cost 10KLOC and a lot of complications. If we support Windows again, it will be via a POSIX/C99 emulation layer such as Cygwin or Microsoft’s Windows 10 facility for executing Linux binaries.
Support for VMS has been removed, and is unlikely to be restored unless that platform has achieved effectively full standards conformance and someone interested throws engineering time and money at us. Likewise for VxWorks.
We consider a refclock driver obsolete if it fails any of the following tests:
-
It has been discontinued for seven or more years and cannot be found for sale on the Web. Types 5, 10, 26, 27, 35, 37, 41.
-
Duplicates capabilities of GPSD, which specializes in GPSes. Types 20, 29, 30.
-
Accuracy an order of magnitude worse than a cheap 1PPS GPS. Type 33.
Thus, we plan to remove the following refclock drivers:
Type 5: TrueTime GPS/GOES Receivers (TRUETIME) |
Type 20: Generic NMEA GPS Receiver (NMEA) |
Type 29: Trimble Navigation Palisade GPS (GPS_PALISADE) |
Type 30: Motorola UT Oncore GPS (GPS_ONCORE) |
We also plan to remove the following modes in the Type 8 (PARSE) driver. These are for equipment that has not been available at least since 2003, and probably earlier.
Mode 3: ELV DCF7000 |
Mode 4: Walter Schmid DCF receiver Kit |
Mode 9: Trimble SVeeSix GPS Receiver TAIP Protocol |
Mode 10: Trimble SVeeSix GPS Receiver |
This will leave the following drivers in place:
Type 1: Undisciplined Local Clock |
Type 4: Spectracom GPS Receivers (SPECTRACOM) |
Type 8: Generic Reference Driver (PARSE) |
Type 11: Arbiter 1088A/B GPS Receiver (GPS_ARBITER) |
Type 18: NIST/USNO/PTB Modem Time Services (ACTS_MODEM) |
Type 22: PPS Clock Discipline (PPS) |
Type 26: Hewlett Packard 58503A GPS Receiver (GPS_HP) |
Type 28: Shared Memory Driver (SHM) |
Type 40: JJY Receivers (JJY) |
Type 42: Zyfer GPStarplus Receiver |
Type 44: NeoClock4X - DCF77 / TDF serial line |
Type 46: GPSD NG client protocol |
For details on the technical considerations, see our NTPD driver retention analysis.
