Hal Murray <hmur...@megapathdsl.net>:
>
> e...@thyrsus.com said:
> >> Do you have an example of where we need to change a
> >> driver variable on the fly?
>
> > No, I'm bothered because I'm (a) not sure we'll never need to do it, and (b)
> > pretty sure what the Dread God Finagle will arrange if I assume we won't.
> > :-)
>
> I just looked at the code. There is a table for refclocks. All are RO.
>
> While I was there, I searched some more. There is only one RW in the whole
> file:
>
> * System variable values. The array can be indexed by the variable
> * index to find the textual name. Mostly not order-sensitive.
> */
> static const struct ctl_var sys_var[] = {
> { 0, PADDING, "" },
> #define CS_LEAP 1
> { CS_LEAP, RW|DEF, "leap" },
>
> I'd be willing to change that to RO and drop the whole idea of writing things
> via ntpq.
Very tempting. I'll need to check whether any of the driver-specfic variables
are control knobs.
> That would leave the configure option. I've never used it.
I think we can justify both removals on security. If Mode 6 is a
read-only channel there can never be any exploits over it. That's
a significant gain in provable bulletproofness.
You want to reconfure your ntpd? Bounce it. This won't happen often.
I'm not ready to pull the trigger yet - Achim or Matt or someone else
might come up with a blocking objection - but you're making a strong case.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
