Incompatible changes, security, and good practice

Gary E. Miller gem at rellim.com
Fri Oct 7 03:27:13 UTC 2016


Yo Eric!

On Thu, 6 Oct 2016 23:10:37 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller <gem at rellim.com>:
> > Yo Eric!
> > 
> > On Thu,  6 Oct 2016 17:06:29 -0400 (EDT)
> > esr at thyrsus.com (Eric S. Raymond) wrote:
> >   
> > > 1. Technical justification  
> >   
> > > The narrow technical case for disabling unauthenticated
> > > symmetric-peer mode is clear.  
> > 
> > No, for many reasons.  
> > 
> > a) Silently breaking existing working configurations is always bad.
> > 
> > b) When NTPsec can not interoperate with existingg systems (that
> > can not be updated), then people will just not use NTPsec.  Only
> > when NTPsec has dominant market share can we just tell users to
> > suck it.
> > 
> > c) There were other changes that can be done to improve the
> > situation that do not have the problems a) and b).  Things might be
> > different if there were no other options, but that is not the
> > case.  Stop hijacking the discussion like this is the only way to
> > solve the problem.  
> 
> You've changed the subject.  Your objections here jump ahead to point
> 3, the policy question about compatibility/security tradeoffs.  The
> sole issue under point 1 is whether Daniel's assessment of high threat
> level with no real benefits is correct.

Scroll up.  I already said no.  Also reference Daniel's email late today
where he comes up with a plan that might solve his and my issues at the
same time.


> I expect and want you to be in the policy argument, but to do it
> right.  Confusing these different kinds of issues is not doing it
> right.

Well, right back at you.

> > No.  The commit was all the communication I needed to know something
> > had gone horribley wrong.  
> 
> Evidently it wasn't, because you mis-identified the breaking commit.
> You thought it was my TESTFRAME removal, or one of the two immediately
> following.  That's what you told me, and havoc (including the head
> reset) ensued.

Yeah, after I spent hours getting my git back to workings...  I was
gonna let that one slide...

> Let me emphasize that point, not because I want to beat up on you but
> because we need to be clear about what went wrong in order to improve.
> If you had correctly identified the merge commit as the place where
> symmetric-peer behavior changed, I would not have concluded that we
> were in shit so deep that the head reset was required.  Several days
> of scrambling to put the pieces back together in a sane order would
> have been avoided.

Well, right back at you.  Please do not get git so balled up and
we don't both waste time on commits taht no longer exist.


> > Big and grossly intrusive changes need to be made a small step at a
> > time.  And quickly reverted when fixable issues come tom light.
> > Possibly only in testing branches.  
> 
> Generally agreed, but there comes a point where the big merge has to
> happen.  The team didn't handle that well.  Daniel screwed up, you
> screwed up, I screwed up.  We need to do better next time.

+1

> > Many facts not in evidence.  And ignoring facts in evidence.  
> 
> I'm listening, when you're ready to produce them.

Read the discussion Daniel and I had this afternoon.  New proposal
we both want to work on is agreed.

> > This is NOT an all or nothing decision.  There are other ways to 
> > mitigate this problem that do not involve major silent breakage.  
> 
> What "this problem" are you referring to? If it's what to do about
> symmetric peer mode, maybe you're right.  But now, under point 3,
> that's over-focusing on the point problem.

"this problem" is when I do a "git pull", reinstall, and most of
my NTP hosts go down...

> What I want to hear from you is what criteria you want us to use
> for making security vs. compatibility tradeoffs in general.  You
> don't like my criterion; that's OK, but if we're going to reach
> a theory we can all live with, you need to put yours on the table.

Not time go shear that yack.  We have a current mess to fix.

> You can use a proposed disposition of peer mode to illustrate
> your more general criteria, but the discussion won't advance
> much if you stop there.

Easy, when we work on it together, we can usually find a mutually
agreeable solution.  I'll not spend time on hypotheticals about
hypotheticals when git head is broken and there is a good plan to fix
it.  

Someday, when we really do have an all or none issue, and we have rael
agree facts, then we cn discuss the real implications of that.  I'll
bet that does not happen in the next year or more.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161006/05a5d6d1/attachment.bin>


More information about the devel mailing list