Thank you!
On Mon, Mar 5, 2018 at 2:25 PM Hal Murray via devel
wrote:
> > 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
>
> Tru
> 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 list of things to fix is the pyt
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 truncate case. Maybe tonig
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? If
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 give
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 too.
>
> I'll add a wa
[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
devel@ntpse
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.
>
> The short term clean fix
> 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 supporte
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 t
> Hal, is there anything I can do to help? I admit that it looks like the
> kind of thing we'd be better off letting you chew on than taking the time to
> fylly educate someone else, but if you don't think that's true I'm
> listening.
I just tried again.
It's not hard to explain. I'll try to
Hal Murray via devel :
> > 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 r
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 real blockers. We've
> 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 ma
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.
..m
On Tue, Feb 20, 2018 at 6:41 PM Mark Atwood wrote:
> Hi!
>
> A few months a
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 0.
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:
>
> rlaa...@wiktel.com said:
> > I
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.
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, with
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 doesn'
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) O
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 t
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 doc
> 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, th
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
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 "me
Mark Atwood via devel :
> 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.
27 matches
Mail list logo
