> Would this be a better formulation? The NTS ALPN negotiation sequence now
> checks for length of the handshake string. This may break interoperability
> with other, non-compliant, NTS implementations.
> Basically, I wish to highlight that things may *break* with pre 1.2.0
Do we have any
Richard Laager via devel :
> On 8/23/19 6:55 PM, Hal Murray via devel wrote:
> > Or maybe wait for the NTS RFC to come out so we have a good reason for the
> > release.
>
> What is the official (or barring that, consensus) view on the quality of
> NTS in NTPsec? Is it something that is usable in
Hal Murray :
>
> >> Is there time to add an IPv4 only initialization option for NTS?
> > Options are bad, in general. Explain why you want this>
>
> (I was going to poke you on this.)
>
> There is a bug waiting for your comment - #666. Looks like you found it.
>
> > I hate options. They add
Sanjeev Gupta :
> Eric
>
> NEWS:
> The NTS ALPN negotiation sequence has been modified for improved
> interoperability with orther NTS implementations.
>
> Would this be a better formulation?
> The NTS ALPN negotiation sequence now checks for length of the handshake
> string.
> This may break
> Has anybody seen anything like this before?
> Assuming "no", I'll try bisecting tomorrow.
My attempt at bisecting hit a brick wall. I backed up many months and it
still fails.
I guessed that something strange had happened to that system. I setup a fresh
version of 7.2 on a different
> I see no changes related to _XOPEN_SOURCE since 2017. Perhaps you're
> thinking of GPSD, where there was bunch of rework in that area just before
> the 3.19 release.
Thanks. You are probably right.
Eric: This area just got more complicated. See #614
strerror_r() has two modes depending
devel@ntpsec.org said:
>> Or maybe wait for the NTS RFC to come out so we have a good
>> reason for the release.
> What is the official (or barring that, consensus) view on the quality of NTS
> in NTPsec? Is it something that is usable in production? If so, please cut a
> release sooner rather
Eric
NEWS:
The NTS ALPN negotiation sequence has been modified for improved
interoperability with orther NTS implementations.
Would this be a better formulation?
The NTS ALPN negotiation sequence now checks for length of the handshake
string.
This may break interoperability with other,
On 8/23/19 6:55 PM, Hal Murray via devel wrote:
> Or maybe wait for the NTS RFC to come out so we have a good reason for the
> release.
What is the official (or barring that, consensus) view on the quality of
NTS in NTPsec? Is it something that is usable in production? If so,
please cut a
> Does it make sense to call this 1.2.0 instead of 1.1.7? Especially since we
> have the ALPN compatiblity fix?
I suggest 1.1.7 soon, then a round of testing and cleanup before 1.2.0.
Or maybe wait for the NTS RFC to come out so we have a good reason for the
release.
--
These are my
>> Is there time to add an IPv4 only initialization option for NTS?
> Options are bad, in general. Explain why you want this>
(I was going to poke you on this.)
There is a bug waiting for your comment - #666. Looks like you found it.
> I hate options. They add complexity and proliferate
On Fri, Aug 23, 2019 at 12:41 PM Eric S. Raymond wrote:
> James Browning via devel :
> > AFAICT issues 599 and 566 still affect FreeBSD.
>
> Not urgent, IMO. In particular, I'm now fweeking more pressure to get
> the NTS fix out.
>
Then they can wait. Sanjeev pointed out that there are lots of
James, I am not sure on the time frame to patch and merge the issues you
mentioned, but I am concerned about the change to the behaviour of NTS.
We are not short of integers, 1.3.0 can be next week :-)
On Sat, 24 Aug 2019, 3:27 AM James Browning via devel,
wrote:
> On Fri, Aug 23, 2019 at 9:43
James Browning via devel :
> AFAICT issues 599 and 566 still affect FreeBSD.
Not urgent, IMO. In particular, I'm now fweeking more pressure to get
the NTS fix out.
> There is a stub in devel/README mentioning devel/tidy which never made it
> into the tree.
Oops. Just fixed.
> Is there time
On Fri, Aug 23, 2019 at 9:43 AM Sanjeev Gupta via devel
wrote:
> We need a point release. Significant things that have happened recently:
>
>
>- The g and G suffixes
>- Removal of neoclock4x
>- Some doc changes
>- The ALPN change
>
> The last is critical, it throws into doubt all
On Sat, Aug 24, 2019 at 2:36 AM Matthew Selsky
wrote:
> Does it make sense to call this 1.2.0 instead of 1.1.7? Especially since
> we have the ALPN compatiblity fix?
>
Yes, please. Although NTS implementation internally has (only trivially)
changed, a bump to 1.2.0 would provide more warning
On Fri, Aug 23, 2019 at 02:12:21PM -0400, Eric S. Raymond via devel wrote:
> Sanjeev Gupta :
> > We need a point release. Significant things that have happened recently:
> >
> >
> >- The g and G suffixes
> >- Removal of neoclock4x
> >- Some doc changes
> >- The ALPN change
> >
>
Sanjeev Gupta :
> We need a point release. Significant things that have happened recently:
>
>
>- The g and G suffixes
>- Removal of neoclock4x
>- Some doc changes
>- The ALPN change
>
> The last is critical, it throws into doubt all the interop we have with
> other NTS
On Fri, Aug 23, 2019, 9:43 AM Sanjeev Gupta via devel
wrote:
> We need a point release. Significant things that have happened recently:
>
>
>- The g and G suffixes
>- Removal of neoclock4x
>- Some doc changes
>- The ALPN change
>
> The last is critical, it throws into doubt all
We need a point release. Significant things that have happened recently:
- The g and G suffixes
- Removal of neoclock4x
- Some doc changes
- The ALPN change
The last is critical, it throws into doubt all the interop we have with
other NTS implementations. We need a tag to describe
20 matches
Mail list logo
