Eric said:
> 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?
I agree that it doesn't need to be fixed anytime soon and/or for 1.0.
The reason I sent that message is that it's a good example of what I expect
for "the list". More on that in another message.
I think that actually fixing it is reasonably simple and low risk. The hard
part would probably be writing the test harness.
The code to add the hole is:
restrict_mask = restrictions(rmtadr);
if (RES_FLAGS & restrict_mask) {
msyslog(LOG_INFO, "Server poking hole in restrictions for:
%s",
socktoa(rmtadr));
restrict_source(rmtadr, false, 0);
}
The code to remove it should be as simple. We'll need a new flag for
add-hole to set and unpeer to test.
---------
The other part of my message was that maybe we don't want to poke holes in
restrictions. Suppose I decide I don't want to use any servers run by
Dilbert but he has a server in the pool. I'd like to be able to add a
restrict line with a flag that says don't poke holes in me. Then the pool
code that processes DNS lookups could skip that slot rather than poke a hole
and add it.
----------
Those could be two items on the list or one item that covers them both.
--
These are my opinions. I hate spam.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
