e...@thyrsus.com said: > 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 ship both hex and text. New code could use the text and ignore the hex. Old code would continue doing whatever it did. > We could keep the old behavior under ENABLE_CLASSIC_MODE. Hm. Hal, what do > you you think our actual risk exposure is here? That doesn't feel right, but I can't come up with a simple example to demonstrate why. I think the exposure is very low. Any geek that has written a mode 6 client can probably fix it quickly. The real problem is that this is just the tip of an iceberg. I'm sure there will be other fixes we want to make that are not backward compatible. Is shipping both a good general policy? Do we need to start tracking what we will support and/or develop a policy for when we drop support for a slot? -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
