The Southeast Linux Fest will be June 8-10th. It appears that 1.2 is
scheduled for June 15th.
Would it not be better to schedule it for the 5th or so, giving room for
a couple days delay while still being able to say "We just shipped 1.2"
at SELF?
--
/"In the end; what separates a Man,
On 03/01/2018 07:40 PM, Hal Murray via devel wrote:
Mark Atwood said:
ntpsnmpd should be it's own Debian package, please. It's useful to both
NTPsec and to NTP Classic installations.
Has anybody tried it with NTP Classic? Do we have a classic server running
that we can test against?
On 03/02/2018 03:47 PM, Hal Murray via devel wrote:
It wouldn't surprise me if we had added something interesting. I'm pretty
sure I have added things. The only question is did we fill in a gap in
classic and/or will ntpsnmpd do the right thing if it encounters something
like that.
On 02/26/2018 06:13 PM, Sanjeev Gupta via devel wrote:
Hi,
For what it is worth, I am running the ntpsnmpd code on a number of
debian and ubuntu machines for some time, including one with an actual
GPS. No issues so far.
I just like to see graphs.
Hooray! Someone is using the code!
1.
On 02/26/2018 09:50 AM, Mark Atwood via devel wrote:
Does waf build it by default?
Does the Debian packaging have it be it's own package?
It is built as part of the other python utilities. The manpage isn't
part of the build yet as I do not know which section it should go in.
--
/"In the
On 02/25/2018 07:18 PM, Hal Murray via devel wrote:
Is there a HOWTO that tells me how to set things up?
I'll get to work on that.
There may be two targets for that document. One is SNMP wizards who don't
know much about ntpd. The other is NTP wizards who don't know much about
SNMP.
While waiting for the NTS holding pattern I'm going to take another look
at the recvbuff removal.
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
Man Chooses, a Slave Obeys."/ -- Andrew Ryan
/"Utopia cannot precede the Utopian. It will exist the moment we are fit
On 10/31/18 2:07 AM, Eric S. Raymond wrote:
Ian Bruene via devel :
On 10/30/18 3:32 PM, Mark Atwood, Project Manager via devel wrote:
Looks straightforward enough. Ian?
Will look into in a little while.
Invoke me if you run into trouble, but this should be pretty sreaightforward.
Gary
On 10/31/18 6:08 AM, Ian Bruene wrote:
While waiting for the NTS holding pattern I'm going to take another
look at the recvbuff removal.
It seems that I missed where SINGLEBUFFER already happened. Taking a
poke at the python code instead; maybe there is some cleanup that can
happen
On 10/30/18 3:32 PM, Mark Atwood, Project Manager via devel wrote:
Looks straightforward enough. Ian?
Will look into in a little while.
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
Man Chooses, a Slave Obeys."/ -- Andrew Ryan
/"Utopia cannot precede the
On 08/31/2018 09:44 AM, Ian Bruene wrote:
On 08/30/2018 11:50 PM, Gary E. Miller via devel wrote:
Oh, most certainly on shutdown.
Do you have a recipe to reproduce? Or does it happen every time?
So far I have not been able to reproduce this on my system. Still digging.
--
/"In the end;
On 08/30/2018 11:50 PM, Gary E. Miller via devel wrote:
Oh, most certainly on shutdown.
Do you have a recipe to reproduce? Or does it happen every time?
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
Man Chooses, a Slave Obeys."/ -- Andrew Ryan
/"Utopia cannot
I'm told that there is a document written by the resident crypto expert
describing NTS. Does anyone have it? We might need to see it if we are
planning on implementing what is in it you know...
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
Man Chooses, a Slave
On 01/06/2019 02:55 PM, Gary E. Miller via devel wrote:
Seems to me that Section 6 of the proposed RFC defines this pretty well.
Once you can figure out who Clarlie (NTPD) and Delta (NTS-KE) are.
Partially. It gives an example of a way to do it, but no protocol or
message scheme; just what
On 01/06/2019 04:57 PM, Gary E. Miller via devel wrote:
That is the one option that has been universally shot down as bad.
I'm not sure what option you refer to. Best in discussions like these to
keep indirection to a minimum.
The one I had just been talking about as being implied by the
Fwd because I hit the wrong reply button.
Forwarded Message
Subject:Re: Let's get moving on NTS
Date: Sun, 6 Jan 2019 14:20:25 -0600
From: Ian Bruene
To: Eric S. Raymond
On 01/06/2019 01:38 PM, Eric S. Raymond via devel wrote:
So I think my job for the
On 01/06/2019 05:11 PM, Gary E. Miller via devel wrote:
Which is a big doc, so I'm still not sure which part we are talking
about here...
/devel/nts.doc is a new, and currently very small, file.
You are thinking of the NTS draft.
That is a bad way to think of this. What you call
On 1/17/19 11:35 AM, Eric S. Raymond via devel wrote:
I see no Bravo-to-Alpha initiation of requests, though there are
responses heading in that direction.
I think everyone has been treating Alpha and Bravo as the same entity.
Similarly, I see no Delta-to-Bravo initiation of requests,
On 1/17/19 2:00 PM, Eric S. Raymond wrote:
Ian Bruene via devel :
Charlie requests a master key (and possibly initial cookies) daily
from Delta.
Cookies wouldn't be part of that. For a start "once a day" would have the
cookies up to tens of thousands of packets out of date (assumin
*Ahem* R...
You are both talking past each other.
There are two key sets:
The c2s/s2c pair. Generated *BY* the TLS exchange between the client and
the NTS-KE server. Stored inside the cookie. Used to encrypt data
between server and client NTPDs thereby eliminating the need for a
On 1/17/19 7:11 PM, Hal Murray via devel wrote:
Do both NTP-server and NTS-KE-server have to know the new-cookie recipe? Does
NTS-KE-server need the master key for anything other than generating cookies?
Does it work if only the NTP-server has the master key and the NTS-KE-server
gets cookies
I know of these keys that exist within NTS:
* client-to-server (c2s)
* server-to-client (s2c)
* server master key
The master key is shared between NTPD and NTS-KE (mechanism currently
undecided). It is used to encrypt data in cookies and is never seen
outside of the NTPD/NTS-KE pair. *The
On 09/14/2018 01:21 PM, John D. Bell via devel wrote:
This is a test message to the mailing list, to diagnose apparent
failure to deliver, etc.
It can safely be ignored.
Pong
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
Man Chooses, a Slave Obeys."/ --
(test)
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
Man Chooses, a Slave Obeys."/ -- Andrew Ryan
/"Utopia cannot precede the Utopian. It will exist the moment we are fit
to occupy it."/ -- Sophia Lamb
I work for the Internet Civil Engineering Institute
On 09/17/2018 04:53 PM, Hal Murray via devel wrote:
If they are written in Go, they are compiled to binary executables, and you
do not need Python (nor a Go compiler) to run them.
Thanks. But we still need libraries. What makes the Python
interpreter/whatever different from a library?
Go
On 09/17/2018 12:34 PM, Eric S. Raymond via devel wrote:
2. PYTOGO
We now have a goal of moving all our client-side code from Python to Go.
Benefits: (1) banish the horror that is Python library directories, (2)
remove a run-time dependency for operators, (3) build competence and
Is there any particular reason why SSL structs need to be passed all
over the place to functions that do not depend on SSL itself?
The notable example here is nts_ke_do_recieve, which only uses the SSL
to pass to SSL_read. I don't see any obvious reason that couldn't be
done in the calling
On 4/1/19 12:00 AM, Hal Murray via devel wrote:
There is some cleanup I've wanted to do in that area anyway. I'll try to get
to it tonight.
Noted, will wait before stirring it up.
Only that it seemed reasonable at the time. I was more interested in getting
things working than how to test
After staring at the code for long enough I see a number of natural
cleavage points for solving this issue. MR in a few days.
On 3/31/19 2:33 PM, Ian Bruene wrote:
Is there any particular reason why SSL structs need to be passed all
over the place to functions that do not depend on SSL
On 3/2/19 9:42 AM, Eric S. Raymond via devel wrote:
REFCLOCKD benefits way down, cost almost unchanged. Every time I model
this in my head the same answer comes out: bad idea. I think we have
better complexity-reduction attacks available, like translating the
whole thing to Go to get rid of a
Someone wondered what the changes in draft 16 were. Aside from date
update miscellanea the only change is in section 9.3.
This paragraph:
Do not process time packets from servers if the time computed from
them falls outside the validity period of the server's
certificate.
After looking at the cookie creation code I don't understand how a
server is supposed to extract the keys contained within. It would not
have the data to de-xor the contents of the cookie when presented with
said cookie.
Unless this is just a placeholder?
int make_cookie(uint8_t *cookie,
On 2/1/19 3:53 PM, Eric S. Raymond via devel wrote:
What is the natural kind in which "nts" is an alternative to "server",
"pool", and "refclock"? If there is such a kind, how does that square
with the possibility that "nts" may become a property of pool request
instances?
Possibly if nts
On 6/16/19 7:47 AM, Eric S. Raymond via devel wrote:
Yes, a triage run is near the top of my to-do list. Expect to see some results
on that by midweek.
Do you cansider the NTS documentation to be in good shape?
I have a branch with a large number of NTS tests that has been sitting
in
On 6/19/19 5:28 PM, Eric S. Raymond via devel wrote:
I'd like to see two different kinds of responses to this provocation.
1. Are there blockers on the road to Go?
2. No, there's something else more important to do first.
Before any general push to Go happens there needs to be either a
On 6/23/19 4:09 PM, Daniel Franke wrote:
The translation of the AEEF ciphertext into corresponding plaintext is
given by the negotiated AEAD algorithm; for AES-SIV, by RFC 5297. The
structure of the plaintext is defined in the draft, as a concatenation
of RFC 7822 extension fields.
This
Nevermind: I figured out what I failed to understand.
The handlers that use CMAC and are size locked are on the client to
server path. The server to client path *does* allow for additional data.
Nothing to see here, move along.
--
/"In the end; what separates a Man, from a Slave? Money?
While working on the NTS test code I have reached a point where I know
that I am misunderstanding *something*, but do now know what.
According to the RFC the AEEF "ciphertext" field looks like it is a
generally usable data blob for extension data. Variable size, no
specific data, etc.
On 4/23/19 9:47 PM, Gary E. Miller via devel wrote:
And that is how cruft grows...
I only disabled them at the time of my test push because I didn't
understand what they were. With that understanding I can now remove them
entirely.
--
/"In the end; what separates a Man, from a Slave?
In trying to write tests for nts_client.c I have run into a problem I do
not know how to solve, as it involved much of the structure of the
codebase as well as the build system.
Some of the code in nts_client.c calls the dns_take* series of
functions. These functions are defined in
The hack worked.
On 4/23/19 9:31 PM, Hal Murray via devel wrote:
There is at least one other place where the test routines have a routine to
keep the linker happy, but I can't think of what it is.
When it was mentioned I remembered seeing that in the nts.c tests.
Ironically I had to
On 8/28/19 1:26 PM, Hal Murray wrote:
Merge Request !1026 was merged
The Subject says "Converted stat_count struct to a module level global"
The code looks like it is un-struct-ing things.
Was that "a module level global" supposed to be "module level globals"?
!1026 moves the variables
On 8/29/19 4:36 PM, Gary E. Miller via devel wrote:
Hal you are corect. Page 140, section 6.7.9 Initialization.
"If an object that has static or thread storage duration is not initialized
explicitly, then:
[...]
-- if it has arithmetic tye, it is initialized to (positive or unsigned)
zero;"
On 8/29/19 3:46 PM, Eric S. Raymond wrote:
By "floating", you mean uninnitialized? In C that's going to mean it's false
Yes. My understanding of C is that anything not explicitly set has
whatever random value happens to be in that memory location. Possibly
changed if certain unknown
The other day I determined that the flag disable_dynamic_updates
(currently in the io_data struct) is either not properly initialized, or
is blocking off a large chunk of dead code. After reading through the
relevant code and looking through the history I think it is the former:
The flag is
I have been trying to write tests for the NTS packet extension code in
nts_extens.c. Almost all of the functions end up needing to encrypt or
decrypt something. It is simple enough to feed in random data for
encryption, but for decryption the various keys and other data needs to
match up.
Question obsolete; I was mixing up some details.
On 6/30/19 12:35 PM, Ian Bruene wrote:
I have been trying to write tests for the NTS packet extension code in
nts_extens.c. Almost all of the functions end up needing to encrypt or
decrypt something. It is simple enough to feed in random data
On 11/20/19 5:44 PM, Hal Murray via devel wrote:
Part of the problem is that there is a lot of cruft in that area. For
example, grep for CERR_
There is a clump of signals defined as part of a ControlSession, none are ever
raised, a few are caught. Looks like somebody decided to rename things
After a great deal of refactoring, digging, confusion, and generalized
wrestling with the surprising number of tentacles that comprise the
mrulist system I can now make a report of sorts:
*Error handling expected by the protocol:*
* If there is no overlap between the requested entries and
101 - 149 of 149 matches
Mail list logo
