> On Oct 17, 2015, at 12:34 PM, Bryan Drewery <bdrew...@freebsd.org> wrote: > > On 10/17/15 11:25 AM, Ian Lepore wrote: >> On Fri, 2015-10-16 at 14:04 +0000, Cy Schubert wrote: >>> Author: cy >>> Date: Fri Oct 16 14:04:16 2015 >>> New Revision: 289421 >>> URL: https://svnweb.freebsd.org/changeset/base/289421 >>> >>> Log: >>> Add default leap-seconds file. This should help ntp networks get >>> the >>> leap second date correct >>> >>> Updates to the file can be obtained from ftp://time.nist.gov/pub/ o >>> r >>> ftp://tycho.usno.navy.mil/pub/ntp/. >>> >>> Suggested by: dwmalone >>> Reviewed by: roberto, dwmalone, delphij >>> Approved by: roberto >>> MFC after: 1 week >> >> One thing about this change scares me. In the ntpd documentation: >> >> If the leapseconds file is present, the leap bits for reference >> clocks and downstratum servers are ignored. >> >> I can't determine from casual code examination (and I don't have time >> to experiment now) whether that is true even if the file is expired. >> >> The leapfile expires every six months, and users must update it using >> some external mechanism, or they must have configured autokey stuff so >> that updates can be accepted from peer servers. In either case what >> we've done is created a default configuration that is likely to fail >> right out of the box, because at least for releases the file we deliver >> will be expired before they even download and install the image. >> >> At the very least I think we should hold off on MFC of this until we >> know for sure whether an expired-but-present leapfile causes incorrect >> operation. If a pending leap notification in the leap bits of packets >> from peer servers and refclocks will be honored when the file is >> expired, then there is no problem with this change. >> > > Yeah. This sounds like something that needs to be delivered more easily > in a normal update mechanism, such as packages. ENs every 6 months are > not practical for this and a lot of users don't always apply EN while > IMO they are more likely to apply package upgrades. Short of that, some > kind of periodic script could fetch an updated file <enter ssl cacert > discussion>.
The file itself is signed, but only weakly with a sha hash at the end. Don’t know if the hash is one of the ones that’s been broken yet or not. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
