Deciding what modes to keep.

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> Yo Daniel!
> 
> On Fri, 30 Sep 2016 14:50:12 -0400
> Daniel Franke <dfoxfranke at gmail.com> wrote:
> 
> > An empty specification in my new language has different semantics than
> > an empty specification in the old language so at some point there will
> > have to be a flag day as to which way it is interpreted, but I don't
> > think this is as big a deal as you've made it out to be.
> 
> I think it is a big deal.  UNtil we have our own rabid base of followers
> the only way NTPsec grows is by taking NTP Classic users.  They will
> want a drop in replacement.
> 
> So any upward extensible is fine, but trivial back-compatibility is
> essential.

I've carefully maneuvered to give us some wiggle room on that.  The
--enable-classic-mode build option produces bug-for-bug compatibility
(with one unavoidable minor exception near the generic clock driver).

I think the predicate "drop-in-replacement" is actually slightly less
important than "I could build it to be bug-for-bug compatible if I wanted
to", especially when we can justify behavior changes in the default build
on security grounds.

That is, as long as we early give adopters the psychological
reassurance of knowing we're conscientious about offering full
backward compatibility for people who *really want that*, I think we
can get away with incompatible changes that tighten security, like
dropping broadcast-client mode and changing the default restriction
set.  Especially when 99% of user will never see those changes because
they match what the standard boilerplate /etc/ntp.conf does anyway.

I think the way to handle Gary's concern is, thus, with another
--enable-classic-mode hack. Use that option, get the old (insecure)
defaults.  Don't use it, get Daniel's new secure set.  Most users will
never care, again because of the boilerplate common restrictions.

I raised a closely related issue with Mark in a voice conversation
yesterday: that is, how do we trade off the security benefit of
dropping misfeatures like broadcast-client mode against the fact that,
well, we won't *have that feature*.

Mark doesn't have a fixed position on this.  I agree that we need to
decide case-by-case, thinking about user stories and remembering that
we have --enable-classic-mode to wall off bad choices in the legacy
code.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160930/002d0054/attachment.bin>