Re: Surprise found while reading the code

[Mark Atwood]

Were the two drivers different?

On Tue, Jun 21, 2016 at 6:33 AM Eric S. Raymond  wrote:

> Refclock 38 (the Hopf 6021 serial driver) was redundant with a mode of
> refclock 8, the parse drive, that also supports the 6021.
>
> I also removed the Hopf 6039 refclock due to a proprietary-driver
> dependency.
>
> This takes us just over 60% of the NTP Classic code removed.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Surprise found while reading the code

[Mark Atwood]

Cool.

I need to fill in my ignorance about the parse driver, and prompt a
discussion about which other drivers can be superseded by additions to the
parse driver.

..m

On Fri, Jun 24, 2016 at 9:42 PM Eric S. Raymond  wrote:

> Mark Atwood :
> > Were the two drivers different?
>
> Not in any significant way I could see.  They parsed the same packet
> format.
>
> I think the second one landed as a unit with the Hopf PCI driver and the
> duplication was simply not noticed.  It wouldn't have been hard to miss;
> the parse driver has 24 different submodes of which Hopf 6021 is just one.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Use of pool servers reveals unacceptable crash rate in async DNS

[Mark Atwood]

Is getaddrinfo_a() in RTEMS?  QNX?   BSD?

On Sun, Jun 26, 2016 at 7:06 AM Eric S. Raymond  wrote:

> Eric S. Raymond :
> > > What would you do if we discovered a case where we wanted it?
> >
> > Cry a lot.  Then add logic to force synchronous DNS when memlocking is
> > selected, and document this as a workaround for a bug we haven't fixed
> yet.
>
> Ugh.  Our options have just narrowed.  I've just seen
>
> libgcc_s.so.1 must be installed for pthread_cancel to work
> Aborted (core dumped)
>
> with memlock off in the build.
>
> I think the homebrew async-lookup code has to go.  Even if we installed
> the warmup fix, I don't think I'd trust it.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Fwd: New Defects reported by Coverity Scan for ntpsec

[Mark Atwood]

- Original message -
From: scan-ad...@coverity.com
Subject: New Defects reported by Coverity Scan for ntpsec
Date: Sat, 25 Jun 2016 20:01:41 -0700


Hi,

Please find the latest report on new defect(s) introduced to ntpsec
found with Coverity Scan.

3 new defect(s) introduced to ntpsec found with Coverity Scan.
3 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 3 of 3 defect(s)


** CID 149750:  Uninitialized variables  (UNINIT)
/ntpd/ntp_intercept.c: 855 in intercept_replay()



*** CID 149750:  Uninitialized variables  (UNINIT)
/ntpd/ntp_intercept.c: 855 in intercept_replay()
849  * machine but by an initial association setup. No
way to check it,
850  * so skip it.
851  */
852 continue;
853 else if (strncmp(linebuf, "receive ", 8) == 0)
854 {
>>> CID 149750:  Uninitialized variables  (UNINIT)
>>> Declaring variable "rbuf" without initializer.
855 struct recvbuf rbuf;
856 struct pkt *pkt;
857 char recvbuf[BUFSIZ], srcbuf[BUFSIZ],
pktbuf[BUFSIZ], macbuf[BUFSIZ];
858 
859 if (sscanf(linebuf, "receive %x %s %s %s %s",
860&rbuf.cast_flags, recvbuf, srcbuf,
pktbuf, macbuf) != 5)

** CID 149749:(UNINIT)
/ntpq/ntpq-subs.c: 1751 in doprintpeers()
/ntpq/ntpq-subs.c: 1794 in doprintpeers()



*** CID 149749:(UNINIT)
/ntpq/ntpq-subs.c: 1751 in doprintpeers()
1745type = 'M';
1746else
1747type = 'B';
1748break;
1749 
1750case MODE_CLIENT:
>>> CID 149749:(UNINIT)
>>> Using uninitialized value "displayname".
1751if (displayname[0])
1752type = 'l'; /* local refclock*/
1753else if (SOCK_UNSPEC(&srcadr))
1754type = 'p'; /* pool */
1755else if (IS_MCAST(&srcadr))
1756type = 'a'; /* manycastclient */
/ntpq/ntpq-subs.c: 1794 in doprintpeers()
1788else
1789serverlocal = currenthost;
1790}
1791fprintf(fp, "%-*s ", (int)maxhostlen,
serverlocal);
1792}
1793if (AF_UNSPEC == af || AF(&srcadr) == af) {
>>> CID 149749:(UNINIT)
>>> Using uninitialized value "displayname".
1794if (displayname[0])
1795strlcpy(clock_name, displayname,
sizeof(clock_name));
1796else if (!have_srchost)
1797strlcpy(clock_name, nntohost(&srcadr),
1798sizeof(clock_name));
1799if (wideremote && 15 < strlen(clock_name))

** CID 149748:  Null pointer dereferences  (NULL_RETURNS)
/ntpd/refclock_jjy.c: 2374 in jjy_receive_seiko_tsys_tdc_300()



*** CID 149748:  Null pointer dereferences  (NULL_RETURNS)
/ntpd/refclock_jjy.c: 2374 in jjy_receive_seiko_tsys_tdc_300()
2368/* Uncertainty date guard */
2369return JJY_RECEIVE_WAIT ;
2370}
2371 
2372time( &now ) ;
2373pTime = localtime_r( &now, &tmbuf ) ;
>>> CID 149748:  Null pointer dereferences  (NULL_RETURNS)
>>> Dereferencing a null pointer "pTime".
2374up->year  = pTime->tm_year ;
2375up->month = pTime->tm_mon + 1 ;
2376up->day   = pTime->tm_mday ;
2377 
2378break ;
2379 



To view the defects in Coverity Scan visit,
https://scan.coverity.com/projects/ntpsec?tab=overview

To manage Coverity Scan email notifications for "m...@mark.atwood.name",
click
https://scan.coverity.com/subscriptions/edit?email=me%40mark.atwood.name&token=efedd5a9ff0a68cbe12873791e5829af
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Technical strategy and performance

[Mark Atwood]

Thank you Eric.  Have read, am pondering, and welcome other people to weigh
in.

..m

On Tue, Jun 28, 2016 at 8:30 PM Eric S. Raymond  wrote:

> In recent discussion of the removal of memlock, Hal Murray said
> "Consider ntpd running on an old system that is mostly lightly loaded
> and doesn't have a lot of memory."
>
> By doing this, he caused me to realize that I have not been explicit
> about some of the assumptions behind my technical strategy.  I'm now
> going to try to remedy that.  This should have one of three results:
>
> (a) We all develop a meeting of of the minds.
>
> (b) Somebody gives me technical reasons to change those assumptions.
>
> (c) Mark tells me there are political/marketing reasons to change them.
>
> So here goes...
>
> One of the very first decisions we made early last year was to code to a
> modern API - full POSIX and C99. This was only partly a move for ensuring
> portability; mainly I wanted a principled reason (one we could give
> potential
> users and allies) for ditching all the cruft in the codebase from the
> big-iron
> era.
>
> Even then I had clearly in mind the idea that the most effective
> attack we could make on the security and assurance problem was to
> ditch as much weight as possible.  Hence the project motto: "Perfection
> is achieved, not when there is nothing more to add, but when there is
> nothing left to take away."
>
> There is certainly a sense in which my ignorance of the codebase and
> application domain forced this approach on me.  What else *could* I
> have done but prune and refactor, using software-engineering skills
> relatively independent of the problem domain, until I understood enough
> to do something else?
>
> And note that we really only reached "understood enough" last week
> when I did magic-number elimination and the new refclock directive.
> It took a year because *it took a year!*.  (My failure to deliver
> TESTFRAME so far has to be understood as trying for too much in the
> absence of sufficient acquired knowledge.)
>
> But I also had from the beginning reasons for believing, or at least
> betting, that the most drastic possible reduction in attack surface
> would have been the right path to better security even if the state of
> my knowledge had allowed alternatives. C. A. R. Hoare: "There are two
> ways of constructing a software design: One way is to make it so
> simple that there are obviously no deficiencies, and the other way is
> to make it so complicated that there are no obvious deficiencies.
>
> So, simplify simplify simplify and cut cut cut...
>
> I went all-in on this strategy.  Thus the constant code excisions over
> the last year and the relative lack of attention to NTP Classic bug
> reports. I did so knowing that there were these associated risks: (1)
> I'd cut something I shouldn't, actual function that a lot of potential
> customers really needed, or (2) the code had intrinsic flaws that would
> make it impossible to secure even with as much reduction in attack surface
> and internal complexity as I could engineer, or (3) my skills and intuition
> simply weren't up to the job of cutting everything that needed to be cut
> without causing horrible, subtle breakage in the process.
>
> (OK, I didn't actually worry that much about 3 compared to 1 and 2 - I
> know how good I am. But any prudent person would have to give it a
> nonzero probability. I figured Case 1 was probably manageable with good
> version-control practice.  Case 2 was the one that made me lose some
> sleep.)
>
> This bet could have failed.  It could have been the a priori *right*
> bet on the odds and still failed because the Dread God Finagle
> pissed in our soup. The success of the project at its declared
> objectives was riding on it. And for most of the last year that was a
> constant worry in the back of my mind.  *What if I was wrong?* What I
> was like the drunk in that old joke, looking for his keys under the
> streetlamp when he's dropped then two darkened streets over because
> "Offisher, this is where I can see".
>
> It didn't really help with that worry that I didn't know *anyone* I
> was sure I'd give better odds at succeeding at this strategy than
> me. Keith Packard, maybe.  Poul Henning-Kemp, maybe, if he'd give up
> timed for the effort, which he wouldn't. Recently I learned that Steve
> Summit might have been a good bet. But some problems are just too
> hard, and this codebase was *gnarly*.  Might be any of us would have
> failed.
>
> And then...and then, earlier this year, CVEs started issuing that we
> dodged because I had cut out their freaking attack surface before we
> knew there was a bug!  This actually became a regular thing, with the
> percentage of dodged bullets increasing over time.
>
> Personally, this came as a vast and unutterable relief. But,
> entertaining narrative hooks aside, this was reality rewarding my
> primary strategy for the project.
>
> So, when I make technical decisions about how to fix problems, one of
>

Re: Technical strategy and performance

[Mark Atwood]

this is was discussed heavily in cii meetings.   will expand later.  on my
phone

On Wed, Jun 29, 2016, 12:03 PM Hal Murray  wrote:

>
> fallenpega...@gmail.com said:
> > Thank you Eric.  Have read, am pondering, and welcome other people to
> weigh
> > in.
>
> The big picture question that comes to mind is why did we start by forking
> ntp classic?  Why not start from scratch?  Did anybody consider chrony?
> What
> other options are/were there?
>
> Where would I look to find a crisp statement of the goals of the project?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Add usestats to collect resource usage statistics

[Mark Atwood]

Cool! Thank you Hal.

On Fri, Jul 1, 2016 at 9:53 PM Hal Murray  wrote:

> I just pushed the code.
>
> You will get things like this:
>
> 57570 76638.360 3600 19.221 29.499 1541 0 0 0 2984 288288 2123 0 8428
> 57570 80238.357 3600 20.812 25.956 1062 0 0 0 3024 246608 2274 0 12652
> 57570 83838.357 3600 23.353 26.497 833 0 0 0 2992 255329 2556 0 16164
> 57571 1038.358 3600 31.154 31.335 1027 0 0 0 3088 310802 2393 0 20280
> 57571 4638.357 3600 31.467 28.972 859 0 0 0 3120 266748 2469 0 23676
> 57571 8238.357 3600 43.700 38.214 1525 0 0 0 2976 369410 3247 0 29748
> 57571 11838.357 3600 35.270 24.945 644 0 0 0 3112 226024 3155 0 32384
> 57571 15438.357 3600 46.356 29.400 1439 0 0 0 2856 278092 1971 0 37928
>
> The data is from getrusage().
>
> The last column is the high water mark for the "resident set size" in
> kilobytes.  If anybody figures out exactly what that means, please clue me
> in.
>
> The above is from a pool server setup with the mrulist limit big enough to
> hold a whole day.  It's still ramping up.
>
> The floating point numbers are user and system CPU usage.  The last line
> shows a total usage of 2.104%.
>
> One of the 0s is page faults.
>
> More into in ./host/docs/monopt.html
> or docs/includes/mon-commands.txt
>
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: CII Best Practices Badging Process - NTPsec

[Mark Atwood]

Hello Caeley and David,
 
Thank you for your offer to help the NTPsec Project improve our CII
Badge score.
 
Yes, we would appreciate your help.
 
As you may know, the NTPsec Project's website is at http://ntpsec.org/
and contains links to the project documentation, and links to our GitLab
org account and git repos at https://gitlab.com/groups/NTPsec
 
Please do check out the project, and let us know your suggestions at
improving our score.
 
Also, do please keep CC devel@ntpsec.org on all emails about this, so we
can maintain a public record and maintain full community participation.
 
..m
 
--
Mark Atwood
Project Manager pro tem, The NTPsec Project
 
 
 
 
 
On Thu, Jul 14, 2016, at 12:36, Looney, Caeley M (UNC) wrote:
> Good Afternoon!
>
> I work with David Wheeler at IDA on the CII Badging Process, and I
> noticed that NTPsec is making great progress towards getting its
> badge.  I have been working to help other projects fill in their
> criteria and help further their progress status, and I’m reaching out
> to you to see if you’d like me to review your project and help fill in
> the application where necessary as well.  Please let me know when you
> have the chance and I look forward to hearing back!
>
>
> Thanks,
> Caeley Looney
 
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Removing the worst cruft

[Mark Atwood]

Re IRIG being "primary time source in high end audio and video work"

You are kidding me.  SIgh.

Can you expand on that for me please?

..m

On Sat, Jul 23, 2016 at 5:42 PM Gary E. Miller  wrote:

> Yo Eric!
>
> On Sat, 23 Jul 2016 15:32:56 -0400 (EDT)
> e...@thyrsus.com (Eric S. Raymond) wrote:
>
> > But AUSTRON/IRIG/CHU...I think there's a good (though not absolutely
> > dispositive) case for simply dropping them all.
>
> I'll give you two out of three.  I think IRIG is a really important
> one.  It is the primary time source in high end audio and video
> work.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Removing the worst cruft

[Mark Atwood]

I know that IRIG is still live, but...  is this particular application
feeding the IRIG into a NTPD?

On Sat, Jul 23, 2016 at 7:44 PM Gary E. Miller  wrote:

