Re: [gpsd-dev] Moving ntpd to an open VCS

[Harlan Stenn]

Dave Taht writes:
> On Tue, Oct 22, 2013 at 9:17 PM, Eric S. Raymond <address@hidden> wrote:
> > Harlan Stenn <address@hidden>:
> >> I would be happy to see the released NTP codebase be available under
> >> more than just BK.  But it *must* be more than just bk and git, and I
> >> must have committed sysadmin help for the non-bk repos.  I will not
> >> allow them to bitrot in case of problems and I do not have the spare
> >> cycles to admin those.
> 
> I don't think I understand "must be more than just bk and git".

In the past when I looked at supporting both bk and git, the git folks
were so ... frothing in their desire to get the codebase in NTP so they
could then do things to poison or break the bk instance that it was
clear that doing anything where they thought their tactics were working
was akin to "negotiating with terrorists".

> >> I have used git and I am not thrilled with it.  From what I have seen,
> >> git is a versioned filesystem.  That's not quite the same as an SCM.  I
> >> do not have the spare cycles to rehash or re-examine other SCMs right now.
> 
> I agree that git has won. And there are zillions of useful tools and
> services using it now. Even the fcc uses git....

Fine,  but that's not my point.  bk is a *very* comfortable glove for
me.  I have a whack of trigger scripts that do exactly what I need for
rbuild and releng.  It works the way I expect an SCM to work, and does
the things I expect an SCM to do.  My team and I get *awesome* support
from bk.

git does not behave as I expect, and I spend a lot of time looking up
how to do things that I have to do rarely.  I have not gotten anywhere
near the level of support from either the git-friendly folks on my team
or from the git community when I've had questions.

If you see a win/win here somewhere, please point it out to me.  I look
for one a lot, and haven't seen anything.

> > 3. Your claim that there is a clear and obvious case for keeping
> > security patches private is not generally accepted by the open-source
> > community.
> 
> Um, er, I think there is a strong community that favors keeping a security
> tree/patches private for as long as needed to fully test, make ready a
> fix, and cycle a new version to the field.
> 
> I note that all the current generation scms (git/bzr/mercural/etc)
> make it very easy to keep private branches like that. Companies like
> github make their living from the necessity to occasionally have a
> shared private branch.
> 
> Companies like isc do contract work first in a private branch.
> 
> It is not, I'll admit, a particularly successful model for new
> development, but it does aid in creating security related patches.

What you write above is exactly my point.

> > I'm not going to argue the merits here because my personal
> > views are not very relevant; what matters is the social fact that most
> > open source developers are fans of prompt full disclosure, or at most
> > a very short timeout.
> 
> NTP is a core network-facing service. It arguably is as common as dns,
> perhaps more so on some platforms.  As such it is potentially subject
> to attacks on a grand scale, and caution is indicated for making ready
> and distributing new releases. Worse many machines running ntp are
> old, unmaintained machines, that do not get much attention or updates
> over their lifetime.
> 
> A hole in NTPD granting root privilege would be devastating across the
> internet.

Thank you - my points exactly.

> > The minority that partially agrees with you will
> 
> count me among that minority!
> 
> > not save you on any of these other issues.
> 
> true.

We all hope this will not transpire.  And reality is biting in other ways.

> > 4. Your plan of "offering read-only access under an NDA to development
> > repos" will be highly toxic to a community that generally considers
> > NDAs to be the moral equivalent of nerve gas. This one is a
> > showstopper, a crash landing, war to the knife.  You'd have an easier
> > time feeding pork to Muslims.
> 
> I tend to view ntp as a rather stable service basically in maintenance
> mode. I have no idea what new features would require NDAs... nor do I
> know of a way to get new features paid for.  What new features are on
> the table?

Features include better integration with PTP, protocol changes, hardware
timestamping, the new general timestamp API, pluggable filter and
selection algorithms, and some other things I'm forgetting.

