Re: Trying again: prep for 1.0.1

devel@ntpsec.org said: > What kind of special labeling does ntpsnmpd require? Is putting > "experimental" in the documentation sufficient? Does it need to give a > warning on launch? I'd put "experimental" in NEWS. If you put something in the documentation it should probably say a bit about

Re: Trying again: prep for 1.0.1

Matthew Selsky : > On Fri, Mar 09, 2018 at 03:25:02PM -0500, Eric S. Raymond via devel wrote: > > Eric S. Raymond via devel : > > > The CVEs we dodged aught to be listed in NEWS. For bragging purposes. > > > > I have just done this. > > Have we

Re: Trying again: prep for 1.0.1

On Fri, Mar 09, 2018 at 03:25:02PM -0500, Eric S. Raymond via devel wrote: > Eric S. Raymond via devel : > > The CVEs we dodged aught to be listed in NEWS. For bragging purposes. > > I have just done this. Have we committed the fix for the CVE that we didn't dodge? Thanks,

Re: Trying again: prep for 1.0.1

Eric S. Raymond via devel : > The CVEs we dodged aught to be listed in NEWS. For bragging purposes. I have just done this. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit

Re: Trying again: prep for 1.0.1

Matthew Selsky via devel : > Can we please call this release 1.1 since it's not just a minor patch from > 1.0? We've fixed a lot of things since 1.0 Concur. -- http://www.catb.org/~esr/;>Eric S. Raymond My work is funded by the Internet Civil Engineering

Re: Trying again: prep for 1.0.1

Ian Bruene via devel : > What kind of special labeling does ntpsnmpd require? Is putting > "experimental" in the documentation sufficient? Does it need to give a > warning on launch? That's not normal practice. Just mark it "Experimental" in the documentation. --

Re: Trying again: prep for 1.0.1

Can we please call this release 1.1 since it's not just a minor patch from 1.0? We've fixed a lot of things since 1.0 Thanks, -Matt On Fri, Mar 09, 2018 at 06:43:47PM +, Mark Atwood, Project Manager via devel wrote: > Ok, trying again. We held the 1.0.1 release for a fix for a problem

Re: Trying again: prep for 1.0.1

On 03/09/2018 12:43 PM, Mark Atwood, Project Manager via devel wrote: Ok, trying again.  We held the 1.0.1 release for a fix for a problem that Hal discovered and fixed.  Thank you, Hal! Since we have a CVE fix in this release, and also a "make it work better on AWS AMIs" fix in, I do want

Trying again: prep for 1.0.1

any reason to not release? I'm targeting Tuesday the 13th of March. ..m On Tue, Feb 20, 2018 at 6:41 PM Mark Atwood <mark.atw...@ntpsec.org> wrote: > Hi! > > A few months ago, I announced prep for a 1.0.1 release. Turns out, it > never actually happened. > > So, I'm declaring

Re: prep for 1.0.1

> Do you have the truncate fix in? Apologies for not sending a specific announcement. Yes. commit b01f1d658b11c4e8c24b307a7a79e8307364fbc2 Author: Hal Murray Date: Fri Mar 2 00:38:49 2018 -0800 Truncate digests longer than 20 bytes. -- The top of my

Re: prep for 1.0.1

Hi Hal, Do you have the truncate fix in? ..m On Thu, Mar 1, 2018 at 6:09 PM Hal Murray wrote: > > fallenpega...@gmail.com said: > > If Hal isn't happy, I'm not happy. I'll hold the release until this gets > > unsnarled. ..m > > It will take a day or two to fix the

Re: prep for 1.0.1

On 03/01/2018 08:09 PM, Hal Murray via devel wrote: > It will take a day or two to fix the truncate case. Maybe tonight. > > It will take a week or so to add CMAC support. Waiting for that seems like a > good idea. It will give a good focus for a release. Are these a regression from 1.0.0?

Re: prep for 1.0.1

fallenpega...@gmail.com said: > If Hal isn't happy, I'm not happy. I'll hold the release until this gets > unsnarled. ..m It will take a day or two to fix the truncate case. Maybe tonight. It will take a week or so to add CMAC support. Waiting for that seems like a good idea. It will

Re: prep for 1.0.1

If Hal isn't happy, I'm not happy. I'll hold the release until this gets unsnarled. ..m On Thu, Mar 1, 2018 at 2:42 PM Hal Murray via devel wrote: > [truncate long digests] > > Bletch. No, we don't. > > Except that others are already doing it, so I guess we should do it

Re: prep for 1.0.1

[truncate long digests] > Bletch. No, we don't. Except that others are already doing it, so I guess we should do it too. I'll add a warning to the code that reads in keys. -- These are my opinions. I hate spam. ___ devel mailing list

Re: prep for 1.0.1

Hal Murray : > > devel@ntpsec.org said: > > I see no real blockers. We've got a bunch of little nits and documentation > > issues. I might try to push a fix for #446. > > There is no problem unless you setup your keys file to use an algorithm with > a big digest. >

Re: prep for 1.0.1

> I see no real blockers. We've got a bunch of little nits and documentation > issues. I might try to push a fix for #446. >From n...@ietf.org > Please note that latest versions of ntp truncate long digests in MACs to 160 > bits, so the authentication should work with any hash function