> Yo Mark!
>
> On Sun, 24 Jul 2016 01:30:05 +0000
> Mark Atwood  wrote:
>
> > Re IRIG being "primary time source in high end audio and video work"
> >
> > You are kidding me.  SIgh.
>
> Sadly, not.
>
> > Can you expand on that for me please?
>
> My son does a lot of robotics, and some of the robots he works on
> are now doing high end work holding high speed cameras filming TV
> commercials and movies.  NDA prevents me from saying the clients and
> technically I should not even know.  But you would know some of them
> very well.
>
> Prolly by Xmas time you will be seeing some amazing new photography
> styles.
>
> The audio, video and robotic equipment is all syncronized to IRIG
> time.  This becomes very important when you get up to 1,000 frame
> a second stuff.
>
> I was also very surprised that IRIG was alive and well in this niche.
>
> I propsoed to them using NTP to sync the robots to the IRIG signal, but
> for now they are slaving the robot on an IRIG time sync box, and running
> everything else synce on IRIG.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Removing the worst cruft

[Mark Atwood]

I'm going to think hard here.

Eric, dont pull IRIG out just yet.

What I am wishing for, would be for someone to write a standalone in its
own demon process IRIG driver, that then speaks GPSD or SHM to NTPsec.
But testing such a beast would be specialized task.

..m

On Sat, Jul 23, 2016 at 8:07 PM Gary E. Miller  wrote:

> Yo Mark!
>
> On Sun, 24 Jul 2016 02:52:00 +
> Mark Atwood  wrote:
>
> > I know that IRIG is still live, but...  is this particular application
> > feeding the IRIG into a NTPD?
>
> Not yet, but that was what I quoted.  I believe it is done at other
> places.
>
> Here is a commmercial IRIG to NTTP converter:
>
> http://www.buenoptic.net/gps-time-servers/item/330-irig-b-to-ntp-converter
>
> And another:
>
> http://www.ese-web.com/irig.htm
>
> Maybe too small a niche for NTP to care about, but not as small a niche
> as LORAN receivers.  I have a LORAN here cheap if anyone want to try
> thatt. :-)
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Removing the worst cruft

[Mark Atwood]

the fact that it was an obsolete sound card was itself reason to kill it.
leave it killed, and fossilized in the git history.

enjoy your vacation, eric.

..m

On Sun, Jul 24, 2016, 4:36 AM Eric S. Raymond  wrote:

> Gary E. Miller :
> > > Yes.  But there's still the issue that the IRIG driver I removed was
> > > designed to handle analog input via an obsolete class of sound card.
> >
> > Yeah, a driver that does that should be shot.  Just don't count out
> > IRIG as a source.
>
> Right. If we were ever to decide we have a requirement to take in IRIG, we
> would have to *write a new driver*.  The presence or absence of the old
> driver *would not change this*; there are multiple reasons it is
> *disqualified* for use in the scenario you described.
>
> Sigh...next time something like this comes up, please try to avoid causing
> unnecessary panic. Especially the day before I go on vacation.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Removing the worst cruft

[Mark Atwood]

Can the palisade/trimble driver be replaced with a parse driver?

On Sun, Jul 31, 2016 at 4:23 PM Eric S. Raymond  wrote:

> Hal Murray :
> >
> > e...@thyrsus.com said:
> > > Drivers that very well might fail the ten-year test: truetime,
> magnavox,
> > > palisade, oncore, jupiter.
> >
> > Palisade is in use.  It covers Trimble TSIP which includes the
> Thunderbolt
> > which was widely available surplus only a few years ago and is popular
> with
> > time-nuts.  It should probably be renamed to Trimble.
> >
> > There are several sub-drivers/modes to cover different Trimble models
> which
> > use different subsets of the full TSIP protocol.
> >
> > There is also some TSIP code in the generic/parse driver.
> >
> >
> > The oncore driver covers Motorola which is/was very common.  They put
> out a
> > long sequence of chips.  Many of them are way old, but probably don't add
> > much to the driver.  The M12/M12+ was popular and state of the art only
> a few
> > years ago.
> >
> > Motorola sold off their GPS business.  I forget who bought it.  Somebody
> in
> > Asia.  It may have been sold again.  I think the M12+ is still in
> production
> > but the name may have changed and/or they may have updated it again.
>
> Noted.  I'll take these of the list.
>
> I had been thinking about renaming "palisade" to "trimble" if we concluded
> that it's still live.  To be done when I'm back from the second half of my
> vacation.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Removing the worst cruft

[Mark Atwood]

Good point.

On Sun, Jul 31, 2016, 8:13 PM Eric S. Raymond  wrote:

> Hal Murray :
> > > Can the palisade/trimble driver be replaced with a parse driver?
> >
> > I doubt it, but I'm far from familiar with the parse driver.
> >
> > Based on Eric's previous comments, the parse driver handles devices that
> > provide the time in an easy to parse format.  TSIP might fit that if all
> goes
> > well.
> >
> > But there are many variations of TSIP.  One covers reversing the normal
> PPS
> > operation.  Instead of needing kernel support to time stamp the PPS
> pulse,
> > you send it a pulse by flapping one of the modem control signals and it
> tells
> > you the time that happened.
> >
> > My vote would be to not rock that boat.  There are more important things
> to
> > work on.
>
> I concur with this.
>
> While I like the idea of replacing as many as possible of the
> remaining legacy drives with modes of the generic driver, an absolute
> requirement for this is that we be able to live-test with the equipment.
> Obviously we're not set up for that yet.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘drift file

[Mark Atwood]

If we make this change, framing it as "it's how chronyd has been doing it
for the past N years" makes it a much easier sell.

Especially if we can make the file format the same.

What principled objections would the hardcore time nerds have?   We do have
to keep their needs firmly in mind.

..m

On Mon, Aug 1, 2016 at 7:40 PM Gary E. Miller  wrote:

> Yo All!
>
> Eric asked me to write up why I thought the chrony drift file handling
> is better than NTPsec's handling.
>
> 1.  On startup chronyd checks the time stamp on the drift file.
> if the timestamp > sysclock, the sysclock is set to the timestamp
>
> This is a nice sanity check on the system clock.
>
> 2.  ntpd stores the frequency ppm offset in the driftfile.
> chronyd stores the frequency ppm offset and the 'skew' (estimated
> accuracy
> of the existing frequency value).
>
> Knowing the 'skew' at startup allows chrony to better reject bad
> reclock input.
>
> I can see that saving the 'skew' is a nice touch, but I suspect much the
> good chronyd startup behavior is explained elsewhere.
>
> In a related topic, it would be nice (maybe an option) for ntpd to hold
> off logging the initial aweful data until after the -g option has
> set the system clock.  And a bit longer, so the wonky startup data is
> masked.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Discussion about PR: WIP: Snapify ntpsec

[Mark Atwood]

This looks great, Christian.

Is there anything we need to do to have our buildbot system test it?

..m

On Tue, Aug 9, 2016 at 8:10 AM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

> Hi,
> I wanted to give the ML a ping as well about this, so that not only the
> Pull Request is existing.
> Eventually one here might chime in as well.
>
> There is a prototype to snap ntpsec at
> https://gitlab.com/NTPsec/ntpsec/merge_requests/49
>
> I'll quote my PR text here and hope for a great discussion:
>
> "Hi, on one hand I worked on packaging ntp (classic) recently and on the
> other hand I worked a bit with snapcraft (=> http://snapcraft.io/). I
> really think ntpsec would be a perfect candidate to exploit snap packaging.
>
> Please consider this an RFC for now - following the spirit of NTPsec
> contribution policy "Before starting significant work, please propose it
> and discuss it first" I'll also write to the ML linking to this branch. But
> also did I not just want to mention snapcraft and run away - instead I
> thought to provide a prototype that can be tested, but discuss motivation,
> tech and details before doing some more heavy lifting work.
>
> My current example is meant for a daily build, but this can easily be
> changed to whatever you prefer. Snapcraft could - for example - build from
> a stable branch of your tree automatically or whatever else you want.
>
> Benefits of exploiting snap(craft) in ntpsec (in my opinion):
>
>- for security it is often important to be able to push fixes fast to
>consumers, snaps are great for that as it somewhat cut's out the
>distributions as a gatekeeper of a release process
>- ntpsec isn't packaged in distributions yet, an upload to the
>snapstore would make you instantly available on multiple distributions
>- faster development iteration cycles, which is especially useful for
>new (or newly forked) projects
>- and of course all the benefits listed at http://snapcraft.io/
>
> Limitations:
>
>- this doesn't use any of the great snap isolation features yet (still
>using --devmode to get the prototype fast). Implementing those will need a
>few new interfaces and that effort should be spent after the discussion
>(but on the good side, you haven't lost anything - just not gained all of
>the snap isolation features yet).
>- currently there is no snapcraft plugin for waf, so I provided one
>(but I also started to push it to snapcraft already so it can be dropped
>from ntpsec in a bit)
>
> I'm looking forward and hope that the security improvements of ntpsec and
> those of snap's for packaging will one day stack up to be even better
> together. Let's discuss.
>
> Kind Regards Christian
>
> P.S. FYI - I'm soon going to vaction - so please don't wonder if there is
> kind of no-response between 13th and 23rd August. OTOH this gives everyone
> more time to play and experiment with it."
>
>
>
> --
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Next point release

[Mark Atwood]

It is time for another point release.

I've received enough private communications from people who are
successfuilly running lab machines on tip, and people who are successfully
running lab machines on the previous point release, and that my work with
the CII is illuminating the need for proof of motion, that I have decided
to make another point release.

I understand the objection that we do not yet have a formalized release
criteria system, nor do we yet have a formalized checklist or automated
release process.  As nobody wise is yet running us in load production, that
is not yet an issue.

This point release will not have Daniel's state machine patch merged in,
because it is a minor risk I don't want to take for the point release just
yet.


Other than that, everyone please chime in:
Daniel
Eric
Amar
Hal
everyone else?

Please get your low risk bug fixes in in the next couple of days.

Unless there is a credible stop reason, I will issue the tag this coming
Tuesday morning.

Thank you everyone!

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Using first server to respond, Issue #68

[Mark Atwood]

Start with the warning, while we think of a solution.

Thank you, Hal.

On Thu, Aug 11, 2016 at 4:05 PM Hal Murray  wrote:

>
> I think I have found the problem.
>
> minsane defaults to 1 so ntpd is "happy" as soon as a server gets past the
> individual server filtering.
>
> I don't see any simple fix.  Even if minsane is set (via ntp.conf) to
> something larger, there is still the possibility that a majority of the
> first
> N servers are not the ones you want.
>
> We might be able to work out something based on how many servers you are
> using, but that gets tangled up with how many servers to use and why.  (If
> you haven't been around for a while, that's an endless topic.)
>
> We could add a warning.  Does anybody look at them?  It won't break
> anything,
> so I guess I'll give it a try.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Possible abuse from fetching the leap second file

[Mark Atwood]

The long term, I like the DNS for solutions to this kind of problem.  But,
under what name?

Other solutions are putting it in AWS & Cloudfront, and in their
equivalents at AZR and at GCS.  To take that route, I would want to arrange
that Amazon, Microsoft, and Google donate that capacity.   The those 3
cloud CDNs could handle that load.  But, that will take negotation time,
and programming time we don't have right now.

An even faster to implement solution would be to put it in github.com.   We
could do that today, and it would cost us nothing, and github on their
backend smoothly pours very high demand raw pages into the the assorted
worldwide cloud providers and into the CDNs. Plus it versions the data, and
they have wellknown TLS certs.

Let's do that!  Hal, others, do you happen to have copies of all the past
leap files, so we can synthesize a git history for it?

..m



On Sun, Aug 14, 2016 at 3:49 PM Hal Murray  wrote:

> Matt Selsky is working on Pythonizing the script that grabs a new leap
> second
> file.  The idea is to run a cron job that keeps it up to date.  That opens
> an
> interesting can of worms.
>
> As a general rule, you shouldn't use a resource on a system that you don't
> own without permission from the owner.  Informed consent might be a better
> term.  A system open to occasional  downloads by a human might not be
> willing
> to support automated fetches from many many systems.
>
> This case is doubly nasty in two ways.
>
> First, the load will normally be light but then go up sharply 60 days
> before
> the file expires.  (The doc mentions a crontab, but I can't find
> specifics.)
> That could easily turn into a DDoS.
>
> Second, the URL from NIST is unreliable[1] and the IEFT clone is out of
> date.
>  It's not obvious that NIST is expecting to support non US clients or that
> either NIST or IEFT is prepared to support high volumes of automated
> fetches.
>
> The clean solution is for us to provide the server(s), or at least the DNS
> so
> we can provide the servers tomorrow.  That commits us to long term support,
> but since we have control of everything we can fix it if something goes
> wrong.
>
> Does anybody know how many downloads/hour a cloud server can suppor?  I'm
> interested in this simple case, just downloading a small file, no fancy
> database processing.  Are there special web server packages designed for
> this
> case?
>
> How many clients are we expecting to run this code?
>
> Another approach might be to get the time zone people to distribute the
> leap
> second file too.  That seems to get updated often enough.
>
> -
>
> 1] The current URL is ftp://time.nist.gov/pub/leap-seconds.list
> DNS for time.nist.gov is setup for time, not ftp.  It rotates through all
> their public NTP servers and many of them don't support ftp.
>
>
> Matt:  The current code has an option to restart ntpd.  The current ntpd
> will
> check for a new leap file on SIGHUP but that will kill ntp-classic.
>
> Please see if you can find a simple way to spread the load.  We can reduce
> the load on the servers by a factor of 30 if you can spread that out over a
> month.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Possible abuse from fetching the leap second file

[Mark Atwood]

On Mon, Aug 15, 2016 at 8:14 AM Eric S. Raymond  wrote:

> We don't need all the past leap files. The data is only ever modified by
> appending a line.
>
>
I'm a crazy competitionist.  Git resources need histories.

OTOH, it looks like the eggert/tz repo already exists. On the other other
hand, it doesn't look like it's got the historical history.

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: stats directory is gone - now, how is logfile pruning done?

[Mark Atwood]

I have no overrule on this point.  Pray continue.

And welcome back, Hal.

On Thu, Aug 18, 2016 at 8:01 PM Eric S. Raymond  wrote:

> Heads up, Mark!  Policy sanity check requested.
>
> Hal Murray :
> >
> > e...@thyrsus.com said:
> > > This does, however, leave me with a question: How are we doing pruning
> of
> > > statfiles at this point?  I seem to recall someone who is not me
> working on
> > > this.  The facility, whatever it is, needs to be documented.
> >
> > Whatever you do, make sure it's easy to get the no-prune option.
> >
> > I suspect that's going to be a distro option and whatever you do will
> just be
> > an example.  Most people won't care about how well their clock is
> working as
> > long at it works well enough so they don't have to pay any attention to
> it.
> >
> > Debian sets things up so that /etc/cron.daily/ntp
> > compresses things and only keeps the last week.
> > I don't know why they did it that way rather than letting logrotate do
> it.
>
> OK, you've told me the important thing: the NTP suite is not historically
> expected to do statfile pruning itself.
>
> That's fine, then.  My decision: We won't try taking the job over from
> the distros - I'm quite happy to let this be somebody else's problem.
>
> OTOH. if someone pushes a well-documented and neatly-packaged solution
> upstream to us (like, say, a logrotate recipe) we'll keep it in etc/
> as an option for distro packagers.
>
> If Mark has any larger-context reason to overrule this it won't bother
> me any.  But I doubt he will.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Removing traps feature

