planning ntpsec 0.9.1 release at about 7pm PST tonight

[Eric S. Raymond]

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>