svn commit: r289421 - in head/etc: . mtree ntp
Warner Losh
imp at bsdimp.com
Sat Oct 17 19:24:15 UTC 2015
> On Oct 17, 2015, at 12:34 PM, Bryan Drewery <bdrewery at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20151017/b4a1170d/attachment.bin>
More information about the svn-src-head
mailing list