[Mark Atwood]

Ok.  Thank you Hal and Eric.

Eric, remove the existing traps code from NTPsec.

We will build a snmp subagent later, when we see user need..

..m



On Thu, Sep 8, 2016 at 4:23 AM Eric S. Raymond  wrote:

> Hal Murray :
> > I don't know of any reason not to remove it, especially if it is broken.
> >
> > I think we need a plan to support SNMP if anybody gets interested.  I
> assume
> > we will do that with some translation code running as a separate job.
>
> Agreed.  I think this can and should be accomplished by plugging together
> three components:
>
> (1) the Mode 6 Python client code I wrote to replace ntpq with.
>
> (2) The Python SNMP library
>
> (3) The Python socketserver library
>
> I don't think this will be difficult - I'd actually be surprised if a
> basic SNMP daemon made from these pieces runs much over 100 LOC and
> I'm pretty sure I could write and test it in a day.  Data flow: when
> you access an SNMP resource at the daemon, this gets translated to a
> Mode 6 query, with the response updating the MIB and posted back to
> your SNMP client.
>
> > I assume we will want traps.  We could either do that by polling at some
> TBD
> > rate, or by re-implementing a trap feature that the translation job
> could use.
> >
> > Traps are slightly ugly.  We probably don't want to process them when
> they
> > happen due to opportunities for traps within traps and such.  I think it
> > would work to set a flag and process traps later similar to the way we
> > process flags from signals.
>
> There's an SNMP trap feature.  I could speculate further but I don't think
> there's much point to doing so before we have evidence of some user demand.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Can we assume SIGQUIT and friends are defined?

[Mark Atwood]

make sure they are defined by the posix level we are targeting

On Mon, Sep 12, 2016, 4:01 PM Eric S. Raymond  wrote:

> Hal Murray :
> >
> > Our current code has ifdefs for SIGQUIT and several others.  That may
> have
> > been leftover from Windows.
> >
> > man 7 signal says:
> >First the signals described in the original POSIX.1-1990 standard.
> >
> >
> > Can we remove those ifdefs?  If not, what environment are we considering
> that
> > doesn't have them?
>
> Good point.  I think they can go.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTPsec's longer-term objectives

[Mark Atwood]

we are not making Rust part of NTPsec right now.  but maybe in a year or
so, at this pace

On Mon, Sep 12, 2016, 12:54 PM Hal Murray  wrote:

>
> e...@thyrsus.com said:
> > Every Unix-like system, for sure.  Checking...Rust has a Windows port. So
> > does Go.  Are there any other tarhets you're worried about?
>
> Mostly just curious.  I've never used either.
>
> I see go on FreeBSD and NetBSD.  I see rust on FreeBSD but not on NetBSD.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTPsec's longer-term objectives

[Mark Atwood]

Go has a GC. the Go standard library and the complier implementation will
always be utterly controlled by Google, and will be full of Google magic.
Go's usecase is to solve Google's problems, and can basically be modelled
as "compiled Python that forcefully avoids all of the kinds of typos that
Dr Pike got annoyed with typing for the past 30 years". It may make sense
to rewrite reposurgeon in Go, to break out of Python's performance
bottlenecks.

Rust is "C with sane types and sane scoping and sane string handling and
sane threading, with a focus on zero runtime cost abstractions".  If
someone was to write security critical internet facing daemons from
scratch, Rust would probably be the right choice.

..m

On Tue, Sep 13, 2016 at 12:35 AM Sanjeev Gupta  wrote:

>

>
> On Mon, Sep 12, 2016 at 8:14 PM, Eric S. Raymond  wrote:

>>

>> While this is in some ways a tempting thought, I think the energy we
>> might spend on this would be better directed towards a newer language
>> that *is* suitable for soft realtime and has good provability properties
>> for security.  Rust or Go seem like the obvious candidates.
>
>
> /me rushes to reserve the GoNTPGo.com domain name.
>
> Now to squat till Mark and pals make me an offer.
>
> --
> Sanjeev Gupta
> +65 98551208 http://www.linkedin.com/in/ghane
> ___
> devel mailing list
> devel@ntpsec.org 
> http://lists.ntpsec.org/mailman/listinfo/devel

___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTPsec release checklist

[Mark Atwood]

Hi!

I have added a draft of the release checklist to devel/hacking.txt

Please look it over, and give feedback.
My next rev of it will include the actually command line commands..

Thank you!

..m


> -Original Message-
> From: Eric S. Raymond [mailto:e...@thyrsus.com]
> Sent: Tuesday, September 27, 2016 2:02 PM
> To: Atwood, Mark 
> Cc: Hal Murray 
> Subject: Re: Release checklist
>
> Hal Murray :
> >
> > e...@thyrsus.com said:
> > > I think that's the right answer. I'll do the move to the website and
> > > start on a release checklist.
> >
> > I've been working on a checklist for a while.  I was hoping Mark would
> > send some details, but that hasn't happend.  Here is my list:
> >
> > Pre-Release:
> >   Check issues
> >   Send warning message
> >   wait N days
> >
> >   Run tests:
> > Check parser
> > Various configurations
> >
> > Release:
> >   bump VERSION: edit, commit, push
> >   Add tag, commit(?), push
> >   bump VERSION: edit, commit, push
> >
> >   make tarball
> >
> >   send release message
> >
> > - Send a PGP signed mail to the list when you make a release that
> >   includes the sha256sum
> > - You put that sha256sum also on the ftp dir
> > - You also sign the the released files with pgp
> >
> >
> > 
> >
> > Things like updating a list of known-good systems only make sense if
> > there is sufficient advanced warning.
>
> Mark, how close is this to what you do on release?  I think we should
> document our procedure, especially the cryptographic measures to ensure
> source integrity, well before 1.0. This is an assurance to potential users.
>
> The only item we can probably strike is build testing.  Jason Azze has
> buildbots doing that continuously.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Forward-planning towards release 1.0

[Mark Atwood]

we need to be packaged for debian, rasbian, ubuntu, gentoo, redhat, and
suse for 1.0 and be working towards getting into their distribution system
(apt, yum, etc)

On Wed, Oct 5, 2016, 6:27 AM Eric S. Raymond  wrote:

> Heads up, Mark!  Possible strategy and external-relations issues.
>
> I think we're no longer very far, technically, from being ready to
> ship a 1.0 release.  This note is to outline what needs to be done,
> suggest a rough timeframe, and lay out a couple of scenarios.
>
> What brought 1.0 over the horizon was successfully landing Daniel's
> protocol-machine refactoring.  There are a couple of rough spots
> yet - peer mode is busted, MS-SNTP needs to be re-implemented, and
> we need to make some decisions about broadcast and anycast modes -
> but there's also no reason to expect that cleanup to take very long.
>
> I polished off about a third of the GitLab tracker bugs today; there
> are just 20 issues left on the tracker, all pretty routine-looking
> stuff.  I think these can be done between and around major tasks.
>
> Here's what I think we ought to do next:
>
> * Fix symmetric-peer mode and MS-SNTP, definitely.
>
> * Drop broadcast client mode, wich Daniel rightly notes is
>   fundamentally impossible to secure
>
> * Fix broadcast server mode, because Mark says a lot of Windows client
>   users rely on it, but add a strong warning that it's a bad idea and
>   users should transition out ASAP.
>
> I don't understand "anycast" well enough to have a strong opinion.
> Does anyone else? Is there any field evidence of use?
>
> If we want to ship 1.0 fast, the right thing to do go into soft code
> freeze after the cleanup, test for a some time, and ship.  We could, I
> think, reasonably expect to ship late October or early November.
> Let's call this "Case Red".
>
> If we're in less of a hurry, the next logical point to freeze is after
> landing the new restriction language.  If we split this up logically,
> with me writing the config grammar and Daniel the internal primitive(s)
> for the
> rules tables and evaluation, this isn't a big job either, nor one
> paricularly difficult to test. I'd say another three weeks should
> do it easily. Let's call this "Case Green".
>
> If we're not in a hurry at all, then the *next* logical target is
> moving ntpq all the way to Python. Not a really difficult job, but
> a largish and somewhat messy one.  I'm going to say four weeks.
> Let's call that "Case Blue".
>
> Case Blue would leave us ready to ship 1.0 right around the end of the
> year.
>
> Which should we aim for? Have I missed anything serious? Discuss...
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> Everything you know is wrong.  But some of it is a useful first
> approximation.
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Forward-planning towards release 1.0

[Mark Atwood]

I want to have a conversation with our new funding sources about their
expectations, as i ponder Case Nightmare Red/Green/Blue

On Wed, Oct 5, 2016, 10:08 AM Eric S. Raymond  wrote:

> Mark Atwood :
> > we need to be packaged for debian, rasbian, ubuntu, gentoo, redhat, and
> > suse for 1.0 and be working towards getting into their distribution
> system
> > (apt, yum, etc)
>
> Yes, we do.
>
> That doesn't imply a choice among Cases Red/Green/Blue, though.  Do you
> have an opinion or judgment about that?
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Proposal - drop the GPSD JSON driver

[Mark Atwood]

Hi!

I've been following this discussion.

We should remove the GPSD JSON driver from NTPsec.

It is an attractive nuisance.  The SHM driver, possibly with improvements,
is a better interface between NTPsec and GPSD.

..m

On Thu, Oct 20, 2016 at 2:53 PM Eric S. Raymond  wrote:

> Hal Murray :
> >
> > e...@thyrsus.com said:
> > >> Yes, I've been thinking about mechanisms for this.  They're all rather
> > >> irrelevant.
> > > Argh.  I meant "inelegant".
> >
> > I assume that using a pipe or socket rather than SHM would fix that.
>
> Probably, but then we run unto buffering jitter again.
>
> You're right, we need to build some test jigs and measure this stuff.
>
> I'll make a publishable white paper out of it.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

POLICY: devel@ntpsec.org is the primary channel of developer discussion and coordination

[Mark Atwood]

Hi!

I would like to formalize a policy about development communication, which
can be touch-in-cheek expressed as:

If it wasn't in email, it didn't happen.

It is currently popular and trendy to use a "chat-centric" developer
communication model.  Chat-centric dev does make sense for rapidly changing
devops and webapp environments, where a moderate sized team is constantly
full time working on a large live "agile" project that is constantly
deploying into production.   That's not us, that is not the kind of project
that NTPsec is.

We will continue to operate the existing IRC channel irc://
freenode.net/#ntpsec which is very useful for semi-realtime interaction
with the larger interest commnuity, and for public coordination with two or
more developers are working in sync.

But, again, please continue to consider this email list devel@ntpsec.org to
be the primary channel of developer discussion and coordination.

Thank you!

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Proposal - drop the GPSD JSON driver

[Mark Atwood]

Got it, thanks!

On Fri, Oct 21, 2016, 5:20 PM Gary E. Miller  wrote:

> Yo Mark!
>
> On Fri, 21 Oct 2016 21:00:24 +0000
> Mark Atwood  wrote:
>
> > We should remove the GPSD JSON driver from NTPsec.
>
> I spend 40 minutes last night trying to get the GPSD SHM driver running
> on a RasPi.  I did not get it finished.  The experience reminds me that
> the #48 driver makes all sorts of non-standard assumptions about how
> gpsd is configured.  A configuration that is contorted and non-obvious
> to implement.
>
> I don't even want to begin to discuss the new bag of worms.  So, yes,
> I now agree, kill it off.
>
> Just one thing to remember about the experience, #48 proves that using
> JSON adds no uncertainty to the time measurements and yields identical
> results when fed to ntpd.  Please do not pull the driver until Eric
> sees, and agrees, with that result.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Progress, and a puzzle.

[Mark Atwood]

On Thu, Nov 3, 2016 at 11:54 AM Hal Murray  wrote:

> > One wonders, for example, why exactly one response (readstats) has a
> binary
> > payload
>
> My guess is history.  It's probably left over from before the mode6/mode7
> stuff got sorted out and Mills decided that mode6 should be all text.
>
> You could fix that.  I'd probably wait until there is a good reason to add
> another command.
>

At least for the time being, we want the Python implementation of ntpq to
interop with NTP Classic.  And even if we manage to land a fixing patch on
NTP Classic, we want to be able to interop with older versions of NTP
Classic, at least until all major distros upgrade.

We're going to have to live with mode6 as it exists right now, for a while
yet.


> One of the complicated responses sends the slots within a line in random
> order and adds a garbage field name and value.  The comment said it was to
> keep the client side from making assumptions that would turn into
> constraints
> on the server side.


I've actually done that myself in code I've written in the past, pretty
much for the same reason.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Of possible use for our Python code: "Hypothesis"

[Mark Atwood]

https://hypothesis.readthedocs.io/en/latest/
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ntpq quirk

[Mark Atwood]

On Sun, Nov 27, 2016 at 1:00 AM Achim Gratz  wrote:

> Eric S. Raymond writes:
> > OK, there are two ways we can handle this.
>
> The third way is building a hash table that maps each possible unique
> prefix to the actual full-length command.
>
>
I was on a project years ago that did that (minimal length matching of
command strings).

Someone on team dug up an amazing little utility that ingested a list of
strings, and emitted a human-unreadable table-driven maximally efficient C
function that implemented some computer science magic state machine
character parser that took as a parameter char* and returned a integer or
enum that designated one of the target strings that was minimal matched by
the input.

We then made running this code generator a Makefile production, and
compiled the generator itself as another dependent Makefile production.

I'm struggling now to remember it's name...


...m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Autokey support removed

[Mark Atwood]

Hello Sanjeev,
Feel free to edit them out the docs, and we will review them in pull
requests.
Thank you for all your work!

..m

On Thu, Dec 1, 2016 at 10:42 AM Eric S. Raymond  wrote:

> Sanjeev Gupta :
> > While re-reading docs today, I came across references to asymmetric
> > key crypto; do I understand that these references are incorrect now?
>
> Yes, and they should be edited out.  But the edits will have to be
> carefully
> reviewed.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Google: Announcing OSS-Fuzz: Continuous Fuzzing for Open Source Software

[Mark Atwood]

I am signing up NTPsec.

On Thu, Dec 1, 2016 at 8:13 PM Sanjeev Gupta  wrote:

>
> https://security.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html
>
> ...
> OSS-Fuzz is launching in Beta right now, and will be accepting
> suggestions for candidate open source projects. In order for a project
> to be accepted to OSS-Fuzz, it needs to have a large user base and/or
> be critical to Global IT infrastructure, a general heuristic that we
> are intentionally leaving open to interpretation at this early stage.
> See more details and instructions on how to apply here.
> ...
>
> --
> Sanjeev Gupta
> +65 98551208 <+65%209855%201208> http://www.linkedin.com/in/ghane
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Change default to "restrict default kod limited nomodify nopeer noquery"

