Re: Incompatible changes, security, and good practice

Yo Eric! On Thu, 6 Oct 2016 23:10:37 -0400 "Eric S. Raymond" wrote: > Gary E. Miller : > > Yo Eric! > > > > On Thu, 6 Oct 2016 17:06:29 -0400 (EDT) > > e...@thyrsus.com (Eric S. Raymond) wrote: > > > > > 1. Technical justification > > > > > The

Re: Incompatible changes, security, and good practice

Gary E. Miller : > Yo Eric! > > On Thu, 6 Oct 2016 17:06:29 -0400 (EDT) > e...@thyrsus.com (Eric S. Raymond) wrote: > > > 1. Technical justification > > > The narrow technical case for disabling unauthenticated symmetric-peer > > mode is clear. > > No, for many reasons. >

Re: KERNEL_PLL

e...@thyrsus.com said: > What is adjtimex/ntp_adjtime doing that is "drift correction" but not clock > slewing? I thought clock slewing was wjat that call did. Deep inside the kernel, the time keeping code does roughly: time += delta_cycles * time_per_cycle That works if the cycles are old

Re: [time-nuts] Need Time Help

> It wouldn't take much to persuade me to drop this 'feature', then. I have no strong opinions. The build default is off. We don't have anybody testing it. On the other hand, it was useful for somebody and it isn't a lot of code and it isn't the sort of code that attracts security problems.

Re: Changing the access defaults

e...@thyrsus.com said: > Out of the box, ntpd ships with anyone on the net able to do anything on the > to your server - query it, KOD it, peer with it, modify its configuration > with ntpq, etc. No. It makes sense to let people query your server by default. (but see below) I think the peer

Re: Incompatible changes, security, and good practice

On 10/6/16, Gary E. Miller wrote: > This is NOT an all or nothing decision. There are other ways to > mitigate this problem that do not involve major silent breakage. You've argued this a few times, but you still haven't specified what you have in mind. Here's one option that

Re: Incompatible changes, security, and good practice

Yo Eric! On Thu, 6 Oct 2016 17:06:29 -0400 (EDT) e...@thyrsus.com (Eric S. Raymond) wrote: > 1. Technical justification > The narrow technical case for disabling unauthenticated symmetric-peer > mode is clear. No, for many reasons. a) Silently breaking existing working configurations is

Re: [time-nuts] Need Time Help

Daniel Franke : > On 10/6/16, Eric S. Raymond wrote: > > It wouldn't take much to persuade me to drop this 'feature', then. > > I still need to re-implement it in the refactored protocol code, but I > see no need to drop it permanently. It's not a lot of

Changing the access defaults

Heads up, Mark! Security and policy implications. Normally I'm not a big fan of backwards-incompatible changes. But when (a) they're justifiable in themselves on security grounds, and (b) they help us significantly going forward, the case for them starts to look pretty good. (Of course, we

Re: [time-nuts] Need Time Help

On 10/6/16, Eric S. Raymond wrote: > It wouldn't take much to persuade me to drop this 'feature', then. I still need to re-implement it in the refactored protocol code, but I see no need to drop it permanently. It's not a lot of code because a separate daemon (part of Samba)

Re: [time-nuts] Need Time Help

Daniel Franke : > AD is Active Directory. Windows NTP works just fine without MS-SNTP. It wouldn't take much to persuade me to drop this 'feature', then. -- http://www.catb.org/~esr/;>Eric S. Raymond ___ devel

Re: Forward-planning towards release 1.0

Hal Murray : > > >> What is the status of your simple setup doc? > > Ready to ship. Your review and corrections were the last polishing step I > > thought it needed. > > I thought we were waiting for the pool/restrict bug to get fixed. > > Has it been updated to use

Re: KERNEL_PLL

Hal Murray : > > e...@thyrsus.com said: > >> It might be useful to make sure that any workaround for > >> OS X is general enough to handle another case. > > It will be. We just fall back to the old BSD adjtime(2) call, which > > everybody (even OS X) has. > > Thanks.

Re: [time-nuts] Need Time Help

> This deliberately discards interleave interleave support. Peer > mode may be broken, broadcast modes probably are broken, MS-SNTP > is not reimplemented. The MS-SNTP stuff is a special hack to get the packet signed by a microsoft server. It's not supported by the

Re: [time-nuts] Need Time Help

Yo Hal! On Wed, 05 Oct 2016 23:38:44 -0700 Hal Murray wrote: > g...@rellim.com said: > > Looks like NTPsec really need SNTP to support Windows clients, and > > the accuracy needs are minimal. > > SNTP and real NTP use the same packet formats so we can already >

Re: Fw: [time-nuts] Need Time Help

g...@rellim.com said: > Looks like NTPsec really need SNTP to support Windows clients, and the > accuracy needs are minimal. SNTP and real NTP use the same packet formats so we can already support Windows clients. -- These are my opinions. I hate spam.

Re: Forward-planning towards release 1.0

e...@thyrsus.com said: >> How are you going to test MS-SNTP? >> The old code, called out to a MS server to sign the response. That >> tied up the server. The people who needed it were running low >> volume so they were OK with that. > That's an issue I was not aware of, and makes me want to

Re: Forward-planning towards release 1.0

>> What is the status of your simple setup doc? > Ready to ship. Your review and corrections were the last polishing step I > thought it needed. I thought we were waiting for the pool/restrict bug to get fixed. Has it been updated to use the pool? What's the URL? -- These are my