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 <esr at thyrsus.com> wrote:

> Hal Murray <hmurray at megapathdsl.net>:
> > 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.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160126/d0e1c727/attachment.html>