You can also try fudging it by 1024*7*24*60*60
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
On 2/4/19 3:58 PM, Hal Murray via devel wrote:
> What's wrong with just adding 2000 to 2 digit years? We are in the 2000s now
> so we don't have to consider the 1900 case any more. I'd be happy to
> reconsider dropping support for 2-digit drivers in another 30 years.
>
> There is another
Hal Murray :
>
> e...@thyrsus.com said:
> > Don't you think it makes sense to very our client code against a known-good
> > implementation first, though?
>
> Maybe. Maybe not.
>
> If we had a known-good server and somebody who was sitting next to me knew
> all
> about it and was prepared to
On 2/5/19, Eric S. Raymond via devel wrote:
> Hal Murray :
>>
>> > 2. Put together client-side NTS support. This mainly means filling in
>> >ntpd/nts.c, as I have already written required the hooks into the
>> >protocol machine.
>>
>> We need code to generate cookies. And test code to
Hal Murray :
>
> > 2. Put together client-side NTS support. This mainly means filling in
> >ntpd/nts.c, as I have already written required the hooks into the
> >protocol machine.
>
> We need code to generate cookies. And test code to pack, encrypt, decrypt,
> and unpack. (No byte
> 2. Put together client-side NTS support. This mainly means filling in
>ntpd/nts.c, as I have already written required the hooks into the
>protocol machine.
We need code to generate cookies. And test code to pack, encrypt, decrypt,
and unpack. (No byte swapping - we get back what
e...@thyrsus.com said:
> Don't you think it makes sense to very our client code against a known-good
> implementation first, though?
Maybe. Maybe not.
If we had a known-good server and somebody who was sitting next to me knew all
about it and was prepared to help debug, sure that would be a
Hal Murray :
>
> e...@thyrsus.com said:
> > I think we'd best completely avoid writing an NTS-KE server until we have
> > tested our client side against one of the two existing server
> > implementations.
>
> Then we have to learn how to drive the existing implementations, and learn
> enough
e...@thyrsus.com said:
> I think we'd best completely avoid writing an NTS-KE server until we have
> tested our client side against one of the two existing server
> implementations.
Then we have to learn how to drive the existing implementations, and learn
enough about how they operate so we
Hal Murray :
> > In fact, it's not strictly speeking something we need to fix until we're
> > worrieed about using a C library other than glibc. It does some weird things
> > under the hood to make stdio operations thread-safe.
>
> msyslog is mostly not stdio so that won't help much.
I see the
> Please open an issue. It's not something I can give priority to at the
> moment.
Done.
> In fact, it's not strictly speeking something we need to fix until we're
> worrieed about using a C library other than glibc. It does some weird things
> under the hood to make stdio operations
We have a number of tasks ahead of us, and I'm hoping for volunteers
to step up. I can't do all the code myself; I expect to have plenty on
my plate documenting things, being everybody's utility coder for the
interfaces between NTS and the rest of NTPsec, and reviewing code.
The tasks:
1.
On 2/4/19 3:40 PM, Hal Murray via devel wrote:
> At shutdown probably isn't good enough. You don't get clean shutdowns on a
> site wide power loss. Maybe shutdown and a weekly/monthly cron job.
Sure, that's a fair point. I'm not sure what the default behavior is on
Raspberry Pi systems.
> Are
On 2/4/19 12:07 PM, Hal Murray via devel wrote:
> Another complication with getting started after a building/site wide power
> loss is that getting time needs DNS and the local caching DNS server may be
> waiting for valid time.
The resolver really shouldn't be waiting for network time, as
Hal Murray :
>
> Eric:
> > I plan to post a detailed analysis and task list later today. I'm working
> > on
> > that now.
>
> I have hack code that makes a TLS connection and verifies certificates.
>
> If/when things calm down, I'll start folding it in.
If that was going to go into nts.c
Hal Murray :
> Please make sure this gets on your list. Do you have a list for NTS or
> should
> I make an issue for it?
Please open an issue. It's not something I can give priority to at the
moment.
In fact, it's not strictly speeking something we need to fix until we're
worrieed about
Thanks.
Please make sure this gets on your list. Do you have a list for NTS or should
I make an issue for it?
I haven't looked at the code recently. This seems like a good opportunity for
a review and cleanup and/or the addition of a good comment discussing the
thread area.
I think the
Eric:
> I plan to post a detailed analysis and task list later today. I'm working on
> that now.
I have hack code that makes a TLS connection and verifies certificates.
If/when things calm down, I'll start folding it in.
ntpd/ntpd.c has a main() in it.
Is the plan to have NTS-KE-server
Hal Murray via devel writes:
> One thing that would be very nice is for msyslog to be thread safe.
>
> If we use a lock, we need to be able to recover in case we crash within
> msyslog while the lock is held.
>
> I'm not enough of a Unix file system wizard. Are there any guarantees about
>
Hal Murray :
> I'm not enough of a Unix file system wizard. Are there any guarantees about
> multi-threaded writes to the same file not getting scrambled? Will it work
> if
> we buffer everything into a big buffer and do a single write?
Under Linux, yes, up to 4096 bytes. Look for "I wrote a
> I plan to post a detailed analysis and task list later today. I'm working on
> that now.
One thing that would be very nice is for msyslog to be thread safe.
If we use a lock, we need to be able to recover in case we crash within
msyslog while the lock is held.
I'm not enough of a Unix
Achim Gratz via devel :
> Matthew Selsky via devel writes:
> > See https://www.ntpsec.org/drivers.html
> >
> > INACCURATE
> > Remove GPS drivers and time radios for which the hardware offers no
> > better source accuracy than a timing GPS available for less than $75
> > in 2015; that is, about
Yo Achim!
On Tue, 05 Feb 2019 19:56:07 +0100
Achim Gratz via devel wrote:
> Eric S. Raymond via devel writes:
> > Achim Gratz via devel :
> >> I visited DEC in Palo Alto one time and got to see the very first
> >> Alpha mainboard (with an alcohol heatpipe made from a glass tube
> >> atop the
Matthew Selsky via devel writes:
> See https://www.ntpsec.org/drivers.html
>
> INACCURATE
> Remove GPS drivers and time radios for which the hardware offers no
> better source accuracy than a timing GPS available for less than $75
> in 2015; that is, about 5µs. (However, do not necessarily remove
Eric S. Raymond via devel writes:
> Achim Gratz via devel :
>> I visited DEC in Palo Alto one time and got to see the very first Alpha
>> mainboard (with an alcohol heatpipe made from a glass tube atop the
>> CPU).
>
> Damn shame about the Alpha. That was a good design that DEC utterly botched
>
Eric S. Raymond via devel writes:
> Achim Gratz via devel :
>> You can have all these errors with four digit years.
>
> Of course we can. I'm not claiming that disqualifying these sources
> with 2-digit year reports will solve the problem, just reduce the
> number of failure modes and the
I've been quiet about the NTS work for the last couple of days
because, off-list, I was trying to recruit the person who cooperated
with Daniel on the draft RFC and write the first server implementation
to do our client-side code.
Had I succeeded, that would have changed our planning a lot. Alas,
27 matches
Mail list logo
