How much effort is it worth to polish unpeer?

Eric S. Raymond esr at thyrsus.com
Thu May 25 14:50:11 UTC 2017


We have a bug relating to unpeer:

#315: unpeer doesn't remove server from reslist

Also, Hal wrote me as follows:

>This is just the tip of an iceberg:
>  ntpsec | unpeer doesn't remove server from reslist (#315)
>  Issue 315: https://gitlab.com/NTPsec/ntpsec/issues/315
>
>Background:
>  If you get a server or pool address via DNS lookup, it checks to see if
>replies from that address would get blocked by the current restrictions.  If
>yes, it pokes a hole in the restrictions to let them through.
>
>Aside from unpeer leaving them behind, they will also get left if a pool
>server that is not responding gets dropped.
>
>I think it takes another flag to mark a restriction as automatically added so
>we know we should delete it.
>
>I think we need another flag to say "don't poke a hole through this slot."

I've been investigating, and a couple of things have become apparent:

1. This is an old bug, inherited from Classic, in a part of the code
we've never touched.

2. This is not a point bug in code that is supposed to achieve the
function but failing; the code path to implement the implied
functionality is missing entirely.

3. This could be fixed, but doing so would add significant code
complexity - adding entirely new lookup code to the ntp_reslist.c
module.

I was going to dive in and do it, but my spider-sense says
"Danger!  Oncoming rathole!". 

I don't think this needs to be pre-1.0, and there's a KISS case for
simply documenting it as a known bug.  Opinions?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

It would be thought a hard government that should tax its people one tenth 
part.	-- Benjamin Franklin


More information about the devel mailing list