[Mark Atwood]

On Sat, Dec 10, 2016 at 11:00 AM Eric S. Raymond  wrote:

>
> Pretty much every distribution in the universe ships a default
> ntp.conf with a restriction sectio that looks like this:
> [...]
> I'm requesting comment on the following behavior change:
> (1) Make these the default restrictions at startup, replacing none at all.
> (2) Retain current behavior if built with --enable-classic-mode.
>

I like it, and learn towards saying yes.  Let's see what Hal and others say.

We may want to emit a log warning if the daemon is ever configured to allow
modify, peer, or query from global.

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Endianness puzzle

[Mark Atwood]

I will see if I can get us a Z/machine target

On Mon, Dec 12, 2016 at 11:53 AM Gary E. Miller  wrote:

> Yo Eric!
>
> On Mon, 12 Dec 2016 14:35:21 -0500
> "Eric S. Raymond"  wrote:
>
> > Gary E. Miller :
> > > I would be nice to have a BIGENDIAN host as a buildbot worker.
> >
> > We don't?  Oh, that's bad.  Put that on your todo list.
>
> AFAIK, ia64 and z/Architecture are the only big endian in common use.
> And I do not know anyone using those.  Also, potentially ARM, but I have
> never seen an LE distro for ARM.
>
> Been a LONG time since I powered up a 68000 or PowerPC.
>
> When I did microcode I learned why LE is the preferred choice.  It just
> codes easier.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ntpmon now has some keystroke commands

[Mark Atwood]

Suggestion:  '?' to display all the keystroke commands.

On Tue, Dec 13, 2016 at 8:00 AM Eric S. Raymond  wrote:

> In response to requests by Hal and Gary, ntpmon now has some keystroke
> commands.
>
> a:: Change peer display to apeers mode, showing association IDs.
>
> n:: Toggle display of hostnames (vs. IP addresses).
>
> o:: Change peer display to opeers mode, showing destination address.
>
> p:: Change peer display to default mode, showing refid
>
> q:: Cleanly terminate the program.
>
> s:: Show all hosts, not just reachable ones.
>
> w:: Toggle wide mode.
>
> x:: Cleanly terminate the program.
>
> I've abolished the command-line options that these make redundant.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> "Government is not reason, it is not eloquence, it is force; like fire, a
> troublesome servant and a fearful master. Never for a moment should it be
> left
> to irresponsible action."
> -- George Washington, in a speech of January 7, 1790
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ntpmon now has some keystroke commands

[Mark Atwood]

I think we are now bikesheding.  Let someone else driveby command aliases
for ntpmon.

Does anyone else have any ideas for any other data displays to add to it?

..m

On Tue, Dec 13, 2016 at 11:36 AM Gary E. Miller  wrote:

> Yo Eric!
>
> On Tue, 13 Dec 2016 14:30:26 -0500
> "Eric S. Raymond"  wrote:
>
> > > Some of the other commands are toggles.  It would be nice if these
> > > were a three way toggle.  I like to just stab one key over and over
> > > and see the data differentlly.  Not sure how that would work.
> > > Maybe a toggles with p and o toggles with p?  Or get rid of a  and
> > > o, keep p, and have p toggle though all three?
> >
> > All that is too much to remember.  I have just made the spacebar
> > rotate through all three modes.
>
> Love it.
>
> > > Hmm, you may want to reconsider that.  I was instead expecting you
> > > to keep those and add a 'one-shot' mode sort of like ntpq.  But not
> > > a big deal...
> >
> > I had it working like that for a while.  The problem is that there is
> > no way to satisfy all three of the following constraints:
> >
> > 1. ntpmon options have the same semantics as corresponding ntpq
> > options 2. option letters are the same as the corresponding command
> > keys 3. commands are natural mnemonics in English
>
> I think that is over thinking it.  But I do see how a one-shot mode may
> make no sense.
>
> > The simplest way to get to a consistent UI design was to remove all
> > command-line options.  Which is a good idea anyway - less to remember,
> > and the command keystrokes cover the functionality.
>
> The simplest yes, but is that best?  I agree with Achim: let the user
> decide.  It is common in unix to alias commands so you get what you
> want easily.  Some people will always want to see the associations first,
> maybe only.  Others will prefer other things.  Unix is all about choice.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: showall - peers display

[Mark Atwood]

If Hal thinks it should go, it should go.   Thank you Hal!

On Mon, Dec 19, 2016 at 4:26 AM Eric S. Raymond  wrote:

> Hal Murray :
> >
> > There is a showall parameter to the worker printout code for the peers
> > display in ntpq and ntpmon.
> >
> > ntpmon has the s keyboard command to toggle it.  ntpq has lpeers and
> > lassociations.
> >
> > Short version: I vote we nuke it - general cruft reduction.
> >
> > Long version:
> >
> > I've never found a good use for it.  I have been confused because peers
> hid
> > info that I was looking for.
> >
> > Nuking it will have subtle changes in the UI.  We can leave the old ntpq
> > commands around as aliases, but I'd vote for removing them.
> >
> > I just set the default in ntpmon to True.
> > I hacked peers and assoc in ntpq to use True which makes them like
> lpeers and
> > lassoc.  There are also lopeers and lpassoc.
>
> In principle, I'm not opposed to this as a de-crufting of the design.
>
> In practice, I wonder if the cleanup buys us more than appearing not
> to care about backwards compatibility costs us.
>
> However, I'm not sure enough this is a problem to revert Hal's change.
> And if he wants to nuke ntpmon's 's' command, I won't stop him.
>
> Hal is taking responsibility for ntpq/ntpmon, therefore he gets the
> authority to make these decisions unless I judge that he is making a
> serious mistake - not a contigency I am ever expecting.
>
> I would like to see other people step up like this (Gary has with
> ntpviz, for which I am also grateful).  It isn't healthy or
> sustainable for me to do as large a percentage of the work and the
> routine decision-making as I have up to now.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

prep for NTPsec 0.9.6 release

[Mark Atwood]

Hi!

Things are looking good for the 0.9.6 release.

Everyone, please update .../NEWS with any significant work and improvements
you have landed.

If you you any reason not to tag and release 0.9.6 in the next few days,
please let us know.

Thank you, everyone!

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Version numbering RFC

[Mark Atwood]

the tags were pushed.  maybe git pull --tags  ?

On Sat, Dec 31, 2016 at 12:25 AM Sanjeev Gupta  wrote:

> On Wed, Dec 28, 2016 at 5:58 PM, Eric S. Raymond  wrote:
>
> My proposal is that we change this before more water has gone under
> the dam.  That is:
>
> 1. VERSION should correspond to the last tag, not tne next one.
>
> 2. It should *not* be bumped when we ship 0.9.6 - that will bring it
>into sync with the new convention.
>
> 3. After 0.9.6, I will add logic to bump the contents of VERSION after
>shipping to devel/release, with --major, --minor, and --point
>options.
>
>
> I can see commit 76e974cf
>
> sanjeev@X201wily:~/SRC/ntpsec$ git show 76e974cf
> commit 76e974cf16da204c6da73d6fa204677d94990088
> Author: Mark Atwood 
> Date:   Fri Dec 30 21:16:45 2016 +
>
> version 0.9.6
>
> Signed-off-by: Mark Atwood 
>
> but
> sanjeev@X201wily:~/SRC/ntpsec$ git describe
> NTPsec_0_9_5_1-547-gb6b2dd0
>
> Is this a missing tag in git?
> --
> Sanjeev Gupta
> +65 98551208 <+65%209855%201208> http://www.linkedin.com/in/ghane
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

RfC: grant gitlab "guest" just for the asking

[Mark Atwood]

Hi!

We've had a couple of cases recently where potential contributors show up
on gitlab.com with a request to join the gitlab project as a developer.

Our preferred way to interact with additional contributors is via gitlab
pull requests.

However, people may be asking to join the gitlab project so they can open
bugs, and because they have been trained by other projects' workflow that
the way you start to participate is to get recognition on of the forge of
record.

GitLab has a ACL level of "guest", described at
https://gitlab.com/help/user/permissions

I think it may be productive to hand out Guest level access just for the
asking, for the sake of growing our community.

Before I dictact that as a new policy, what do the other contributors and
interested people think?

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: RfC: grant gitlab "guest" just for the asking

[Mark Atwood]

Granting someone Guest access does add them to
https://gitlab.com/groups/NTPsec/group_members so it's not just a no-op.

On Tue, Jan 3, 2017 at 11:24 AM Eric S. Raymond  wrote:

> Mark Atwood :
> > I think it may be productive to hand out Guest level access just for the
> > asking, for the sake of growing our community.
> >
> > Before I dictact that as a new policy, what do the other contributors and
> > interested people think?
>
> Not opposed, but Gaery has pointed out that guest permissions seem to be
> available to all on public projects.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

"Why does ntpkeygen pass a low entropy ignored seed into SystemRandom?""

[Mark Atwood]

Hi!

My friend Greg Rubin, who does security work for Amazon, took at quick look
at NTPsec 0.9.6, and asks the following queston:

"Why does ntpkeygen pass a low entropy ignored seed into SystemRandom? It's
ignored, so it doesn't matter, but it's the type of error which concerns
me."

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: pyflakes

[Mark Atwood]

Pyflakes test requirement has been added to .../devel/hacking.txt

On Wed, Jan 4, 2017 at 2:47 PM Hal Murray  wrote:

> > We do not take patches that fail pyflakes.
>
> If that's the policy, it should be announced and documented.
>
> Are there other similar policies?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: NTPsec leap second experience

[Mark Atwood]

Thank you Achim

On Wed, Jan 4, 2017 at 11:53 AM Achim Gratz  wrote:

>
> I've kept to rasPi running through the leap second.
>
> The first was following the PTB servers as a stratum2 and monitoring
> both a DCF77 and a GPS (via USB).  This one correctly announced the leap
> second and kept the time.
>
> The second one was configured as a stratum1 (via GPS w/ PPS) and
> monitoring the PTB servers for reference.  Since apparently Jessie has
> not been updated with the correct leap second file (it still doesn't
> recognize the leap second as a valid datum), the GPS got marked as a
> falseticker when the leapsecond arrived and the NTP loop opened.  I've
> arrived back home almost two days later to restart NTP.  I keep that
> system at a temperature that has close to zero TC (I'm not regulating
> the temperature yet, but it seems that should be possible) and during my
> absence the room temperature was also quite stable.  Accordingly the
> clock had only drifted a little bit less than 1ms (I recorded all PPS
> time stamps).  It probably would have drifted even less if there hadn't
> been a GPS burp shortly before the leap second and the loop hadn't
> stabilised to the correct offset again.
>
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: pyflakes

[Mark Atwood]

> what is pep8?

https://pypi.python.org/pypi/pep8

pep8 is a tool to check your Python code against most of the style and
formatting conventions in "PEP 8"

A "PEP" is a "Python Enhancement Proposal". Think of it as an "RFC" in the
Python Community. PEP 8 is a specification of a "best practices" formatting
and style guide for Python code, and is documented at

https://www.python.org/dev/peps/pep-0008/

..m

On Wed, Jan 4, 2017 at 3:39 PM Hal Murray  wrote:

>
> g...@rellim.com said:
> > All of the current code passes pyflakes, and pep8.  With a few documented
> > exceptions.
>
> What is pep8?
>
> Fedora ships a pyflakes package so I don't have to work very hard to figure
> out where to get it and what it does.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

uncrustify

[Mark Atwood]

On Wed, Jan 4, 2017 at 4:50 PM Daniel Poirot  wrote:

> Uncrustify is both useful and has a clever name!


Running  uncrustify against NTPsec is good idea, but it needs to be a flag
day, because it will be a huge patch.

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: uncrustify

[Mark Atwood]

Did Dr Mills have a preferred C style?  If he did, was it not terrible?

What is everyone else's preferred C indent style?

I have my own favorite, but I'm not the one who has to read and rework the
C code.

..m

On Thu, Jan 5, 2017 at 11:18 AM Daniel Poirot  wrote:

> Before long, everyone will be using a virtual machine with an
> integrated editor and common development system!
>
> ...oh, wait, that's what started all this:
> https://en.wikipedia.org/wiki/Lisp_machine
>
>
>
> On Thu, Jan 5, 2017 at 12:54 PM, Eric S. Raymond  wrote:
> > Hal Murray :
> >>
> >> >> Running  uncrustify against NTPsec is good idea, but it needs to
> >> >> be a flag day, because it will be a huge patch.
> >>
> >> > ...pretty much a 'fork' from which there is no recovery...
> >>
> >> Is that a serious problem?  If so, why?
> >>
> >> It would mean that I couldn't (usefully) diff versions of a file that
> crossed
> >> the flag day, but I don't think I do that very often.  I'm more likely
> to let
> >> git diff version X and X-1 and if we trust uncrustify I won't be doing
> that
> >> for X being the flag day.
> >
> > I concur with Hal's doubt that this is a serious problem.  I don't find
> myself
> > doing diffs with very old versions often.  If I did, diff -b (ignoring
> > whitespace) would probably mitigate a lot of them.
> >
> > I've installed uncrustify.  I'll do some experoments.
> > --
> > http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: uncrustify

[Mark Atwood]

I'm not going to dictat my own style just because it's my style.  But I
will veto tab characters, and 8 space tab stops, for all the reasons.

ANSI, modified K&R, OTBS, linux kernel style, uncrustify default, they are
all good to me.

..m

On Thu, Jan 5, 2017 at 11:58 AM Gary E. Miller  wrote:

> Yo Mark!
>
> On Thu, 05 Jan 2017 19:32:55 +
> Mark Atwood  wrote:
>
> > What is everyone else's preferred C indent style?
>
> I'm stuck in the past, with s slightly modified K&R style.
>
> > I have my own favorite, but I'm not the one who has to read and
> > rework the C code.
>
> I find any consistent style works for me.  The default uncrustify
> setting look OK to me, except I'd also like to limit lines to < 80
> chars.
>
> RGDS Veritas liberabit vos
> GARY Quid est veritas?
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Fwd: Your blog post "Getting past C"

[Mark Atwood]

Interesting. He makes good points, and I have earned a living coding in
Ada, myself. But all that said, there are sufficient good reasons not to
port to Ada. Well, unless and until the DOD, the ARPA, or the
Physikalisch-Technische Bundesanstalt want to pay us enough to do it, at
which point it can be revisited.


-- Forwarded message -
From: 
Date: Thu, Jan 5, 2017 at 1:05 AM
Subject: Your blog post "Getting past C"

Dear Mr. Raymond,

