Requesting code review on possible fix for nopeer/pool conflict

[Eric S. Raymond]

Daniel Franke <dfoxfranke at gmail.com>:
> On 7/5/16, Eric S. Raymond <esr at thyrsus.com> wrote:
> > Hal's bug report reads like this:
> >
> >     restrict nopeer kills using the pool command. (Try it.) The symptom is
> >     that no slots ever show up in ntpq -p
> >
> >     The nopeer restriction is intended to prevent attackers from
> >     pretending to be a peer and then screwing up the local clock. The pool
> >     command is using the same peer mechanism to setup a temporary slot. We
> >     should be able to bypass that part of the restrict filter. We know
> >     what IP address to expect. The server slots already do it.
> 
> I think this working as designed. 'restrict nopeer' means "Don't
> establish unauthenticated ephemeral associations with this IP
> address", which is exactly what pool does. I agree this is stupid
> design but I don't think it's a bug. One more reason I need to get my
> ACL language implemented and restrict needs to die.
> 
> The whole receive() function you're looking at is about to get blown
> away in my ntp_proto refactor. Can you hold off on touching it until
> next week?

Yes, I can.

I think there is an argument that pool servers ought to be treated specially -
that, in fact, the pool keyword *means* that we should trust unauthenticated
peerd recommended by the pool dispatcher.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>