ntpsec (1.2.1+dfsg1-6) unstable; urgency=low

  ntpsec is replacing ntp in Debian.

  If you were already using ntpsec, you can stop reading now.  For
  those coming from ntp, NTPsec is a drop-in replacement for common
  configurations, but some things have been removed or changed in the
  name of security and/or maintainability:
    https://docs.ntpsec.org/latest/ntpsec.html

  If you use a hardware clock, note that the Debian ntpsec package builds
  only the following drivers:
    arbiter,generic,hpgps,jjy,local,nmea,pps,shm,spectracom,trimble,zyfer

  NTPsec upstream dropped or deprecated several drivers:
    https://www.ntpsec.org/removal-plan.html
    https://www.ntpsec.org/drivers.html

  I am not building deprecated drivers.  However, if the reason for
  a driver's deprecation is only "two digit years", I am building it.

  The gpsd driver is not built.  While using the gpsd daemon is
  recommended, using the ntpd gpsd driver is not.  The two projects have
  upstream developers in common, who report that the ntpd gpsd driver is
  buggy and "makes all sorts of non-standard assumptions about how gpsd
  is configured.  A configuration that is contorted and non-obvious".
  Use the SHM driver instead:
    # GPS PPS reference (NTP1)
    refclock shm unit 1 refid PPS
    # GPS Serial data reference (NTP0)
    refclock shm unit 0 refid GPS

  For more gpsd <-> ntpd configuration details, see:
    https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/
    https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html

  The modem driver, despite working the last time I tested it, is NOT
  built because:
    1. Modems are not very common any more.
    2. Modem time services are disappearing (e.g. USNO's Washington D.C.
       number no longer answers).
    3. The telephone network is increasingly packet-switched rather
       than circuit-switched.  So you might as well use the Internet.
    4. Internet connections are always on.
    5. GPS receivers are cheap.

 -- Richard Laager <rlaager@debian.org>  Sun, 03 Apr 2022 15:23:36 -0500

ntpsec (1.2.0+dfsg1-1) unstable; urgency=medium

  IANA has assigned port 4460 to NTS-KE.  ntpd now uses port 4460 in both
  client and server modes.

 -- Richard Laager <rlaager@debian.org>  Mon, 16 Nov 2020 23:32:31 -0600

ntpsec (1.1.9+dfsg1-1) unstable; urgency=medium

  IANA has assigned port 4460 to NTS-KE.  ntpd in server mode now listens
  on both ports 123 and 4460 to facilitate transitioning.  ntpd in client
  mode now defaults to port 4460.  In the next upstream release, ntpd will
  listen only on port 4460.

 -- Richard Laager <rlaager@debian.org>  Wed, 12 Aug 2020 23:57:16 -0500

ntpsec (1.1.8+dfsg1-4) unstable; urgency=medium

  The NTS label has been changed.  This is a backwards incompatible change!
  This affects NTS in both client and server modes.  Public servers (e.g.
  CloudFlare) have already changed.

  The AppArmor policy no longer imports abstractions/ssl_certs and ssl_keys.
  ntpd needs to be able to read the certificate and key after dropping
  privileges; otherwise, it cannot handle certificate renewals (without a full
  restart).  Use a deploy script to copy the certificate and keys to
  /etc/ntpsec/cert-chain.pem and key.pem and permission them appropriately
  (e.g. mode 640 and group ntpsec).  For certbot users, a deploy script is
  provided; set the appropriate certificate name (e.g. the system's hostname)
  in the NTPSEC_CERTBOT_CERT_NAME variable in /etc/default/ntpsec.

 -- Richard Laager <rlaager@wiktel.com>  Sat, 25 Apr 2020 13:35:14 -0500
