Catching up -- time for a release?

[James Browning]

> On 05/01/2026 4:42 PM PDT Hal Murray via devel <devel at ntpsec.org> wrote:

:::snip:::

> I think it's time to start thinking about a release. Is there anything on
> your list that we should be sure to include?

I have some.

1. Make ntpdig not ask localhost when -c given (#868)
2. Bump waf to version 2.1.9, to heed GNU directories (#870)
3. Make mode 6 auth respect cleartext commands (#864)
4. Document best clock selection in ntpdig (#867)
5. Clarify config file inclusion and sources (#871) follow-up
6. Add a driver for the chrony socket refclock (#756)
7. Add a preempt clock option for external tools
8. Replace the ntpd log when it's not where it was before
9. Update revised file list for new drivers
10. Try using the "-pthread" cflag for compile & link
11. NTS-KE server to fail w/o AEAD alogorithm (#688)
12. Add release bot & documentation
13. Describe rare ntpviz refclocks more concisely
14. Prevent some broken ntpviz graphs (from a few datapoints, or one)

You might pick a few. I doubt more than that could get merged.

> I had a Raspberry Pi hang with bad time yesterday. It was configured to
> run with only NTS servers and Fedora doesn't have a fake-hwclock, After a
> power cycle, the time was way way off and it rejected all the certificates.
> 
> It would only take a few lines of code to check for time before the build
> date and get a good recent time from the drift file. I think I mentioned
> something like this a while ago, but don't remember any comments. Is that
> something we should do? Or carefully avoid?

There were some comments; Richard made more sense than I did.

Ignore the OCSP stapling bits of the earlier thread.
- https://lists.ntpsec.org/pipermail/devel/2019-February/007576.html
- https://lists.ntpsec.org/pipermail/devel/2026-March/010940.html