Hal Murray <hmur...@megapathdsl.net>:
> There is another potential worm in this can. I don't think if it applies to
> this case, but it's worth keeping in mind.
>
> Some of the flags that get decoded come from the kernel sources rather than
> NTP sources. They are generally the same across OSes and kernel versions,
> but I don't know how to verify that. I think the clean solution would be to
> decode them on the server. [Or copy the versions from one kernel to our
> sources and have the build step crash if they are defined in the kernel and
> different.)
You are right to raise this issue. Either fix would be messy though.
Mode 6 should really not be shipping those flag bits in hex at all; it
should decode them into a list of mode strings. That would be the
*right* fix, but of course it would break mode 6 backward compatibility.
I'm tempted to do it anyway. I'm normally extremely wary of doing things
that might break sysadmin scripts, but this is a rather improbable case -
somebody would have to be decoding those bits with a thing that isn't
ntpq or ntpmon itself to be affected.
We could keep the old behavior under ENABLE_CLASSIC_MODE. Hm. Hal,
what do you you think our actual risk exposure is here?
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
