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