a German IT news website recently had a news item about your blog post
"Getting past C". I would like to comment on that. But before doind that I
would like to provide some background of my interest in NTP.

I am working at Physikalisch-Technische Bundesanstalt which is the national
metrology institute of Germany, much like the NIST for the USA. One of our
legal tasks is to provide the official time for the country, which of
course involves NTP. Recently the requirements for reliable time signal got
even tighter due to the increasing use of smart electricity meters. I am
tasked with working on the institute's information security management
system which involves the integrity and availability of our time service.

But I am not writing on behalf of my employer, I merely want to express my
personal opinion. My programming experience is rather limited, I only did a
few rather small projects for measurement systems, mostly using graphical
programming. My first language was Pascal, later I acquired minor C and
Perl experience.
I totally understand your motivation for writing that blog post. Most of
the CVEs result from absolutely unnecessary mistakes during programming. On
the other hand: Why should the programmer have to care about checking every
data that should be written into a variable? Why aren't these check
implemented automatically? Humans tend to forget things and to make
mistakes, and obviously the are not well-suited to take care of every
detail. The motivation is clear: Use a language that does not allow such
mistakes. In doing so, you can be the one who started it, and in ten years
we might have much safer and more reliable core services for the internet.

All is wel up to the point where you present your options: Go and Rust.
What, that it? Two very young languages that -for the outsider- seem to be
under heavy development? You forgot the most natural choice of all: Ada.
This language is well-established for high safety and high reliability
applications like the aerospace industry. It is standardised (last revision
was in 2012), the reference manual is available online and there are free
software tools and compilers. Ada even features concurrency, object
orientation, exception handling and an interface to C. Furthermore several
studdies suggest that the total lifetime cost is lower and projects are
finished fasterand with less bugs when using Ada .

Although I would like to see Ada being used for internet core services, I
am well aware that it might not be the best choice. But it would be a grave
mistake to not consider it when thinking about programming languages with
built-in safety. That is my request to you: Consider more languages than
just Go and Rust, and try to choose wisely, even when that means to rewrite
the whole NTP code. You can set an example for future choices. We urgently
need a much higher level of integrity, security and safety in the software
that drives our lives.

With best regards,
Thomas Scheller


procedure Signatur is
begin
-- Themenbeauftragter Informationssicherheit
-- Präsidialer Stab
-- Physikalisch-Technische Bundesanstalt
-- Bundesallee 100
-- 38116 Braunschweig
-- Telefon: +49 531 592 2007 <+49%20531%205922007>
-- Telefax: +49 531 592 69 2007 <+49%20531%20592692007>
-- E-Mail: thomas.schel...@ptb.de
-- Website: https://www.ptb.de/
null;
end Signatur;


smime.p7s
Description: Binary data
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

RFC: uncrustify vs clang-format

[Mark Atwood]

While I was reading up on uncrustify, opensource.com posted an article
about clang-format.

https://opensource.com/article/17/1/coding-style

Does anyone have any comments or experience comparing them?

I will probably spend the time to play with both of them, and run diffs of
the output of each.

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Comments on Replacing C

[Mark Atwood]

On Sun, Jan 8, 2017 at 4:47 PM Gary E. Miller  wrote:

>
> Yes, threads will help a lot.  I remember when Apache and Mysql started
> to use good threading.  It really helps when you can use all 16 cores
> on a CPU instead of just one.
>

MySQL is not something I would hold up as an example of good threading.
I've been down in that code.  It's lock constipated, and never was good for
more than 4 cores until very recently.

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Comments on Replacing C

[Mark Atwood]

On Sun, Jan 8, 2017 at 6:47 PM Gary E. Miller  wrote:

>
> I think not.  Most of the threads will be servering clients.  All a
> thread needs to serve a client is the incoming packet and the current
> local time.  No locks needed for that.
>
> The client threads will prolly need some locking, but I doubt anyone
> has more than 40 refclocks or peers.
>
> The big win os for NTp servers with hundreds of clients.
>

That is the concurrency pattern that Erlang was designed for and wins at.

I am not recommending that we port NTPsec to Erlang, because the pool of
available Erlang programmers with time to contribute is too low.

However, if I was a telco, spending a man-year or two writing an open
source NTP server in Erlang as a lab project, and then upstreaming it into
the various telco grade ecosystems would be a good idea.

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: RFC: uncrustify vs clang-format

[Mark Atwood]

I think that the difference between uncrustify and clang-formatter is that
clang-formatter actually uses the clang parser, so it should be able to
injest any valid C.

But, it will be an interesting experiment.

..m

On Fri, Jan 13, 2017 at 9:09 AM Eric S. Raymond  wrote:

> Mark Atwood :
> > While I was reading up on uncrustify, opensource.com posted an article
> > about clang-format.
>
> Note that clang-format style is not a single thing; the tool takes
> parameters.
>
> I looked at the Wikipedia article on "Indent style".  There are more
> perversities out there than were dreamt of in my philosophy!
>
> I prefer what it calls Allman style. I could live with any of the 1TBS
> variants.  I mildly dislike Whitesmiths and Ratliff, somewhat more
> strongly dislike GNU, and don't want us going anywhere near Horstmann,
> Pico, or "Lisp" styles.
>
> But, as I said, I generally adapt to whatever style I find in place in
> a C codebase and don't try to impose my preferences.
>
> The most unusual trait of Mills style is exemplified by this function
> header:
>
> static void
> clock_update(
> struct peer *peer   /* peer structure pointer */
> )
> {
>
> I've never seen this way of laying out formal argument lists anywhere else.
> If we apply a formatter, we're going to have to first check what it does
> to these.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

the MSNTP feature and author, Andrew Bartlett

[Mark Atwood]

I just spent an hour talking with Andrew Bartlett of Catalyist.  He is the
author of the msntp feature in NTP Classic.

The feature is actually in place for Samba clients.   Given that, we likely
will want to put it back, but do it better than how it was originally
hammered into Classic.

He hope will be joining us on the mailing list and in the IRC channel when
he can soon, to talk about the feature.

He also has suggested we look at the Samba test framework for inspiration
for testing NTPsec.

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Rust vs. Go post is up

[Mark Atwood]

If you want a randomly different thing to relaxation hack on with Go,
instead of an IRC server, consider a Matrix.ORG server.   A Matrix.org
server that is binary and performant actually has a good chance of
significant uptake.   But, your choice, your project.

Thank you for your work, Eric.  I had high hopes for Rust.  I think that
extremely high learning curve for the languages is even more of a killer
for us than swarm/crate/roadmap issue.

..m

On Wed, Jan 18, 2017 at 12:06 PM Eric S. Raymond  wrote:

> My experiment with parallel prototyping of an IRC server in Rust and
> Go is done.  Go won by a mile.
>
> https://blog.ntpsec.org/2017/01/18/rust-vs-go.html
>
> I will probably continue working on the Go code as a relaxation hack,
> but I'm going to refocus on NTPsec now.  I see some good work got done
> while I was elsewhere.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> After a shooting spree, they always want to take the guns away from the
> people who didn't do it.-- William S. Burroughs
> Conservatism is the blind and fear-filled worship of dead radicals.
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: sockaddr_storage

[Mark Atwood]

I prefer :: tagged IPv6 addresses for IPv4 addresses.   No need for a
redundant flag.

On Mon, Jan 23, 2017 at 12:48 PM Gary E. Miller  wrote:

> Yo Hal!
>
> On Sun, 22 Jan 2017 20:10:36 -0800
> Hal Murray  wrote:
>
> > All the MRU list needs is a flag to specify if the IP address
> > is 4 or 6, the address, and the port number.
>
> Or just use IPv4 addresses mapped into IPv6.  From wikipedia:
>
> https://en.wikipedia.org/wiki/IPv6_address
>
> You place the prefix an IPv4 address with :::
>
> 192.0.2.128 becomes :::c000:0280 also written as :::192.0.2.128
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: The state of NTPsec as I see it

[Mark Atwood]

There is still the threaded DNS lookup bug that Hal discovered, and his
proposed new threaded DNS design.

On Mon, Jan 23, 2017 at 2:11 PM Eric S. Raymond  wrote:

> Gary E. Miller :
> > > 3. The JSON refclock is a mess that has never worked quite right,
> > > without a clear purpose in life. I'd prefer to drop it, unless
> > > somebody steps up to fix it.
> >
> > I could be wildly wrong, but I think that some systems like
> > MacOS do not support shared memory, required for SHM().  The
> > JSON driver is way to get PPS+gpsd+ntpd running on MacOS.  And
> > other OS that also fail to have /dev/shm.
> >
> > If I were to fix it, I would rip out almost all the options and
> > drop it back to basics.  Then get it working on MacOS at a minimum.
> >
> > If that works for you, it should probably get a new name and driver
> > number to avoid confustion.
>
> There aren't any driver numbers any more.  OK, I fib slightly; there's
> a table deep in the guts of ntpd that gets indexed by the driver number
> when you use the old refclock syntax.  This is for backwards
> compatibiility,
> otherwise they're gone.
>
> OK, strip it and fix it.  We'll worry about the namespace issue once
> we know what you had to throw overboard.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Current status of --enable-crypto

[Mark Atwood]

If we are going to have an SSL dependency, I have a pretty strong
preference towards WolfSSL

if we are going to have an OpenSSL dependency, it needs to be to the latest
stable OpenSSL release.

What would be using an SSL library for, that libsodium does not already
provide?

What all are we using libsodium right now for?

..m


On Fri, Jan 27, 2017 at 8:05 AM Eric S. Raymond  wrote:

> Eric S. Raymond :
> > Daniel Franke :
> > > If SHA-0 has ever been used in NTP that's news to me. It was broken
> pretty
> > > quickly after publication and never saw much use. Pretty sure any
> > > documentation which refers to it is confused.
> >
> > There were repeated references to "SHA and SHA-1".  I don't see how that
> > could reasonablt disambiguate to anything but "SHA and SHA-1".
>
> Er, of course, I meant "to SHA-0 and SHA-1".
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Crypto tangle

[Mark Atwood]

Can libsodium upstream take a pull request that adds the hash functions
that we need?

On Fri, Jan 27, 2017 at 7:40 AM Eric S. Raymond  wrote:

> Hal Murray :
> > We currently have 2 and 1/4 crypto packages.  That seems like the sort of
> > things you like to clean up.
>
> Yes.
>
> > I would have said we have 2 1/2, but somebody deleted half of the 1/2.  I
> > assume that was part of the --enable-crypto cleanup.  There used to be
> > routines in libisc for MD5 and SHA1.  md5.c is gone, but sha1.c is still
> > there.  There are also 2 header files in libisc/include/isc/: md5.h and
> sha1.h
>
> md5.c isn't gone, it's in libntp.c.  It's clearly the ISC code, so somebody
> moved it there.  Might have been me, though I do not remember doing this.
>
> > We need sodium and OpenSSL.  I don't know much about either, but 2 seems
> like
> > the wrong number.  Do we really need both?  If so, why?  I think we
> should
> > have a paragraph someplace explaining why etc.
>
> It depends on which MAC algorithms we want to support, a question I've
> opened
> in a recent email.  It looks like libsodium's support for hash functions in
> our set is limited to SHA-2, so libsodium can't replace OpenSSL.
>
> > We also need pointers to the documentation.  I think I'd vote for a web
> page
> > on our main web site with links to documentation for C99, POSIX, and all
> the
> > packages we need.
>
> I am *strongly* against creating a separate web page for this.  I like
> a single point of truth, and I write all our internal docs (including
> INSTALL) in asciidoc exactly so they can be rendered to HTML and exposed
> on the website when we deem it useful.
>
> Therefore, no, not a separate web page.  Instead, I request that the
> infrastructure crew provide us with a facility to expose, as HTML on
> the website, selected asciidoc pages that are *not* under docs/.
>
> Then, INSTALL can be first on that list.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Hash function support, MD5 / SHA256, strawman proposal

[Mark Atwood]

How hard would the following be?

Just go ahead and add SHA256 to NTPsec
then
Write an I-D modifying the NTP4 protocol documenting it.
then
Write a patch to NTP classic for it.  (yes, I know, icky code)

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Hash function support, MD5 / SHA256, strawman proposal

[Mark Atwood]

Ok, thanks for the update.

..m

On Fri, Jan 27, 2017 at 10:38 AM Daniel Franke  wrote:

> Sharon and Aanchal are already working on a better proposal and have
> an I-D for it. The new MAC function for legacy authentication
> ("legacy" as opposed to NTS) is going to be AES-CMAC.
>
> On 1/27/17, Mark Atwood  wrote:
> > How hard would the following be?
> >
> > Just go ahead and add SHA256 to NTPsec
> > then
> > Write an I-D modifying the NTP4 protocol documenting it.
> > then
> > Write a patch to NTP classic for it.  (yes, I know, icky code)
> >
> > ..m
> >
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Current status of --enable-crypto

[Mark Atwood]

WolfSSL has a "we are compatible with any OSI approved license" codecil to
their license.  I can get a formal signed commitment and document from the
CEO reinforcing it.

We do need to get wacking on the weeds on removing more of this thicket.

..m



On Fri, Jan 27, 2017 at 10:38 AM Gary E. Miller  wrote:

> Yo Mark!
>
> On Fri, 27 Jan 2017 18:14:15 +
> Mark Atwood  wrote:
>
> > If we are going to have an SSL dependency, I have a pretty strong
> > preference towards WolfSSL
>
> It may be the best, but it is not in Gentoo.  I suspect few distros have
> it.  As we see from the libsodium mess, using non standard libs is a
> massive increase in difficulty.
>
> > if we are going to have an OpenSSL dependency, it needs to be to the
> > latest stable OpenSSL release.
>
> We gotta support what crap users have.
>
> > What would be using an SSL library for, that libsodium does not
> > already provide?
>
> That really needs an audit.  waf seems to check for a lot of openssl stuff
> that is never used.
>
> My quick check shows md5 and sha1.
>
> And even though --enable-crypto is gone, there are still a lot of
> #ifdef HAVE_OPENSSL around.
>
> > What all are we using libsodium right now for?
>
> We use libsodium to read /dev/random, or whatever equivalanet the OS
> has.  libsodium does not support md5 or sha1.
>
> OTOH, openssl does have RAND_bytes().  Why do we not use that, and get rid
> of libsodium?  Most projects consider it good enough.
>
> And, don't forget, libisc is still in the tree with its own copies of
> md5 and sha1.  Nuke it!
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Crypto tangle

[Mark Atwood]

Ah, now I get it.  They do support new good stuff, they don't support old
bad stuff.

Daniel, are you suggesting we want to use OpenSSL instead of inline C of
md5 and sha1 to take advantage of optimized asm and accellerated
implementations?

..m

On Fri, Jan 27, 2017 at 10:43 AM Gary E. Miller  wrote:

> Yo Mark!
>
> On Fri, 27 Jan 2017 18:17:40 +
> Mark Atwood  wrote:
>
> > Can libsodium upstream take a pull request that adds the hash
> > functions that we need?
>
> My understanding is that they considered md5 and sha1 too dangerous to
> use and would not be complicit with anyone doing do.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Current status of --enable-crypto

[Mark Atwood]

OpenSSL is not going to drop them anytime soon.  if/when they do, we can
add back inline support in better understood ways.

Daniel, if we make OpenSSL a requirement, can we drop libsodium?

Daniel, which rev of OpenSSL should we require?  (Not 0.9.x et al)

If/when we encounter a target without OpenSSL, we can add the complexity
back, but for now, we keep paring away.)