Re: prep for 1.0.1

devel@ntpsec.org said: > I see no real blockers. We've got a bunch of little nits and documentation > issues. I might try to push a fix for #446. There is no problem unless you setup your keys file to use an algorithm with a big digest. The short term clean fix is to reject algorithms with

Re: prep for 1.0.1

Mark Atwood, Project Manager via devel : > Are we comfortable with the 1.0.1 release on March 3rd? > > I look forward to seeing it move down all the distribution pipelines. > Google Alerts have shown 1.0.0 in Debian, Ubuntu, and Gentoo distribution > build reports. I see no

Re: prep for 1.0.1

> Are we comfortable with the 1.0.1 release on March 3rd? I'm not. My attempts at fixing #461 aren't working. I think it should be simple. I think I understand what the problem is, but I don't understand why my attempts at fixing it aren't working. The root of the problem is this (from the

Re: prep for 1.0.1

wrote: > Hi! > > A few months ago, I announced prep for a 1.0.1 release. Turns out, it > never actually happened. > > So, I'm declaring an intention for the 1.0.1 release the weekend after > next, about March 3rd. > > As you work, consider stability, and avoid introducing

Re: prep for 1.0.1

On Wed, Feb 21, 2018 at 02:10:25AM -0600, Richard Laager via devel wrote: > On 02/20/2018 09:19 PM, Eric S. Raymond via devel wrote: > > I'll get on the tracker and swat a bunch of small issues I see. > > I'd like to suggest the following: > > 1) Move #55 out of 1.0.0 milestone. > 2) Close the

Re: prep for 1.0.1

I am inclined towards quarterly release schedule as well, modified with doing a release when we discover an important enough issue, and we will delay a release if we discover an important enough issue. On Wed, Feb 21, 2018 at 1:41 PM Hal Murray via devel wrote: > >

Re: prep for 1.0.1

rlaa...@wiktel.com said: > If you're going to move to time-based, you might consider quarterly > releases? I'd be happy with quarterly releases. The next question is how seriously do we take the release date? I think there are two approaches. The first is to try hard to release as scheduled.

Re: prep for 1.0.1

On 02/21/2018 02:44 AM, Hal Murray wrote: >> I'm a big fan of "always stable master" and time based releases. > > I'd be happy with that. What sort of interval did you have in mind for "time > based"? I don't have one in mind. Looking at the history of releases, they tend to be 1-4 months,

Re: prep for 1.0.1

Thanks for the input. > I'm a big fan of "always stable master" and time based releases. I'd be happy with that. What sort of interval did you have in mind for "time based"? Our master is generally pretty stable, but we don't have a solid test setup. We can tell if it builds, but that

Re: prep for 1.0.1

On 02/20/2018 09:19 PM, Eric S. Raymond via devel wrote: > I'll get on the tracker and swat a bunch of small issues I see. I'd like to suggest the following: 1) Move #55 out of 1.0.0 milestone. 2) Close the 0.9.4, 0.9.5, and 1.0 release milestones, since those releases have already happened. 3)

Re: prep for 1.0.1

On 02/21/2018 01:50 AM, Hal Murray via devel wrote: > devel@ntpsec.org said: >> So, I'm declaring an intention for the 1.0.1 release the weekend after next, >> about March 3rd. > > Could you please say a bit more about how you picked that date? Please consider this my "vote"/request/preference

Re: prep for 1.0.1

devel@ntpsec.org said: > So, I'm declaring an intention for the 1.0.1 release the weekend after next, > about March 3rd. Could you please say a bit more about how you picked that date? I would expect either: as soon as we finish feature X, or as soon as we stop fixing minor things (like

Re: prep for 1.0.1

> The big deal is whether we have closure on the Python installation mess. The only loose end that I know about is PYTHONDIR vs PYTHONARCHDIR. We now understand why what we have been expecting doesn't work. We are trying to import ntp.ntpc. That's a two step process. First it looks up ntp,

Re: prep for 1.0.1

On 02/20/2018 08:41 PM, Mark Atwood via devel wrote: Hi! A few months ago, I announced prep for a 1.0.1 release. Turns out, it never actually happened. So, I'm declaring an intention for the 1.0.1 release the weekend after next, about March 3rd. As you work, consider stability, and avoid

Re: prep for 1.0.1

On 02/20/2018 09:19 PM, Eric S. Raymond via devel wrote: I'll get on the tracker and swat a bunch of small issues I see. The big deal is whether we have closure on the Python installation mess. The Python installation works the way it did before that last minute 'fix' before 1.0. So the

Re: prep for 1.0.1

Mark Atwood via devel <devel@ntpsec.org>: > A few months ago, I announced prep for a 1.0.1 release. Turns out, it never > actually happened. > > So, I'm declaring an intention for the 1.0.1 release the weekend after next, > about March 3rd. > > As you work, co

prep for 1.0.1

Hi! A few months ago, I announced prep for a 1.0.1 release. Turns out, it never actually happened. So, I'm declaring an intention for the 1.0.1 release the weekend after next, about March 3rd. As you work, consider stability, and avoid introducing instability. And let us know