Re: Default config file behavior - request for comment

2017-09-20 Thread Hal Murray via devel
> 0 192.168.1.22/32 > ntpport interface ignore (and friends) > I'm having trouble mapping that to my mental model of how restriction blocks > work, which maked me nervous about modifying mearby code. There is code that adds rules like that to keep ntpd from getting time from i

Re: Default config file behavior - request for comment

2017-09-20 Thread Eric S. Raymond via devel
Hal Murray : > > e...@thyrsus.com said: > > Yes, we could keep tinkering with stuff like this. But I think it's time to > > squash whaetever tracker issues we can, then stand away and *launch* the > > damn rocket. > > You are the one who brought it up. I am. Perfectionism on my part. I'm a b

Re: Default config file behavior - request for comment

2017-09-20 Thread Hal Murray via devel
e...@thyrsus.com said: > Yes, we could keep tinkering with stuff like this. But I think it's time to > squash whaetever tracker issues we can, then stand away and *launch* the > damn rocket. You are the one who brought it up. What would you have done if somebody we didn't know had filed a bug

Re: Default config file behavior - request for comment

2017-09-20 Thread Eric S. Raymond via devel
Hal Murray : > > >> Code in choice #1, and if its easy to do, with a big loud warning to stderr > >> and logerr that it's doing nothing. > > > Can be done. > > How about exiting after the loud warnings? That solves the open-door problem > if the admin is focused on some other problem. As I s

Re: Default config file behavior - request for comment

2017-09-20 Thread Eric S. Raymond via devel
Achim Gratz via devel : > Eric S. Raymond via devel writes: > > I think the global pool name is a special case here. Why are they > > advertising > > that service if not to be used in exactly this way? > > No, I think their rule (and no, you don't get to redefine it) is that if > you wanted to h

Re: Default config file behavior - request for comment

2017-09-20 Thread Hal Murray via devel
>> Code in choice #1, and if its easy to do, with a big loud warning to stderr >> and logerr that it's doing nothing. > Can be done. How about exiting after the loud warnings? That solves the open-door problem if the admin is focused on some other problem. -- These are my opinions. I hate

Re: Default config file behavior - request for comment

2017-09-20 Thread Mark Atwood via devel
Achim is right, the ToS and documentation for pool.ntp.org forbids vendors from using pool.ntp.org as a default or a hardcoded entry. I have submitted an application for a vendor pool named ntpsec.pool.ntp.org In the meantime, our hardcoded default should be #1 "locked down do nothing", and our r

Re: Tinkerboard w/ TinkerOS 2.0.1

2017-09-20 Thread Achim Gratz via devel
Achim Gratz via devel writes: > I've switched the TinkerBoard to PPS and starting to collect PPS > statistics. Everything looks pretty good so far, I've also started > ovenizing the XTAL, but it will be some time before I get enough > statistics to extract the parameters from for a proper control

Re: Default config file behavior - request for comment

2017-09-20 Thread Achim Gratz via devel
Eric S. Raymond via devel writes: > I think the global pool name is a special case here. Why are they advertising > that service if not to be used in exactly this way? No, I think their rule (and no, you don't get to redefine it) is that if you wanted to have a hardcoded/default pool association

Re: Default config file behavior - request for comment

2017-09-20 Thread Eric S. Raymond via devel
Mark Atwood via devel : > While I like choice #2 for friendlyness, I have to agree re not to hardwire > the pool name without external consent. I think the global pool name is a special case here. Why are they advertising that service if not to be used in exactly this way? > Code in choice #1, a

Re: Default config file behavior - request for comment

2017-09-20 Thread Mark Atwood via devel
While I like choice #2 for friendlyness, I have to agree re not to hardwire the pool name without external consent. Code in choice #1, and if its easy to do, with a big loud warning to stderr and logerr that it's doing nothing. Supply a reference config file that implements #2 ..m On Wed, Sep 2

Re: Default config file behavior - request for comment

2017-09-20 Thread Achim Gratz via devel
Eric S. Raymond via devel writes: > There are three obvious ways to address this. > > 1. The infosec-focused way. Change the default restrictions to be > "allow nothing." This way, if you bring it up with no config, there's > no harm. It just spins inaccessibly. If it does that without complaini

Re: Default config file behavior - request for comment

2017-09-20 Thread Hal Murray via devel
> Right now, if ntpd is brought up with no config file, it runs with no > restrictions at all. Anyone can query it, anyone can configure it. This > seems dubious from a security point of view. Seems not-too-likely in the normal case since it won't keep good time. Also seems possible in, say, a

Default config file behavior - request for comment

2017-09-20 Thread Eric S. Raymond via devel
I've been thinking about security and defaults. Right now, if ntpd is brought up with no config file, it runs with no restrictions at all. Anyone can query it, anyone can configure it. This seems dubious from a security point of view. To fix this, we're going to have to feed it a string of config