planning ntpsec 0.9.1 release at about 7pm PST tonight
fallenpegasus at gmail.com
Tue Jan 26 02:40:06 UTC 2016
No worries. Fix 2845 2882 2772 2948 2939 2935 2937 2814 2829 2887 2958
2962, and we will call that 0.9.2
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
> > who, how, when, etc? There were a lot of patches released in the past
> > 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.
> 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
> > 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
> > If the flag is on, the signal handler does a longjmp to bail from the
> > I put a printf in the top of the signal handler. The problem I'm seeing
> > that the ^C handler goes away after the first jump. If it doesn't jump,
> > 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
> > I haven't investigated. Since it isn't mentioned in the man page, I
> > it puts things back the way they were and/or calls the old signal
> > 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),
> older API may not preserve your signal bindings when a handler is fired.
> 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...
More information about the devel