NTPsec 1.2.5 released

[Hal Murray]

This area is a big mess.  I think we have to figure out what we mean by 
"support".

We need crypto in 3 areas:
  MD5 to hash IPv6 addresses to fit into 32 bits.
  Shared key
  NTS

We have a configure option to disable NTS.  It gets turned on 
automatically if you try to build on a system with sufficiently old 
OpenSSL.  We could add something similar for shared keys.

What does support mean if it can't build with NTS?

-------

FreeBSD ships with one version of OpenSSL, but you can install a newer (or 
older) version from their packages collection.  NTPsec knows how to find 
it.

$ openssl version
OpenSSL 3.5.6 7 Apr 2026 (Library: OpenSSL 3.5.6 7 Apr 2026)

$pkg search 
openssl-3.0.21,1               TLSv1.3 capable SSL and crypto library
openssl34-3.4.6                TLSv1.3 capable SSL and crypto library
openssl35-3.5.7                TLSv1.3 capable SSL and crypto library
openssl36-3.6.3                TLSv1.3 capable SSL and crypto library
openssl40-4.0.1                TLSv1.3 capable SSL and crypto library

-------

You can build yourself a version of OpenSSL from source.  I do it for 
testing upcoming releases.  Directions are in HOWTO-OpenSSL  I haven't 
tested those directions and any of their tarballs on any really old 
systems.

-------

> I think we wanted to keep supporting OpenSSL 1.1.1 for a bit longer since
> several Linux distributions still have it. Eg: 

How many of the people running old systems want modern NTPsec?  I assume 
the reason they are running such old code is that they don't want to rock 
the boat.

> - Debian 11 shipped OpenSSL 1.1.1. Standard LTS support ends August 2026.

>From apt show ntpsec on Debian 11/bullseye
    Package: ntpsec
    Version: 1.2.0+dfsg1-4

----------

The reason that I want to get rid of supporting 1.1.1 is to simplify the 
code.

There are 28 places that start with
  #if OPENSSL_VERSION_NUMBER

There is more in the attic, but they don't come under the support umbrella.

We did all the early NTS development on 1.1.1.  I don't remember any major 
changes when 3.0 came out.

Most of the ugliness is in the shared key code where I've been working recently.  I'll look into cleaning that up when things calm down.  I have the HMAC code close to ready to merge, but there is no rush for that.

In case anybody hasn't noticed yet, NIST now supports good crypto on their authenticated (aka shared key) service.
https://www.nist.gov/pml/time-and-frequency-division/time-services/nist-authenticated-ntp-service

SHA256 already works so I don't see any rush for HMAC-SHA256.


-- 
These are my opinions.  I hate spam.