..m

On Fri, Jan 27, 2017 at 12:23 PM Daniel Franke  wrote:

> Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1
> support any time soon? That's inconceivable to me.
>
> On Jan 27, 2017 3:21 PM, "Eric S. Raymond"  wrote:
>
> Mark Atwood :
> > We do need to get wacking on the weeds on removing more of this thicket.
>
> Here are our constraints:
>
> * Daniel has stated that he prefers the OpenSSL implementations of MD5 and
>   SHA-1. He's our crypto expert, so he gets to make that call and I would
>   have no grounds to even argue with it.
>
> * We have beem warned that these might be removed from OpenSSL in the
>   unspecified future.
>
> * libsodium does not carry MD5 and SHA-1, and won't for the same reason
>   that they might be removed
>
> Therefore, here are our options:
>
> 1. Make OpenSSL a required library and remove the local MD5/SHA-1.  Daniel
> gets
>his optimizations, I get to remove code, and all is happy unless the axe
>falls and MD5/SHA-1 are removed from OpenSSL.
>
> 2. Do nothing.  OpenSSL remains optional and we're covered against OpenSSL
>yanking those festures.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: sockaddr_storage

[Mark Atwood]

I like the idea of removing more IPv4 specific code.

If we do, can we still get arrival timestamp from the kernel?

How do standard display functions display v6 mapped v4 addresses?   How do
we want them displayed?

Are there any places left in the code that are storing addresses in
packed-4-octets or ints?

..m

On Fri, Jan 27, 2017 at 12:16 PM Gary E. Miller  wrote:

> Yo Eric!
>
> On Fri, 27 Jan 2017 15:01:19 -0500
> "Eric S. Raymond"  wrote:
>
> > Gary E. Miller :
> > > Yes, but NTP does not have to.  NTP can just open an IPv6 socket and
> > > shove all IPv6 and IPv4 in through that socket.  Apache does this,
> > > sendmail does this, nginx does this, postfix does this.  Very
> > > standard and very easy.
> >
> > That's interesting.  Does this mean we could throw out all
> > IPV4-specific code and use IPV6 logic everywhere?
>
> Yes.
>
> > I didn't think an IPv6 accept() would take incoming IPv4 connections
>
> Yes.
>
> > - is there a way to make it take both?
>
> It does by default, if you only open an IPv6 socket.
>
> Look at 'man 7 ipv6'
>
> Or here: http://man7.org/linux/man-pages/man7/ipv6.7.html
>
> "IPv4 connections can be handled with the v6 API by using the
> v4-mapped-on-v6 address type; thus a program needs to support
> only this API type to support both protocols.  This is handled
> transparently by the address handling functions in the C library."
>
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Hash function support, MD5 / SHA256, strawman proposal

[Mark Atwood]

How stable is their ID?

How much effort will it be to add it to NTPsec?

My next strawman proposal that we add it NTPsec as soon as convenient, but
make it an option for now.

..m

On Fri, Jan 27, 2017 at 10:40 AM Mark Atwood 
wrote:

> Ok, thanks for the update.
>
> ..m
>
> On Fri, Jan 27, 2017 at 10:38 AM Daniel Franke 
> wrote:
>
> Sharon and Aanchal are already working on a better proposal and have
> an I-D for it. The new MAC function for legacy authentication
> ("legacy" as opposed to NTS) is going to be AES-CMAC.
>
> On 1/27/17, Mark Atwood  wrote:
> > How hard would the following be?
> >
> > Just go ahead and add SHA256 to NTPsec
> > then
> > Write an I-D modifying the NTP4 protocol documenting it.
> > then
> > Write a patch to NTP classic for it.  (yes, I know, icky code)
> >
> > ..m
> >
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Hash function support, MD5 / SHA256, strawman proposal

[Mark Atwood]

I think what we will do is implement the new "legacy" auth protocol as soon
as Daniel feels comfortable with it, and implement new new secure time
protocol on, again, as soon as Daniel feels comfortable and then delivers
the code.

Dropping support for the legacy legacy MD5 method is not on our roadmap.
Most likely what we will do is
- make the newer protocols the default
- then later, emit warning messages when MD5 is selected
- then later, making it a --enable-foo compile option

But it will take years.  About the fastest possible path would be a year
for each of those steps.

..m

On Fri, Jan 27, 2017 at 3:26 PM Kurt Roeckx  wrote:

> On Fri, Jan 27, 2017 at 03:00:42PM -0800, Hal Murray wrote:
> >
> > fallenpega...@gmail.com said:
> > > How hard would the following be?
> > > Just go ahead and add SHA256 to NTPsec then Write an I-D modifying the
> NTP4
> > > protocol documenting it. then Write a patch to NTP classic for it.
> > > (yes, I know, icky code)
> >
> > I think you are overlooking how long it takes to update the installed
> base.
>
> Just to compare this with SSL/TLS. SSLv3 exists since 1996. There
> are still webservers on the internet that only speak SSLv2 in the top
> 1 million sites. So if you really care that you can still talk to
> all servers, you would need to support things for over 20 years.
>
> But at a certain point we're willing to break things. No modern
> webbrowser will talk to those servers. And if they want you to
> talk to them, they'll just have to upgrade. And the question
> really becomes how much you're willing to break. And it seems that
> most people don't care about 0.1%.
>
> > CentOS 6.8 and NetBSD 6.1.5 are still shipping ntp 4.2.6p5
> > (I assume they have back ported all the important security patches.)
> > 4.2.8 was released at the end of 2014
>
> I think redhat supports their release for 10 years, so you'll
> probably still get near 10 years that you might see 4.2.6 servers.
>
>
> Kurt
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Copyright dates

[Mark Atwood]

they don't require updating

On Sat, Jan 28, 2017, 5:38 PM Hal Murray  wrote:

>
> Do they need to be updated?  I just noticed one that was 2015.
>
> Should that go on the release checklist?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Recent trends in the codebase size

[Mark Atwood]

Is there a reason to keep dumbclock?   Maybe it exists as a starting
framework for when someone wants to write a new clockdriver?

..m

On Sun, Jan 29, 2017 at 5:36 AM Eric S. Raymond  wrote:

> Here are the full current stats:
>
> all71320 (100.00%) in 298 files
> c  60694 (85.10%) in 152 files
> python  7472 (10.48%) in 48 files
> shell   1444 (2.02%) in 7 files
> yacc1255 (1.76%) in 1 files
> waf  455 (0.64%) in 11 files
>
> We're down to a hair over 26% of the original bulk of C.  The main
> possible place to cut that's left is the ntp_io.c code; removing
> interface scanning and going with one wildcard socket seems likely
> to cut a couple KLOC.  Past that, we're running out of crap to clean
> up unless we decide to drop more obsolete refclocks or Hal is
> able to rewrite the async-DNS code and seriously shrink it.
>
> Accordingly I've recently done a pass through the reclocks. The
> dumbclock driver should probably go - it's an obvious dorm-room stunt
> that doesn't correspond to any production hardware anywhere.
> Otherwise it's hard to see what else to cut without a policy change.
>
> A couple other interesting points:
>
> * The size of the waf recipe has been dropping recently. The crypto
>   cleanup helped with that.  More needs to be done here; it's still
>   overcomplicated and somewhat buggy.
>
> * 10% of the code is now Python.  That's better than I thought we
>   would do in terms of moving from C to a memory-safe language (that
>   is, shy of a rewrite in Go or something). It would be good to
>   increase that further, but this is unlikely; what's left in C either
>   needs to be there for performace reasons (ntpd) or would be
>   difficult to shift out of all proportion to its size(ntptime,
>   ntpfrob, sht).
>
> * Most of the shell code (975 lines) is autorevision.sh.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> Live free or die; death is not the worst of evils.
> -- General George Stark.
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Timings for random

[Mark Atwood]

I wonder if we should just start recommending that people plug one of Keith
Packard's ChaosKey's into a USB port on their NTP boxes.

https://keithp.com/blogs/chaoskey/

I just leave one plugged into my main working NUC all the time.

..m

On Sun, Jan 29, 2017 at 5:15 PM Hal Murray  wrote:

>
> g...@rellim.com said:
> > You can't run out of randomness with RAND_bytes().
>
> Would you please say more.  The man page says:
>
>RAND_bytes() puts num cryptographically strong pseudo-random bytes
> into
>buf. An error occurs if the PRNG has not been seeded with enough
>randomness to ensure an unpredictable byte sequence.
>
> How can I be sure that it has "been seeded with enough"?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Copyright dates

[Mark Atwood]

copyright lengths will always be increased to keep Steamboat Willy under
copyright.

Right now our standard copyright text is "Copyright
$YEAR_YOU_ARE_WRITING_THIS by the NTP Project contributors"

After 50ish years goes by from now-ish, we can revisit.

..m

On Sun, Jan 29, 2017 at 1:02 PM Gary E. Miller  wrote:

> Yo Mark!
>
> On Sun, 29 Jan 2017 07:58:24 +
> Mark Atwood  wrote:
>
> > > Do they need to be updated?  I just noticed one that was 2015.
>
> > they don't require updating
>
> US Copyright is now generally 70 years after the death of the author.
>
> You plan to live that long?
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Recent trends in the codebase size

[Mark Atwood]

Kill it

On Sun, Jan 29, 2017 at 9:05 PM Eric S. Raymond  wrote:

> Mark Atwood :
> > Is there a reason to keep dumbclock?   Maybe it exists as a starting
> > framework for when someone wants to write a new clockdriver?
>
> Actually, I only left dumbclock in because you said "keep it for the lulz"
> during the conversation about some other refclock that we ended up
> dropping.
>
> You've put your finger on the only even weakly persuasive argument for
> keeping it.  But:
>
> 1. If we want a simple model for an old-school refclock, a couple
> others are handy.  The most obvious is refclock_local.c; zyfer and
> spectracom would also be good. In fact the spectracom driver (under
> its old WWVB or "Type 4" name) historically *was* the model for several
> other drivers - it's often cited in header comments.
>
> 2. If it were up to me, nobody would ever write an old-school refclock
> again.  Makes more sense to write a parse template for the generic
> driver.  You get more code re-use that way.
>
> So no, I don't see remaininh value in keeping it.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Recent trends in the codebase size

[Mark Atwood]

My inclination is that when more clock types show up, they get a driver
running in it's own process space, and exporting a SHM buffer.

The problem with covering existing drivers to that is...  testing them.

..m

On Sun, Jan 29, 2017 at 10:49 PM Eric S. Raymond  wrote:

> Hal Murray :
> > It's not clear that there is any good way to have a starting point
> reference.
> >  If you give examples of all the possibilities, it will be too
> complicated.
> > You can start with an existing driver.  That's easy if you already know
> your
> > way around, but there is likely to be a lot of code that you have to skip
> > over.
>
> I agree, this is a real problem.  I have an item on my long-term to-do
> list to rewrite the generic-driver HOWTO so writing parse templates
> becomes easier. And maybe apply some of GPSD's tricks to make a mode
> that tries to autoadapt.
>
> That's kind of blocked on having a device that exercises that driver,
> though.
> I want to know that it actually still works before I put in the effort.
>
> > I won't complain if it goes away.
>
> It's gone.
>
> > > 2. If it were up to me, nobody would ever write an old-school refclock
> > > again.  Makes more sense to write a parse template for the generic
> driver.
> > > You get more code re-use that way.
> >
> > I think that only works for hardware that fits the model.  There is a
> lot of
> > stuff that doesn't.  Could you fit a SHM driver in there?  How about
> > JSON/GPSD?
>
> You're right, of course, and a POSIX-compliant shared-memory driver is
> exactly the exception I should have thought of.
>
> My defense is that I was thinking of actual hardware clocks.  Which do
> seem in general to all be very alike in what they emit.  I'm pretty sure
> that several of the existing srivers (at least spectracom and trutime,
> probably more) do in fact fit the model.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Clocks broken on Mac mini

[Mark Atwood]

Hello Hugh,

No need to be off list, we like to work in public as much as possible.

Yes, please make those connections, and prod your friends on this issue.

..m

On Mon, Jan 30, 2017 at 12:37 AM Hugh Blemings  wrote:

> Hiya,
>
> /me de-lurks
>
> On 30/01/2017 19:28, Eric S. Raymond wrote:
> > Hal Murray :
> >>
> >> e...@thyrsus.com said:
> >>> Well, that's disturbing. But hard to act on until we get a better idea
> >>> what's busted
> >>
> >> Sorry if I wasn't clear.  It's the kernel, not our code.
> >
> > Alas.  Those would have made nifty little test machines othwerwise.
>
> If it would be of help I've a couple of friends who still do
> Linux/PowerPC kernel work, might be able to prod them about a fix at
> least for upstream if we have a simple to demonstrate test case and are
> confident it's in the kernel.
>
> If already in hand or those connections already there that's fine too of
> course - I'm sure among this particular group I'm not the only one with
> friends in kernel-land :)
>
> Hal feel free to email me off-list if preferred to keep chatter down for
> the rest of the folk
>
> Cheers,
> Hugh
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Copyright dates

[Mark Atwood]

That's... complicated.

We don't need to have a notice attached to every file, because there is a
copyright notice attached to the project as a whole, and there is a notice
attached to each repo.  Individual files generally don't each need their
own notice, since individual files generally no longer get "detached" from
a project or tree.

But, if you were to copy in a substantial amount of text from another
source, you should make sure that the copyright from that source is
properly declared, right next to the text pulled in.

Also, however, documentation is a bit unusual in that it is much more
likely to be detached and separately distributed from the rest of the
project.  We should make sure that if the documentation is ever printed
out, or is separately displayed on sites like man7.org, that a copyright
notice should be readable.

..m

On Mon, Jan 30, 2017 at 1:55 AM Hal Murray  wrote:

>
> fallenpega...@gmail.com said:
> > Right now our standard copyright text is "Copyright
> $YEAR_YOU_ARE_WRITING_THI
> > S by the NTP Project contributors"
>
> Should the documentation files have a copyright notice?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Copyright dates

[Mark Atwood]

Commercial FOSS audit tools like Protecode and Blackduck will be able to
recognize the SPDX tags, and the Copyright text.


In our file ntpsec/devel/hacking.txt :

