Paul Eggert said:

Is there some reason we need a new TZDB release because of this? Do you use software that requires that this file come from a TZDB release, rather than from other sources such as the one mentioned above?

Yes, NTP can use the leap file from other sources. The idea of distributing it with TZDB is that it removes an operational step from running NTP with (hopefully) minimal work on the TZ team and OS distros since they are already distributing TZ info. Debian's ntpsec.conf now contains: leapfile /usr/share/zoneinfo/leap-seconds.list

I recall that traditionally ntpd needed leap-seconds.list and looked at the expiration but am not up to date with what its successor NTPsec is doing.

NTPsec uses the expiration date. Long version: GPS satellites distribute leap second info. Some receivers pass that on to the clients. So does NIST's ACTS phone/modem time service. WWVB in US, JJY in Japan, MSF in UK, and DCF77 in Germany also provide leap second info. I'm not sure how many receivers make that available. NTP can get leap info from 3 sources: file, radio, and network. If it has a valid file, it believes that. If it doesn't have a file, next in line is a local refclock. With no file and no refclocks, it gets leap info from network time servers. So a valid file when there is no leap pending will keep ntpd from believing buggy or malicious NTP servers on the net. I think there was an event where a bunch of servers didn't stop advertising a leap. It was many years ago. I've forgotten the details. I think the code was changed from believing one server to requiring a majority. There is a subtle difference between no-known-leap and known-no-leap. The NTP packet format doesn't have a way to indicate known-no-leap and that gap probably percolates through the code. It may not actually work as I described above but that's the way it should work. -- These are my opinions. I hate spam.