e...@thyrsus.com said:
> And by "old stuff" I think you mean specifically Autokey, don't you? To the
> extent I understand these length interactions from having coded the Python
> support, I don't believe either MD5 or SHA-1 MACs are implicated.
I think it's slightly more complicated than that.
Gary E. Miller :
> Eric S. Raymond writes:
> > 1. Performance and algorithm tuning - we need to take a serious
> > swing at Gary's slow-convergence problem, in particular.
>
> My thinking on this has changed a bit. I'm now more concerned about
> the wackiness that happens on startup. And if th
Frank Nicholas :
> If you haven’t seen [Grumpy], you might be interested. Not sure of the
> quality (experimental?)
>
> Google boosts Python by turning it into Go:
Yes, Gary turned me on to this earlier in the week. Grumpy is extremely
interesting, as a path forward for reposurgeon if not fo
Eric!
Eric S. Raymond writes:
> 1. Performance and algorithm tuning - we need to take a serious
> swing at Gary's slow-convergence problem, in particular.
My thinking on this has changed a bit. I'm now more concerned about
the wackiness that happens on startup. And if that is solved then
(re)
>
>>> 3. Move the codebase to Go or Rust?
>>
>> While I understand what kind of problem you're trying to solve, at the
>> moment I see neither of those two languages survive for long if their
>> current parent projects change course (again).
>
> I'm not worried about that for Go, because Google
Sanjeev Gupta :
> Would you consider Julia ?
Alas, a perfect example of a language excluded from present consideration
because the developer and userbase is below the threshold that says
long-term sustainability.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
On Sun, Jan 8, 2017 at 9:32 PM, Eric S. Raymond wrote:
> ractically speaking, I don't have time to become fluent in half a dozen
> candidate languages. I can probably budget time for one more beyond Go
> and Rust; Erlang actually seems like a strong contender there.
>
Would you consider Julia ?
Hal Murray :
>
> > > That sounds uncomfortably plausible. I can think of a workaround: add a
> > > padding extension long enough that the packet can't have any of the magic
> > > lengths.
> > I've read that. I've even implemented it myself once, in the Python
> > protocol back end. Is there ad
> > That sounds uncomfortably plausible. I can think of a workaround: add a
> > padding extension long enough that the packet can't have any of the magic
> > lengths.
> I've read that. I've even implemented it myself once, in the Python
> protocol back end. Is there advice in there that I miss
Mark: Heads up! Serious discussion of language migration follows.
Achim Gratz :
> Eric S. Raymond writes:
> > 1. Performance and algorithm tuning - we need to take a serious swing
> > at Gary's slow-convergence problem, in particular.
>
> This objective needs to be defined more properly.
Agreed.
Hal Murray :
>
> [extension fields]
> > That sounds uncomfortably plausible. I can think of a workaround: add a
> > padding extension long enough that the packet can't have any of the magic
> > lengths.
>
> Here is the RFC on that area.
>
> Network Time Protocol Version 4 (NTPv4) Extension Fie
Eric S. Raymond writes:
> 1. Performance and algorithm tuning - we need to take a serious swing
> at Gary's slow-convergence problem, in particular.
This objective needs to be defined more properly. At the moment I'm not
all that convinced that this is a real defect considering the guarantees
tha
[extension fields]
> That sounds uncomfortably plausible. I can think of a workaround: add a
> padding extension long enough that the packet can't have any of the magic
> lengths.
Here is the RFC on that area.
Network Time Protocol Version 4 (NTPv4) Extension Fields
March 2016
https://tools.ie
Kurt Roeckx :
> So 1 question I have is if you care about Windows or not.
We do, though not urgently.
Some googling indicates that Windows supports wildcard sockets. Do you know
how to do source- and destination-address extraction in that environment?
--
http://www.catb.org/~esr
Hal Murray :
>
> > The successful scalarization of both 64-bit timestamp types has now been
> > achieved. There's a draft about how this was done in the blog repo:
> > _drafts/
> > cant-we-all-just-get-a-long.ad
>
> How much testing has been done?
If you're running any pull from the last thre
On Fri, Jan 06, 2017 at 11:43:01PM -0500, Eric S. Raymond wrote:
> (mutt hiccupped. You might see this twice.)
>
> Kurt Roeckx :
> > On Fri, Jan 06, 2017 at 12:14:35PM -0500, Eric S. Raymond wrote:
> > > and the other is ripping out all
> > > the interface-scanning stuff so we lose the dependency
> The successful scalarization of both 64-bit timestamp types has now been
> achieved. There's a draft about how this was done in the blog repo: _drafts/
> cant-we-all-just-get-a-long.ad
How much testing has been done?
TESTFRAME would have helped for this sort of change.
I know about l_fp. W
>> Only if they correctly ignore extensions that they don't expect.
> What would "not ignoring" look like?
If length != 48: Goto Reject
> That could be. If it is, we're in the "must design NTPv5" future. But I
> don't think we'll know whether we're there unless we field a more
> conservative d
>> 17 Nov 03:28:16 ntpd[12949]: Listen and drop on 0 v6wildcard [::]:123
>> 17 Nov 03:28:16 ntpd[12949]: Listen and drop on 1 v4wildcard 0.0.0.0:123
> That means those aren't being processed, I gather.
I assume so, but I haven't checked the code.
I was going to try a broadcast packet, but ...
[r
Hal Murray :
>
> e...@thyrsus.com said:
> > Remember that the code *already* uses wildcard addresses as fallbacks, so
> > any security issues these raise have already been present for a long time.
>
> >From the log file:
>
> 17 Nov 03:28:16 ntpd[12949]: Listen and drop on 0 v6wildcard [::]:123
Hal Murray :
>
> e...@thyrsus.com said:
> > I think the solution for this is obvious. We define an extension type the
> > contents of which, if it exists, SHOULD be used as the refid.
> > Implementations that don't know about that extension will be no worse off
> > than before.
>
> Only if they
e...@thyrsus.com said:
> Remember that the code *already* uses wildcard addresses as fallbacks, so
> any security issues these raise have already been present for a long time.
>From the log file:
17 Nov 03:28:16 ntpd[12949]: Listen and drop on 0 v6wildcard [::]:123
17 Nov 03:28:16 ntpd[12949]:
Hal Murray :
> There is an interface command in ntp.conf, and the man page refers to -I and
> -L command line options, both deprecated.
Yes, I was planning to remove these.
> I think we need to be careful here. Unless we understand what's really going
> on we are likely to break something, and
e...@thyrsus.com said:
> I think the solution for this is obvious. We define an extension type the
> contents of which, if it exists, SHOULD be used as the refid.
> Implementations that don't know about that extension will be no worse off
> than before.
Only if they correctly ignore extensions
e...@thyrsus.com said:
>>> and the other is ripping out all
>>> the interface-scanning stuff so we lose the dependency on
>>> getifaddrs(3) and use wildcard interfaces only.
>> Are you sure this is going to work? As far as I know there are (or
>> were) good reasons to do this, but I can't remembe
Hal Murray :
> We should start a list of the things that need fixing/changing [in IPv5].
>
> Maybe a file in devel/ ?
Reasonable.
> There is one quirk that comes up occasionally. The RefID only has room for
> an IPv4 address. IPv6 addresses need hashing. That's not a serious problem
> and y
(mutt hiccupped. You might see this twice.)
Kurt Roeckx :
> On Fri, Jan 06, 2017 at 12:14:35PM -0500, Eric S. Raymond wrote:
> > and the other is ripping out all
> > the interface-scanning stuff so we lose the dependency on
> > getifaddrs(3) and use wildcard interfaces only.
>
> Are you sure this
On Fri, Jan 06, 2017 at 12:14:35PM -0500, Eric S. Raymond wrote:
> and the other is ripping out all
> the interface-scanning stuff so we lose the dependency on
> getifaddrs(3) and use wildcard interfaces only.
Are you sure this is going to work? As far as I know there are (or
were) good reasons to
e...@thyrsus.com said:
>> Is there any online doc about IETF progress on NTPv5?
> So far there isn't any, because (at least to my knowledge) there aren't any
> IPv5 drafts on the table.
We should start a list of the things that need fixing/changing.
Maybe a file in devel/ ?
There is one quirk
Gary E. Miller :
> Is there any online doc about IETF progress on NTPv5?
So far there isn't any, because (at least to my knowledge) there aren't
any IPv5 drafts on the table.
--
http://www.catb.org/~esr/";>Eric S. Raymond
signature.asc
Description: PGP signature
There isn't any progress to be reported: no proposals and no plans to
produce or entertain any.
On Jan 6, 2017 3:36 PM, "Gary E. Miller" wrote:
> Yo Eric!
>
> On Fri, 6 Jan 2017 15:29:37 -0500
> "Eric S. Raymond" wrote:
>
> > > How does NTPsec intend to coordinate with Classic about NTPv5?
> >
Yo Eric!
On Fri, 6 Jan 2017 15:29:37 -0500
"Eric S. Raymond" wrote:
> > How does NTPsec intend to coordinate with Classic about NTPv5?
>
> Through IETF.
Is there any online doc about IETF progress on NTPv5?
RGDS Veritas liberabitvos
GARY
Royce Williams :
> I've seen Harlan refer to NPTv5 protocol changes as well:
>
> http://seclists.org/nanog/2016/Dec/307
>
> A code fork is one thing; a protocol fork is something else entirely.
>
> How does NTPsec intend to coordinate with Classic about NTPv5?
Through IETF.
--
On Fri, Jan 6, 2017 at 8:14 AM, Eric S. Raymond wrote:
> The successful scalarization of both 64-bit timestamp types has now
> been achieved.
Most excellent! From my vantage point in the peanut gallery, it's been
a fascinating and inspiring show.
[snip]
> 7. NTPv5? Maybe a new base protocol, m
The successful scalarization of both 64-bit timestamp types has now
been achieved. There's a draft about how this was done in the blog
repo: _drafts/cant-we-all-just-get-a-long.ad
This brings us to an interesting place. I can't say the C cleanup
work is done yet, but that point is now visible in
35 matches
Mail list logo