We use the SPDX convention for inclusion by reference.  You can read about
this at

  http://spdx.org/licenses

When you create a new file, mark it as follows (updating the year) as
required:



/* Copyright 2017 by the NTPsec project contributors

 * SPDX-License-Identifier: BSD-2-Clause

 */




For documentation:




// Copyright 2017 by the NTPsec project contributors

// SPDX-License-Identifier: CC-BY-4.0




Modify as needed for whatever comment syntax the language or markup uses. Good
places for these markings are at the end of an extended

header comment, or at the very top of the file.


When you modify a file, leave existing copyright markings in place - especially
all references to Dr. Dave Mills, to Mr. Harlan Stenn, and

to the Network Time Foundation.


You *may* add a project copyright and replace the inline license with an
SPDX tag. For example:




/* Copyright 2017 by the NTPsec project contributors

 * SPDX-License-Identifier: NTP

 */





On Mon, Jan 30, 2017 at 10:44 AM Daniel Poirot  wrote:

> Commercial FOSS audit tools like Protecode and BlackDuck will match a
> snippet and attribute to the FOSS project.
>
>
> On Jan 30, 2017, at 12:30 PM, Mark Atwood  wrote:
>
> That's... complicated.
>
> We don't need to have a notice attached to every file, because there is a
> copyright notice attached to the project as a whole, and there is a notice
> attached to each repo.  Individual files generally don't each need their
> own notice, since individual files generally no longer get "detached" from
> a project or tree.
>
> But, if you were to copy in a substantial amount of text from another
> source, you should make sure that the copyright from that source is
> properly declared, right next to the text pulled in.
>
> Also, however, documentation is a bit unusual in that it is much more
> likely to be detached and separately distributed from the rest of the
> project.  We should make sure that if the documentation is ever printed
> out, or is separately displayed on sites like man7.org, that a copyright
> notice should be readable.
>
> ..m
>
> On Mon, Jan 30, 2017 at 1:55 AM Hal Murray 
> wrote:
>
>
> fallenpega...@gmail.com said:
> > Right now our standard copyright text is "Copyright
> $YEAR_YOU_ARE_WRITING_THI
> > S by the NTP Project contributors"
>
> Should the documentation files have a copyright notice?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Copyright dates

[Mark Atwood]

Oh god, yeah.  Stack Overflow copypastes are a constant headache today when
doing due diligence when acquiring tech companies.

Lots of people have been begging Stack Overflow to do something about it.
The CC license that SO defaults all it's content to is not compatible with
any open source or even proprietary license.   They need to change their
TOS to make code snippets be either CC0 or MIT.

(In general, the only CC license that is compatible with anything is CC0.
Any software code licensed under any other CC license cannot be mixed with
anything else.)

..m

On Mon, Jan 30, 2017 at 11:16 AM Daniel Poirot  wrote:

> What's fun is hearing "No copyright needed, I got it off Stack Overflow!"
>
> ...wrong
>
>
> On Jan 30, 2017, at 12:58 PM, Mark Atwood  wrote:
>
> Commercial FOSS audit tools like Protecode and Blackduck will be able to
> recognize the SPDX tags, and the Copyright text.
>
>
> In our file ntpsec/devel/hacking.txt :
>
> We use the SPDX convention for inclusion by reference.  You can read about
> this at
>
>   http://spdx.org/licenses
>
> When you create a new file, mark it as follows (updating the year) as
> required:
>
> 
>
> /* Copyright 2017 by the NTPsec project contributors
>
>  * SPDX-License-Identifier: BSD-2-Clause
>
>  */
>
> 
>
>
> For documentation:
>
>
> 
>
> // Copyright 2017 by the NTPsec project contributors
>
> // SPDX-License-Identifier: CC-BY-4.0
>
> 
>
>
> Modify as needed for whatever comment syntax the language or markup uses. Good
> places for these markings are at the end of an extended
>
> header comment, or at the very top of the file.
>
>
> When you modify a file, leave existing copyright markings in place - 
> especially
> all references to Dr. Dave Mills, to Mr. Harlan Stenn, and
>
> to the Network Time Foundation.
>
>
> You *may* add a project copyright and replace the inline license with an
> SPDX tag. For example:
>
>
> 
>
> /* Copyright 2017 by the NTPsec project contributors
>
>  * SPDX-License-Identifier: NTP
>
>  */
>
> ----
>
>
>
> On Mon, Jan 30, 2017 at 10:44 AM Daniel Poirot  wrote:
>
> Commercial FOSS audit tools like Protecode and BlackDuck will match a
> snippet and attribute to the FOSS project.
>
>
> On Jan 30, 2017, at 12:30 PM, Mark Atwood  wrote:
>
> That's... complicated.
>
> We don't need to have a notice attached to every file, because there is a
> copyright notice attached to the project as a whole, and there is a notice
> attached to each repo.  Individual files generally don't each need their
> own notice, since individual files generally no longer get "detached" from
> a project or tree.
>
> But, if you were to copy in a substantial amount of text from another
> source, you should make sure that the copyright from that source is
> properly declared, right next to the text pulled in.
>
> Also, however, documentation is a bit unusual in that it is much more
> likely to be detached and separately distributed from the rest of the
> project.  We should make sure that if the documentation is ever printed
> out, or is separately displayed on sites like man7.org, that a copyright
> notice should be readable.
>
> ..m
>
> On Mon, Jan 30, 2017 at 1:55 AM Hal Murray 
> wrote:
>
>
> fallenpega...@gmail.com said:
> > Right now our standard copyright text is "Copyright
> $YEAR_YOU_ARE_WRITING_THI
> > S by the NTP Project contributors"
>
> Should the documentation files have a copyright notice?
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Copyright dates

[Mark Atwood]

I will sweep through the documentation files, and add the correct forms and
content for the copyright and license markings.

..m

On Mon, Jan 30, 2017 at 12:02 PM Gary E. Miller  wrote:

> Yo Mark!
>
> On Mon, 30 Jan 2017 18:58:55 +0000
> Mark Atwood  wrote:
>
> > When you create a new file, mark it as follows (updating the year) as
> > required:
>
> [...]
>
> Can you add this advice to some doc that is in tree?
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘Debug modes

[Mark Atwood]

No objections from me.

On Thu, Feb 16, 2017 at 1:13 PM Gary E. Miller  wrote:

> Yo All!
>
> Currently waf has:
>
> --enable-debug  (ignored)
> --disable-debug Disable debugging code
> --enable-debug-gdb  Enable GDB debugging symbols
> --enable-debug-timing Collect timing statistics for debugging.
>
> Debug mode is the default, but not gdb (-g)
>
> Stripping of the binaries only happens with --disable-debug
>
> Seems to me debug off should be the default, so the options should be:
>
> --enable-debug  Enable debugging code
> --enable-debug-timing Collect timing statistics for debugging.
>
> Any objections?
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘ntpclient names

[Mark Atwood]

My own preference would be
ntploggps
ntplogheat
ntpmakeheat

eg.  {prefix}{verb}{thenoun}

"temp" is too overloaded as "temporary".

Short is not needed, the day of 15 character filenames and typing over a
110bps ASR33 with 500ms of lag are far in the distant past.

But that's just a preference of mine, GEM's proposal is fine.

..m


On Tue, Feb 21, 2017 at 12:38 PM Eric S. Raymond  wrote:

> Gary E. Miller :
> > Yo All!
> >
> > Eric wants all ntp programs to start with 'ntp' and not have hypens.
> >
> > So, how about:
> >
> >   gps-log -> ntpgpslog
> > temp-log -> ntptemplog
> > makeheat -> ntpmakeheat
> >
> > Suggestions?
>
> That works for me.  I'd make 'em shorter if I could, but don't see any
> obvious way to do that that wouldn't reduce them to garble.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> 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
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ntpclient names

[Mark Atwood]

> What's the actual problem with including ntpviz in the standard install

Anything that triggers a surprise dependency to load libx, a font renderer,
or a font pack onto a ssh & text console -only host gets a veto from me.

..m



On Tue, Feb 21, 2017 at 2:14 PM Eric S. Raymond  wrote:

> Hal Murray :
> > As long as they don't get installed, I don't think the ntp prefix is
> > important.
>
> Nevertheless, I think we should maintain namespace discipline even for
> the uninstalled stuff. It's not always easy to predict what will *remain*
> uninstalled.
>
> >A hyphen after the ntp might make them easier to read.
>
> But harder to remember when you're typing.  I actually thought about
> this pretty carefully before squeezing hyphens out of the program
> names at the time of the fork.  I didn't do that casually.
>
> The problem is that there's no generative rule for where to hyphenate
> in names like these that is both intuitively correct and simple to
> apply on the fly. So if you use hyphens you're implicitly putting on
> users the cognitive burden of remembering semi-arbitrary locations.
>
> To illustrate the problem, consider the different ways ntpkeygen might
> be hyphenated:
>
> ntpkeygen
> ntp-key-gen
> ntp-keygen
> ntpkey-gen
>
> Generally when you hyphenate a compound like that, you're expressing a
> judgment about which subset of parts are tightly bound to each other
> (and should be wordlike) vs. which subparts are more loosely coupled
> and deserve an intermediating hyphen.  It's *hard* to form a simple
> generative rule for this, and harder to apply it consistently across
> multiple names.  You get into fuzzy issues about what the semantic
> units are; effectively you have to commit to preferring one of
> multiple competing phrase parsings for the expansion of the name.
>
> So I just said "screw it" and ripped all the hyphens out.  Simplest thing,
> and I think we should stick to it.
>
> > We need to figure out how to handle ntpviz and friends.  I think it
> should
> > NOT be part of the standard install set.  At a minimum, there should be
> an
> > easy way to skip it during install.
>
> I've forgotten.  What's the actual problem with including ntpviz in
> the standard install?
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> 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
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ✘ntpclient names

[Mark Atwood]

Call it "therm" or "thermal" then, instead of "heat" or "temperature"?

On Tue, Feb 21, 2017 at 2:24 PM Gary E. Miller  wrote:

> Yo Mark!
>
> On Tue, 21 Feb 2017 22:12:26 +
> Mark Atwood  wrote:
>
> > My own preference would be
> > ntploggps
> > ntplogheat
> > ntpmakeheat
> >
> > eg.  {prefix}{verb}{thenoun}
>
> I like it.
>
> > "temp" is too overloaded as "temporary".
>
> Yeah, but heat is in Joules or Watts and temperature is in degrees
> Celsius or Fahrenheit.  Not the same thing.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: ntpclient names

[Mark Atwood]

++

On Tue, Feb 21, 2017 at 2:26 PM Gary E. Miller  wrote:

> Yo Mark!
>
> On Tue, 21 Feb 2017 22:20:57 +0000
> Mark Atwood  wrote:
>
> > > What's the actual problem with including ntpviz in the standard
> > > install
> >
> > Anything that triggers a surprise dependency to load libx, a font
> > renderer, or a font pack onto a ssh & text console -only host gets a
> > veto from me.
>
> ntpviz triggers no such thing.  gnuplot does, but that is in the optional
> buildprep script.  So it should be an option to buildprep.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Scheduling a repository outage

[Mark Atwood]

I'm ready.

On Sun, Mar 5, 2017 at 12:26 PM Eric S. Raymond  wrote:

> Mark has asked me to try to graft onto our repository a branch
> representing NTP Classic development since the fork.
>
> For ugly reasons that I will detail in later mail, I think this is
> just barely doable, but not with conventional git operations.
> It will take reposurgeon to get the job done.
>
> That means we need to develop a protocol for doing surgery on the GitLab
> repository in such a way that everyone's pending work (whether tip
> changes, private branges, or merge requests) is preserved and can be
> reapplied afterwards.
>
> I don't want us to have to debug that protocol while I'm dealing with a
> serious tangle - and the branch graft is a serious tangle. So I intend
> to do a surgical test with low stakes first. The low stakes are "let's
> fix typos in old comments without modifying code or repository topology".
> That way, even if the graft attempt fails (which is possible) we'll
> at least have gained *something* from the whole exercise.
>
> Here's how I think it needs to go:
>
> 1. When you read this, push any public changes you have ready.
>
> 2. If you have private branches, save each one as a patch sequence.
>Make note of the branch point.
>
> 3. Reply to this message telling me you're ready - especially if you
>are Gary, Matt, or Hal.
>
> 4. I will then schedule a brief repo outage for the surgery.
>
> 5. When I'm done, I'll announce it here.  At that point the following
>things will need to happen:
>
> 6. You guys restore your private branches.
>
> 7. Mark will need to re-make the signed release tags.
>
> One of the reasons I want to do this is to find out if GitLab's issue
> and merge-tracker logic is capqable of resynching itself to the new
> hash sequence after surgery.  For example under issue #247 the
> page says "Eric S. Raymond @esr mentioned in commit 6e45c35a a week
> ago" with that commit titled
>
> Revert "Address GitLab issue #247: Extra precision for avgint field..."
>
> It'll be important to note what happens to this reference post-surgery.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> Hoplophobia (n.): The irrational fear of weapons, correctly described by
> Freud as "a sign of emotional and sexual immaturity".  Hoplophobia, like
> homophobia, is a displacement symptom; hoplophobes fear their own
> "forbidden" feelings and urges to commit violence.  This would be
> harmless, except that they project these feelings onto others.  The
> sequelae of this neurosis include irrational and dangerous behaviors
> such as passing "gun-control" laws and trashing the Constitution.
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: A talk on NTPsec

[Mark Atwood]

Thank you so much, Sanjeev.

Do you know if your talk will be video recorded?

..m

On Sun, Mar 12, 2017 at 2:45 PM Sanjeev Gupta  wrote:

> Hi,
>
> FossAsia is a large(ish) hacker conference in Singapore, now 4 or 5 years
> old.  I thought of a short talk on NTPsec.
>
> The blurb (which is not possible in the 25mins allocated) is here:
> http://2017.fossasia.org/tracks.html#2017-03-19-Security%20and%20Privacy
> (search for Sanjeev)
>
> It is setup just before lunch, I plan to actually use a RPi and a GPS puck
> to build and run NTPsec.
>
> Any pointers for the talk?  Average audience is 25-35 year olds, from S E
> Asia.
>
> Susan, do you have a slide deck I could "be inspired by"?
>
> --
> Sanjeev Gupta
> +65 98551208 <+65%209855%201208> http://www.linkedin.com/in/ghane
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: A talk on NTPsec

[Mark Atwood]

Sanjeev,

You can see a video of Susan's recent talk at
https://www.oreilly.com/ideas/the-internet-is-going-to-fall-down-if-i-dont-fix-this-susan-sons?imm_mid=0eb1c1&cmp=em-webops-na-na-newsltr_security_20161129

and her slide deck is at
http://slides.com/hedgemage/savingtime

Which GPS receiver puck are you going to use?

You and your audience can buy GPS receiver pucks at
https://www.etsy.com/shop/Fallenpegasus