The NDA has a twofold purpose.  One is because of security issues.  The
other is that if compaines see a value in getting early access to
development code and they are willing to pay for that, it's a revenue
stream.  This "benefit" is something that can easily be provided to
appropriate folks.  But if these poeple then publish the development
code and break that confidentiality, it damages the revenue stream and
causes other problems.  If individuals want to become developers, they
can submit patches, get approved as committers, and get R/W access to
the development branches.  If commercial or opensource institutions
want access to development repos they can get them too.  But I'm not
sure why they should get *write* access to those repos if they are not
otherwise qualified as committers.

> What bothers me is that inferior versions of ntp (take the busybox
> version for example) have huge amounts of penetration due to their
> comparative simplicity.

The new sntp code is pretty simple.  If folks want a stripped-down ntpd
that's easy to configure, too.  If we can separate the current code into
an ntpd and a clockd that's great.

As for "inferiority", if it gives folks what they need who am I to
judge?

If it is actively screwing foks over, that's a different story.

> > 5. Source developed in parallel in two or more distinct repos?
> 
> Generally there needs to be a repo format that is "core" and a patch
> format that is acceptible. I don't know to what degree a core
> maintainer working in bitkeeper today could take patches generated by
> a downstream git user... but I suspect it would be ugly.

No idea.  But I'd be happy to find out if somebody wanted to send me
some patches from a git repo.

> one of my main projects (openwrt) is partially maintained in svn, and
> there is a regular svn to git pull that happens. I work out of git
> because of how easy it is to have a private repo, and while using the
> svn-git conversion is useful for those that mostly read patches, but:
> whenever I bother to submit one, going from git to svn back to git
> again inevitably requires reverting the local patch, which is a pita.

I use openwrt too, but I haven't used the repo versions for a while.

I do not really understand why folks still use subversion.

> > Unless
> > there's automatic commit propagation among them, this is going to make
> > hackers question your competence (and possibly your sanity).  Which
> > wouldn't be an insuperable problem by itself.  But when you're also
> > bucking the open-source crowd on what it considers core ethical and
> > best-practice issues, the exposure you can least afford is looking
> > incompetent.  That's like blood in the water to sharks...
> 
> ntp's culture goes way, way, way back.

It took me *years* to get DLM to even agree to an SCM, and the one
condition he insisted on was that it be invisible to him.

When I finally got fed up with CVS I spent a a few more *years* looking
at all of the alternatives at the time, and it was clear that BK was the
very best choice at the time, and bk still beats everything I've seen on
a technical basis.  If one is flat-out opposed to any commercial
software git is probably the best of the alternatives, but that doesn't
mean it's the best.

> > You might be able to buck community sentiment on *one* of these (2
> > would probably be the least difficult) and still recruit enough talent
> > from us to keep your codebase in good shape.  Well, on any one except
> > 4; that one is, like, grabbing for the third rail.  But all five?  No
> > chance. None at all.
> 
> NTP has "survived" for years on its existing development model. There
> is no viable replacement, and not a lot of interest  in a generation
> that thinks python and javascript can be used for everything.
> 
> *I* would certainly like a better ntp: bad chimers automagically
> kicked out,

They are, from the "pool" list.  Or am I missing something?
 
> a sane set of statistics on one way delay measurements,

Please say more about this.  We could do a lot if we could
better-measure one-way delay.

> good hooks to pps/gps/lte and other sources of reliable time,

Still working on that, and improvements can clearly be made.

> and sanely configurable crypto...

Yes, and the crypto stuff is really tricky, on several fronts.  And
people disagree on what to use it for, and the models in-place were
designed a long time ago, for problems that may not still be valid.

> but I'll argue it would require a seriously prolific, caring, new
> generation of coders overwhelming the previous one with patches to
> change the backend scm and long established development practices.

The NTP codebase is coming up on 30 years' deployment.  In that time
there have been 5 CERT advisories against the codebase.  It's *visible*
on over 7M machines on the internet.  There are way more machines than
that  running ntpd; most of them are behind routers and firewalls.

I did the math, and last year there were in excess of 1 trillion
operational hours for NTP.  It might actually be more than an order of
magnitude greater than that.

Yeah, I'm careful about how things are done with the codebase.

H