Of interest to time geeks from that part of the world is that they will
receive from the the QZSS GNSS system that covers much of that part of the
world.



..m


On Sun, Mar 12, 2017 at 2:45 PM Sanjeev Gupta  wrote:

> Hi,
>
> FossAsia is a large(ish) hacker conference in Singapore, now 4 or 5 years
> old.  I thought of a short talk on NTPsec.
>
> The blurb (which is not possible in the 25mins allocated) is here:
> http://2017.fossasia.org/tracks.html#2017-03-19-Security%20and%20Privacy
> (search for Sanjeev)
>
> It is setup just before lunch, I plan to actually use a RPi and a GPS puck
> to build and run NTPsec.
>
> Any pointers for the talk?  Average audience is 25-35 year olds, from S E
> Asia.
>
> Susan, do you have a slide deck I could "be inspired by"?
>
> --
> Sanjeev Gupta
> +65 98551208 <+65%209855%201208> http://www.linkedin.com/in/ghane
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Future of 32 bit time_t?

[Mark Atwood]

Are there any worrisome performance or conformance issues with time64_t on
any of our 32bit targets?

..m

On Mon, Mar 13, 2017 at 5:03 PM Hal Murray  wrote:

>
> I have the leap second code mostly cleaned up.  It builds but the tests
> still
> get several errors.  There is no reference to ntpcal_xxx.
>
> The general idea is that the file format uses NTP epoch, but as soon as
> dates
> are read in, they are converted to time_t.  All processing is done using
> time_t.
>
> That works fine now, but will break in 2038.
>
> Is the world going to shift to 64 bit time_t soon enough?  Or should I
> convert everything to time64_t now while the code is somewhat fresh in my
> mind.  Actually, I think I would debug the non64 case first, then update to
> time64_t.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

next release, 0.9.7, 2017-03-21

[Mark Atwood]

A lot of useful work has gone into NTPsec since the 0.9.6 release on
2016-12-30, and we have some good momentum right now, which we want to
demonstrate.

To that end, I would like to cut the 0.9.7 release a week from today, on
2017-03-21.

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: git head now contains touch-20170321.1

[Mark Atwood]

my fault. I'll push a deletion of it

..m

On Wed, Mar 22, 2017, 2:14 AM Eric S. Raymond  wrote:

> Hal Murray :
> >
> > I thought it was my fatfinger and deleted it, but then git status said
> it was
> > deleted.
>
> esr@snark$ git log touch-20170321.1
> commit 899f8859082c6de768caf84daad26aeceb3143fd
> Author: Mark Atwood 
> Date:   Tue Mar 21 22:15:26 2017 +
>
>     version 0.9.7
>
> Signed-off-by: Mark Atwood 
>
> Mark, did you create this by hand for some reason?  grep-find isn't showing
> anything that looks like plausible creation code in the tree.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> 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
>
-- 
Mark Atwood
http://about.me/markatwood
+1-206-604-2198 SMS & Signal
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Wildcard-socket simplification hits a wall

[Mark Atwood]

I would like some discussion about this, however, my inclination is to drop
it.

It is my belief that when a sysadmin is going to do sophisticated filtering
based on MAC or by interface id, they will do it in their switch or they
will do locally with the ipfw or iptables feature, and would not trust the
daemon process they are trying to protect to get it right.Every
Linux-like and modern POSIX-like OS has a kernel level table filter feature
like iptables or ipfw, and doing such filtering there is the Right Place to
do it.

I specifically would like GEM and Hal to chime on this.  Am I correct?

..m

On Thu, Mar 30, 2017 at 9:06 AM Eric S. Raymond  wrote:

> Head up, Mark!  Policy issue.
>
> I fear the wildcard-socket simplification, last of our pre-1.0 major
> ambitions, has just hit a wall.
>
> The problem is not with the code simplification itself.  The problem is
> that there is a configuration feature called "NIC rules" that depends
> on knowing what actual physical interface a packet arrived on. NIC
> rules are address filters applied to individual interfaces.
>
> In order to implement this against a packet flow that is all being
> accepted by the wildcard interface, we need a way to back out of each
> packet which physical interface it arrived on.
>
> One might expect this to be available via a CMSG lookup into recmvsg's
> per-package auxiliary headers, analogously to the way we now get the
> packet-arrival timestamp (see ntpd/ntp_packetstamp.c).  It's the only
> place for the information to be that has the right locality.
>
> That's our wall.  There appears to be such auxiliary header part under
> Linux. It's not easy to say definitively, because the documentation
> of this part of the socket API is scanty and confusing.  But it looks
> like, other than the values of certain options set by sockopt(2),
> arrival time is the *only* out-of-band data you can reliably back out
> of a packet.
>
> Thus we can proceed with the simplification only at the cost of
> dropping the NIC-rule feature.  As much as I would love to drop the
> snarl of code around interface scanning, I feel I must recommend
> against this.  It would be the first case in which we take away an
> administrator tool without a specific security rationale. I fear it
> would not go over well.
>
> My recommendation is that we ship with this code undisturbed, mark
> the NIC-rule feature "deprecated" and speak of it being removed in
> the future, then see if anybody squawks.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> Of all tyrannies, a tyranny exercised for the good of its victims may
> be the most oppressive. It may be better to live under robber barons
> than under omnipotent moral busybodies. The robber baron's cruelty may
> sometimes sleep, his cupidity may at some point be satiated; but those
> who torment us for our own good will torment us without end, for they
> do so with the approval of their consciences.
> -- C. S. Lewis
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-- 
Mark Atwood
http://about.me/markatwood
+1-206-604-2198 SMS & Signal
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Wildcard-socket simplification hits a wall

[Mark Atwood]

I'm inclined to say drop the feature.

Yes defense in depth is good, but I think it doesn't really count in this
case.  If a network admin is defending their NTP in depth, they will do it
in (in order), the local kernel table, the local switch, the ingress
switch, on the ISP side on the other side of the link to the ingress
switch, and in their ISP's connection to their transit providers.

The feature also feels very "brittle" to me, from an admin POV.  How many
netadmins are going to remember to update the setting when they change
anything about the local interface topology, or in the local hypervisor or
container topology.

And yes, can someone Not Me ask on the NTP list?

..m

On Fri, Mar 31, 2017 at 12:31 PM Gary E. Miller  wrote:

> Yo Mark!
>
> On Fri, 31 Mar 2017 19:19:04 +
> Mark Atwood  wrote:
>
> > I would like some discussion about this, however, my inclination is
> > to drop it.
>
> Drop the discussion, drop the old feature, or drop the work to drop the old
> feature?
>
> > It is my belief that when a sysadmin is going to do sophisticated
> > filtering based on MAC or by interface id, they will do it in their
> > switch or they will do locally with the ipfw or iptables feature, and
> > would not trust the daemon process they are trying to protect to get
> > it right.Every Linux-like and modern POSIX-like OS has a kernel
> > level table filter feature like iptables or ipfw, and doing such
> > filtering there is the Right Place to do it.
>
> Or the newest toy: nftables.  My personal beliefe is every sysadmin
> should be managing his entire system from the one tool, but defense
> in depth is also good.
>
> > I specifically would like GEM and Hal to chime on this.  Am I correct?
>
> My main concern is if anyone actually uses this option.  If so, they
> are the more advanced users, and I'd rather not annoy them when we want
> them to switch to NTPsec.
>
> OTOH, if no one is actually using the option, then we can remove the
> option.  My totally unsubstantiated gut feel is that this is a newish
> feature that is not used by many sysadmins, if any.
>
> So, sadly, my answer is a non-answer.  When I kill off esr's suffix's
> I'd be happy to dig into this.  I have now looked at more than a
> hundred current and popular ways to dor .d directories.  Esr's take
> is very much an outlier.  But more on that later, in a different
> thread.
>
> Maybe someone could ask on the NTP list is anyone uses the feature?
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel

-- 
Mark Atwood
http://about.me/markatwood
+1-206-604-2198 SMS & Signal
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Wildcard-socket simplification hits a wall

[Mark Atwood]

> running a single instance in a VM for the pool.

This feature would be a misfeature in a VM, as MACs and interface ID's are
particularly fluid in VMs.  And if someone is running ntpd in a VM and want
to protect it in depth, they will use the hypervisor's network access
control table.

..m

On Fri, Mar 31, 2017 at 1:42 PM Gary E. Miller  wrote:

> Yo Mark!
>
> On Fri, 31 Mar 2017 20:06:32 +
> Mark Atwood  wrote:
>
> > I'm inclined to say drop the feature.
>
> Me too, but only as a me too.  Don't blame me!
>
> > Yes defense in depth is good, but I think it doesn't really count in
> > this case.  If a network admin is defending their NTP in depth, they
> > will do it in (in order), the local kernel table, the local switch,
> > the ingress switch, on the ISP side on the other side of the link to
> > the ingress switch, and in their ISP's connection to their transit
> > providers.
>
> Now you are thinking big boy toys, a lot of small guys run ntpd.  Think
> of Hal running a single instance in a VM for the pool.
>
> But then, Hal would not be using this feature...
>
> > The feature also feels very "brittle" to me, from an admin POV.  How
> > many netadmins are going to remember to update the setting when they
> > change anything about the local interface topology, or in the local
> > hypervisor or container topology.
>
> Yeah, I've been bitten by that.  Especially when Gentoo changed ethernet
> intertfaces names a while back.
>
> > And yes, can someone Not Me ask on the NTP list?
>
> I just asked on questi...@ntp.org.  Did not seem like a hack...@ntp.org
> thing.
>
>
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel

-- 
Mark Atwood
http://about.me/markatwood
+1-206-604-2198 SMS & Signal
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Coverity upped its game again

[Mark Atwood]

awesome!

On Mon, Jan 25, 2016 at 2:27 AM Eric S. Raymond  wrote:

> An encouraging news bulletin because things have been a bit slow over the
> holidays:
>
> I'm now able to do Coverity scanning again after a hiatus of about three
> weeks due to my cov-build tools going stale when I ubgraded to Ubuntu 15.
>
> Coverity has improved its scan quality while I wasn't looking.
> I found a resource leak in async DNS this morning and plugged it.
> There was also a bad shift operation in one of the clock drivers
> that had not been caught before and was easy to fix.
>
> These are nice things to have land just before 0.9.1.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

planning ntpsec 0.9.1 release at about 7pm PST tonight

[Mark Atwood]

Hi!

If the buildbot status makes me happy, and nobody chimes in with a blocker,
I will tag and release ntpsec 0.9.1 at about 7pm PST this evening 2016-01-25

Thank you, everyone.

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: planning ntpsec 0.9.1 release at about 7pm PST tonight

[Mark Atwood]

On Mon, Jan 25, 2016 at 11:39 AM Mark Atwood 
wrote:

> If the buildbot status makes me happy, and nobody chimes in with a
> blocker, I will tag and release ntpsec 0.9.1 at about 7pm PST this evening
> 2016-01-25
>
>
Hi!

I'm happy with buildbot, I created a clean VM and cloned and built in it,
I've updated NEWS and VERSION, I just created a signed tag NTPsec_0_9_1.
I'm about to push.

..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: planning ntpsec 0.9.1 release at about 7pm PST tonight

[Mark Atwood]

No worries.  Fix 2845 2882 2772 2948 2939 2935 2937 2814 2829 2887 2958
2962, and we will call that 0.9.2

Thanks!

..m

On Mon, Jan 25, 2016 at 6:37 PM Eric S. Raymond  wrote:

> Hal Murray :
> > The real question is are we going to track fixes from NTP Classic and if
> so
> > who, how, when, etc?  There were a lot of patches released in the past
> few
> > days.  I haven't scanned them. I don't think anybody has reviewed all the
> > changes since the fork.
>
> Uh oh.  We've had a moderately serious coordination failure here.
> Fortunately
> it should be recoverable without a huge amound of work.
>
> Just before 0.9.0 I reviewed all Classic changes from the fork to
> September 29th and forward-ported everything relevant up to their fix
> for bug 2902 on 29 September.  The only thing I skipped that I regret a
> little is pearly's cleanup of the calendar code - I have a bit set to
> look back at that if we don't recruit him first.
>
> So the good news is we're caught up to well past the fork.
>
> After I did the catchup to late September I thought *you* had accepted
> the job of tracking Classic's fixes while I concentrated on
> capture/replay.  That was in the proposed work plan I published just
> after 0.9.0, which Mark approved.  I thought you were obviously the best
> positioned for this, since you track ntp-hackers and occasionally
> contribute fixes there.
>
> As for where we are now, we elected not to port the Classic fix for
> 2332 because we're planning to plain rewrite the async stuff.
> Excluding the CVEs we already have fixes for, I don't actually see a
> lot of bugfixes affter Sep 29 that need porting.  I'm looking at the
> Classic history now and I see these: 2845 2882 2772 2948 2939 2935
> 2937 2814 2829 2887 2958 2962.
>
> The better news is that most of these look like pretty trivial
> patches; I'd be surprised if it takes more than a day and a half to
> cross-port them all.  If I'd known we'd had a disconnect and you
> weren't working on this I'd have knocked off a few to relax from the
> heavy stuff.
>
> > I looked into the ^C tangle.  I'm trying to do it from scratch rather
> than
> > blindly copy the new code.  Maybe I'll learn enough to understand why
> the new
> > code seems so complicated.
> >
> > It should be simple.  The general idea is that the code that calls the
> > command dispatcher does a setjmp and sets a flag for the ^C signal
> handler.
> > If the flag is on, the signal handler does a longjmp to bail from the
> command.
> >
> > I put a printf in the top of the signal handler.  The problem I'm seeing
> is
> > that the ^C handler goes away after the first jump.  If it doesn't jump,
> it
> > keeps on working.
>
> Yeah, that looks like you're getting old-style resetting behavior when the
> handler is called.  See below...
>
> >
> > An additional complication is that readline sets a bunch of signal
> handlers.
> > I haven't investigated.  Since it isn't mentioned in the man page, I
> assume
> > it puts things back the way they were and/or calls the old signal
> handler.
> >
> > I tried blindly setting the signal handler again but that didn't fix it.
> > That's as far as I got before it was time for sleep.  Maybe it's masked?
> >
> > I've spent some time googling but haven't found anything interesting yet.
> > Are there any obvious gotchas associated with signals and longjmp that I
> > should know about?
>
> Heh.  Looks like you tripped over them already. This sort of thing is
> par for the course when you mess with signal handlers.  They're spooky
> action at a distance and the side effects are hard to track.
>
> General advice: Be sure you're using sigaction(2) rather than signal(2),
> the
> older API may not preserve your signal bindings when a handler is fired.
> Make
> sure the handler flags do *not* include SA_RESETHAND.
>
> Be sure you signal-latch flag is declared volatile; compiler optimizations
> can fuck you up otherwise.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel