On Tue, Jul 6, 2021 at 1:40 PM Richard Laager via devel
wrote:
>
> On 7/5/21 8:38 AM, Eric S. Raymond via devel wrote:
> >> There is a close-to-RFC to handle this area. "Interleave" is the
> >> buzzword. I
> >> haven't studied it. The idea is to grab a transmit time stamp, then tweak
> >> the
Rust uses cfg attributes for most such things.
https://doc.rust-lang.org/rust-by-example/attribute/cfg.html
On Sun, Jun 20, 2021, 21:12 Hal Murray via devel wrote:
>
> How do Rust and/or Go handle the cruft that C coders use #ifdefs for?
>
> Does that just get pushed down to a C library?
>
>
>
lication of NTS
> From: Watson Ladd
> Date: Tue, 22 Sep 2020 13:02:06 -0400
> To: Hal Murray
> Cc: Susannah Gray , "Karen O'Donoghue" ,
> Patrik Fältström ,
> Miroslav Lichvar ,
> Dieter Sibold ,
> "Langer, Martin
The normative content of the RFC is not going to change. There's no
reason to hold back any release while waiting for publication.
On Fri, Sep 18, 2020 at 11:43 AM Hal Murray via devel wrote:
>
>
> Maybe we should get 1.2 out now/soon so it will be ready when the RFC comes
> out rather than short
clock_gettime is. Adjtimex isn't in any standard except for an obscure RFC
that nobody follows.
On Tue, Aug 25, 2020, 20:47 Eric S. Raymond via devel
wrote:
> Hal Murray via devel :
> >
> > When was clock_gettime and struct timespec introduced?
> >
> > We can cleanup some cruft if we assume it e
It's present on Linux, FreeBSD, NetBSD, and Darwin. It's absent on
Solaris and IllumOS.
On Tue, Aug 25, 2020 at 8:03 PM Hal Murray via devel wrote:
>
>
> When was clock_gettime and struct timespec introduced?
>
> We can cleanup some cruft if we assume it exists.
>
> --
> These are my opinions. I
There's nothing to fix. It's the just optimizer telling you it'd rather not
inline a function that was declared inline. Which is fine, it doesn't
affect correctness.
On Wed, Apr 29, 2020 at 8:32 PM Hal Murray wrote:
>
> What's the right fix for this?
> gcc (GCC) 10.0.1 20200328 (Red Hat 10.0.1-0
Hal,
Yes, we'll be getting a new port number, but the more important item
for IANA is the NTP extension registry. I know NTPsec and several
other NTS implementations are all squatting on a set of EF type
numbers and we probably don't want these to change. You and other
maintainers should coordinat
I've forwarded your message to Watson Ladd.
On Mon, Dec 9, 2019, 17:38 Paul Theodoropoulos via devel
wrote:
> I just noticed that Cloudflare's documentation for NTS -
>
> https://developers.cloudflare.com/time-services/nts/usage/
>
> links to the NTPsec quickstart page -
>
> https://docs.ntpsec.
On Sun, Dec 8, 2019 at 9:15 AM Hal Murray wrote:
> Because ALPN is not supported by TLSv1.2
Nonsense. ALPN predates TLS 1.3 by several years and RFC 7301 doesn't
even restrict it to TLS 1.2 and up; it even can support 1.0.
___
devel mailing list
devel@n
On Sun, Dec 8, 2019 at 7:58 AM Hal Murray via devel wrote:
> The current code now requires ALPN if using TLSv1.3. ***
Why only TLS 1.3? The spec makes it mandatory for all versions.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/m
This is a security bug and needs a point release and a CVE.
On Tue, Oct 29, 2019, 05:06 Hal Murray via devel wrote:
>
> Announcement below.
>
> It triggered a bug. When copying the hostname out of the NTS-KE server
> response, I forgot to add a NUL. I assume we tested that code. I guess
> we
On Mon, Sep 16, 2019, 22:50 Hal Murray via devel wrote:
>
> The disadvantage of SHM is that there is no way to wake up a reader when
> new
> data is available. Readers have to poll.
>
This is exactly what futexes are for.
>
___
devel mailing list
dev
Option 2. If the manufacturer won't support the product any more, we
shouldn't either.
On Thu, Aug 8, 2019 at 8:36 AM Eric S. Raymond via devel
wrote:
>
> Issue #608, "Future need for oncore GPS driver", foregrounds a product
> strategy question we need to make a decision about.
>
> In the early
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.
On Sun, Jun 23, 2019, 16:42 Ian Bruene via devel wrote:
Everything about init scripts should be assumed distro-specific and
'make install' should not be attempting to touch them. Leave that up
to distro packagers.
On Wed, Mar 20, 2019 at 2:57 PM Gary E. Miller via devel
wrote:
>
> Yo Hal!
>
> On Tue, 19 Mar 2019 22:07:26 -0700
> Hal Murray via devel
I recommend having no default at all for the trust store location and
forcing to be set in the config file. Too much risk otherwise of
finding something that looks like a store but isn't actually
trustworthy and entering an insecure state without the user realizing
it. Leave it up to packagers to p
On Tue, Mar 5, 2019 at 2:37 AM Daniel Franke wrote:
>
> I'll post a rebuttal sometime later this week. As for IETF processes,
> though, you're years late. The WG already had a consensus call in 2016
> on what NTS-KE's framing format should look like, and it was
> un
On Thu, Mar 7, 2019 at 5:14 PM Gary E. Miller via devel
wrote:
> Wikipedia makes no mention, even sideways, of /var/local.
>
> Nor does the base document, FHS 3.0:
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
>
> See section 5. "The /var Hierarchy".
It's specified in the tab
On Thu, Mar 7, 2019 at 3:10 PM Gary E. Miller via devel
wrote:
> My idiosyncratic read of the FHS would, by default, put the master keys
> in /usr/local/var/lib:
>
> "State information. Persistent data modified by programs as they run,
> e.g., databases, packaging system metadata, etc. "
I have n
A different RFC, eventually. But I'm not in a rush. Let people managing
large scale deployments figure out what works for them and then standardize
around it later.
On Wed, Mar 6, 2019, 13:25 Achim Gratz via devel wrote:
> Daniel Franke via devel writes:
> > That's correc
On Wed, Mar 6, 2019, 03:33 Hal Murray wrote:
>
> dfoxfra...@gmail.com said:
> > The intended design for running NTS with pool servers is that only the
> pool
> > operator runs an NTS-KE server. The NTS-KE server then picks an
> NTS-enabled
> > NTP server out of the pool and serves you an appropri
Still accurate.
OTOH, OS X finally got clock_gettime() in 10.12.
On Tue, Mar 5, 2019 at 4:28 PM Hal Murray via devel wrote:
>
>
> wscript says MacOS doesn't have it.
>
> timer_create seems pretty basic. Is that still accurate? Or perhaps leftover
> from an old version that is no longer support
On Tue, Mar 5, 2019 at 4:10 PM Hal Murray wrote:
> How does that work in practice? 443 is for HTTPS. Does Apache have a call
> out mode? Is there a standard utility that does ALPN dispatching? What
> fraction of clients send ALPN info?
I've never tried it myself, but I think Nginx can handle
On Tue, Mar 5, 2019 at 2:28 PM Eric S. Raymond wrote:
> Thanks. I didn't see that in the RFC draft. Did I simply miss it or is
> it in a registry that is entirely separate?
Last sentence of section 3, first sentence of section 4, and section 7.2.
___
On Tue, Mar 5, 2019 at 1:52 PM Eric S. Raymond wrote:
> If you end up going with a non-123 port number, I requst that the RFC
> allow use on other ports when and if ALPN is available and specify
> the ALPN tag to be used.
The spec already mandates that ALPN always be used and allocates a tag
with
On Tue, Mar 5, 2019 at 7:21 AM Eric S. Raymond wrote:
> You yourself advocated that Mode 6 ought to be replaced by an HTTP
> service on TCP port 123. I think that's a good idea, if we can do
> it. The problem is than NTS-KE *also* wants to have TCP 123.
Like Hal pointed out, ALPN makes this a non
I'll post a rebuttal sometime later this week. As for IETF processes,
though, you're years late. The WG already had a consensus call in 2016
on what NTS-KE's framing format should look like, and it was
unanimous. You can still comment during IETF Last Call and try to
convince the IESG to block the
On Mon, Mar 4, 2019 at 4:28 PM Gary E. Miller via devel
wrote:
> The name in ntp.conf MUST match the name in the cert. Unless you
> override it ("noval", pin, etc.).
>
> > The normal getaddrinfo and friends automatically follow CNAMEs.
> > Thus my comment about needing some DNS code.
>
> Which o
The intended design for running NTS with pool servers is that only the
pool operator runs an NTS-KE server. The NTS-KE server then picks an
NTS-enabled NTP server out of the pool and serves you an appropriate
NTPv4 Server Negotiation Record. Individual server operators, on a
one-time basis, establi
On Mon, Mar 4, 2019 at 9:25 AM Eric S. Raymond wrote:
> The NTP packet-stamp code dates from the before time, when sampling lag
> due to timeslice granularity was an order of magnitude or more worse
> than it is now. From some of its details I'd guess it was written about
> '87 or '88.
I just ch
9:25 AM Eric S. Raymond wrote:
>
> Daniel Franke :
> > Scheduler timeslices haven't changed much. The current default on
> > Linux is 1ms and it's been that way for a long time. What's changed is
> > that everybody has multicore processors now, so contention almost
19 at 8:36 AM Daniel Franke wrote:
>
> On Sun, Mar 3, 2019 at 9:44 PM Eric S. Raymond wrote:
> > (Also, it turns out not to be important at post-Y2K machine speeds to
> > get those arrival timestamps from the UDP layer ASAP, rather than
> > looking at packet read
On Sun, Mar 3, 2019 at 9:44 PM Eric S. Raymond wrote:
> (Also, it turns out not to be important at post-Y2K machine speeds to
> get those arrival timestamps from the UDP layer ASAP, rather than
> looking at packet read time in userspace. The cost of the latter,
> naive approach is
If you try to measure the cost of the authentication code using log
messages you're going to get total noise, because the cost of logging
a message is higher than the cost of doing the authentication. Each
invocation of AES-SIV should take, in round numbers, 250 CPU cycles,
and processing a typical
On Sun, Mar 3, 2019 at 8:45 AM Kurt Roeckx via devel wrote:
> On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote:
> >
> > k...@roeckx.be said:
> > > If this is something you're worried about, this can be solved with the
> > > interleave mode, which was removed.
> >
> > How well does it wor
On Sat, Mar 2, 2019 at 12:36 PM Gary E. Miller via devel
wrote:
> Yes, but you seriously reduce the attack time window. Instead of
> a possible MitM every few seconds, you need to grab the one time the
> cookies are shared.
No you don't, because a MitM who appears at any time can drop time
packe
On Fri, Mar 1, 2019 at 11:39 PM Gary E. Miller via devel
wrote:
> Not complete security, but at least encryption. And there are
> levels of validation. If you are off net, you can't completely
> validate the cert, but you can partially validate it. Maybe you
> would want to pin it.
Encryption
Which ones do you intend to relax? And in any case you don't need a whole
CA, you can pin a self-signed cert and still do full validation on it.
On Fri, Mar 1, 2019, 23:41 Gary E. Miller via devel
wrote:
> Yo Daniel!
>
> On Fri, 1 Mar 2019 21:26:15 -0500
> Daniel Franke wr
On Fri, Mar 1, 2019 at 7:01 PM Gary E. Miller via devel
wrote:
> "noval" is not mostly for debugging. It is essential for off
> network operation.
There's no point in doing NTS if you're not doing certificate
validation. The result isn't any more secure than unauthenticated NTP.
On Wed, Feb 20, 2019 at 12:48 AM Hal Murray via devel wrote:
> The K and I used to encrypt cookies is a hack constant so old cookies work
> over server reboots.
I assume this is temporary while you work on this code, right?
Obviously if K is a hardcoded constant you have no security.
> With the
Okay, not surprised that's where the breakage was introduced, since
OpenSSL 1.1.0 rearchitected how it handles threading:
https://www.openssl.org/blog/blog/2017/02/21/threads/
Did my commit switching _ANSI_SOURCE to _POSIX_SOURCE resolve the build failure?
On Mon, Feb 18, 2019 at 11:53 PM Hal Mur
You can assume it's a verification failure because "failure in
underlying machinery" shouldn't be possible. The call doesn't allocate
memory and doesn't make any system calls. There's nothing that can
fail.
On Mon, Feb 18, 2019 at 3:53 PM Hal Murray wrote:
>
>
> There is a rough edge that I don't
Try the new HEAD (3562205). I changed ANSI to POSIX.1-2001 which
should hopefully make FreeBSD happy again while still suppressing the
colliding symbols on NetBSD.
What version of OpenSSL are you building against on FreeBSD? I want to
go through sources to figure out exactly why it fails.
On Mon,
The current HEAD of libaes_siv is a release candidate. Whether or not
it becomes the release depends on what I decide to do about the CentOS
6 issue, which in turn depends on the OpenSSL team getting back to me.
I'm also waiting on Hal to run it through his build farm again to let
me know if last-m
The BSDs work the same way Linux does except on FreeBSD the
configuration file is called /etc/ld-elf.so.conf and you run 'ldconfig
-elf' after you've changed it.
Your distribution owns /usr and packages not installed through your
distribution's packaging system shouldn't touch it and should defaul
His problem had nothing to do with waf or ntpd. ld.so.conf is magic
used by the ELF loader to locate the libraries it needs -- at runtime,
not at link time.
On Sat, Feb 16, 2019 at 10:09 AM Eric S. Raymond wrote:
>
> Hal Murray via devel :
> > The symptom is that it links but doesn't run. At run
This is on Linux? Make sure /usr/local/lib is in your /etc/ld.so.conf
and then run ldconfig.
On Sat, Feb 16, 2019 at 9:46 AM Hal Murray wrote:
>
>
> I'm getting closer to actually using it.
>
> Of course, it didn't work or you wouldn't be reading this message.
>
> The symptom is that it links but
Excellent. I just pushed the fix to HEAD.
On Fri, Feb 15, 2019 at 5:54 PM Hal Murray wrote:
>
>
> dfoxfra...@gmail.com said:
> > Hal, try putting
> > #define _ANSI_SOURCE 1
> > #define _ISOC99_SOURCE 1
>
> ...
> [100%] Linking C executable demo
> [100%] Built target demo
> -bash-4.4$ make test
>
this
works for you I'll commit the change.
On Fri, Feb 15, 2019 at 7:49 AM Daniel Franke wrote:
>
> It's exactly like I suspected: a system header is #defining bswap64 as
> a macro, causing a syntax error in my local definition. This is a
> upstream bug twice over. First, no
ce I don't have a NetBSD system and won't be able
to answer any follow-up questions if I file the ticket myself. For the
meantime, I'll probably have to work around the issue by renaming that
function in libaes_siv.
On Thu, Feb 14, 2019 at 11:33 PM Daniel Franke wrote:
>
> This lo
This looks like namespace pollution of some kind -- perhaps one of
NetBSD's standard C headers defining a bswap64 macro that conflicts
with my definition. Can you send me what aes_siv.c looks like on your
system after preprocessing?
I'm not going to support CMake 2, but CentOS has CMake 3 availabl
On Thu, Feb 14, 2019 at 9:15 PM Hal Murray via devel wrote:
> How do I tell it that I don't want the doc?
> (I don't have a2x on that system.)
You shouldn't have to tell it anything. All the manpage
target-generation directives are wrapped in if(A2X). If a2x isn't
found, those targets won't be
Release tags match v.., so just check the tag list for
the most recent v1.y.z. Don't automatically go to 2.anything since releases
are semantically versioned and that would indicate backward-incompatibility.
On Thu, Feb 14, 2019, 17:24 Eric S. Raymond Daniel Franke :
> > You probably
You probably don't want to auto-pull the latest HEAD every time it gets an
update; only releases get the full battery of QA. Note I'll probably be
stamping a release this weekend since the last release from two years ago
has a build issue with more recent OpenSSL versions.
On Thu, Feb 14, 2019, 17
CVE-2018-7182 only.
On Tue, Mar 6, 2018 at 3:10 PM, Richard Laager via devel
wrote:
> I tried this to security-discuss, but I'm not sure if it went through:
>
> The Debian security team has asked me which of the February 2018
> ntp-4.2.8p11 vulnerabilities apply to NTPsec:
>
> http://support.ntp.
On 8/26/17, Hal Murray wrote:
> Is there a good high-level writeup of NTS?
https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-09#section-1.2
> Why encrypt stuff? (as compared to verify)
NTS authenticates everything and encrypts as much as possible without
breaking backward compatibi
There aren't many deficiencies in NTPv4 which can't be fixed by adding
extension fields. A change big enough to make a version bump
worthwhile would incorporate at least most of the following:
1. Drop everything other than client/server mode. Replace mode 6 with
something that runs over HTTPS on t
If we're aiming for a September 28 release then I propose we should
have a dev freeze by September 1. Bug fixes only during that month;
anything that's mere polishing goes on a branch.
I don't want to release 1.0 without having
https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-01
implem
https://developers.google.com/time/smear#standardsmear
On Mar 14, 2017 7:25 AM, "Eric S. Raymond" wrote:
> Hal Murray :
> > It will take me a day or two to clean things up and test some more.
>
> Looking forward to the patch.
>
> > We need to figure out how to test leap seconds.
> >
> > In parti
On 3/13/17, Eric S. Raymond wrote:
> Daniel Franke :
>> I question this prediction. I expect there to be plenty of
>> *newly-manufactured* 32-bit embedded systems for the indefinite
>> future, well beyond 2038. Nobody needs or wants 64 bits to control a
>> coffee po
On 3/13/17, Eric S. Raymond wrote:
> I think so. I'd worry about this more if I thought we were going to be
> running
> on a lot of legacy embedded systems in the *near* future, but by 21 years
> from
> now I seriously doubt a significant fraction of our potential targets will
> be
> 32-bit.
I q
I just tripped over a nasty bug in OpenSSL's CMAC implementation,
present from 1.1.0 onward and now likely to be fixed in 1.1.0f. I
thought I'd give you a heads up in order to save you some sanity when
you're implementing draft-aanchal4-ntp-mac.
https://github.com/openssl/openssl/pull/2798
The bu
On 1/27/17, Mark Atwood wrote:
> Daniel, if we make OpenSSL a requirement, can we drop libsodium?
Yes.
> Daniel, which rev of OpenSSL should we require? (Not 0.9.x et al)
1.0.1 and prior are no longer supported upstream so I'm not going to
make any effort to support them either. I don't think
On 1/27/17, Eric S. Raymond wrote:
> Daniel Franke :
>> Where is this notion coming from that OpenSSL is going to drop MD5 or
>> SHA1
>> support any time soon? That's inconceivable to me.
>
> I think it was either Achim Gratz or Kurt Roecx (I can't ea
Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1
support any time soon? That's inconceivable to me.
On Jan 27, 2017 3:21 PM, "Eric S. Raymond" wrote:
> Mark Atwood :
> > We do need to get wacking on the weeds on removing more of this thicket.
>
> Here are our constraint
On 1/27/17, Mark Atwood wrote:
> Ah, now I get it. They do support new good stuff, they don't support old
> bad stuff.
>
> Daniel, are you suggesting we want to use OpenSSL instead of inline C of
> md5 and sha1 to take advantage of optimized asm and accellerated
> implementations?
Setting aside
Sharon and Aanchal are already working on a better proposal and have
an I-D for it. The new MAC function for legacy authentication
("legacy" as opposed to NTS) is going to be AES-CMAC.
On 1/27/17, Mark Atwood wrote:
> How hard would the following be?
>
> Just go ahead and add SHA256 to NTPsec
> t
On 1/27/17, Mark Atwood wrote:
> If we are going to have an SSL dependency, I have a pretty strong
> preference towards WolfSSL
WolfSSL is full GPLv2 with no or-any-lrater-version provision. Are you
comfortable with having a dependency licensed under those terms?
Possibly more importantly, Wolf
If SHA-0 has ever been used in NTP that's news to me. It was broken pretty
quickly after publication and never saw much use. Pretty sure any
documentation which refers to it is confused.
I would prefer that OpenSSL implementations of primitives get used when
available, for performance reasons whic
On 1/17/17, Sanjeev Gupta wrote:
> On Tue, Jan 17, 2017 at 10:22 PM, Daniel Franke
> wrote:
>
>> Putting it back should be easy if someone can provide me with a working
>> test environment, including a correctly configured Samba servet and a
>> Windows client configure
Putting it back should be easy if someone can provide me with a working
test environment, including a correctly configured Samba servet and a
Windows client configured to talk to it.
On Jan 16, 2017 11:48 PM, "Mark Atwood" wrote:
> I just spent an hour talking with Andrew Bartlett of Catalyist.
Yes, on top of our having mostly dropped symmetric and peer modes,
interleaved mode was never implemented correctly to begin with. It behaved
as though the time at which send() returns was the time when the packet
left the network card, which is an absurd misunderstanding of how OS
kernels work.
I
I wish somebody had mentioned to me that we wrote ntpkeygen in Python
last month so that I could have done a code review. I now have, and
fortunately, it appears as correct as can be for a Python-based
implementation.
But that qualifier is important. I'm not thrilled that we're now
relying on Pyth
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?
> >
On 11/25/16, Achim Gratz wrote:
> Daniel Franke writes:
>> The reference timestamp isn't really used for anything
>
> The server is supposed to return this value unchanged, so one of the BSD
> implementations of the ntp client uses this field to send random data in
> or
On 11/24/16, Eric S. Raymond wrote:
> Daniel Franke :
>> t_1, the origin timestamp, is the time according to the client at
>> which the request was sent.
>> t_2, the transmit timestamp, is the time according to the server at
>> which the request was received.
>> t
On 11/24/16, Eric S. Raymond wrote:
> The Python port of ntpdig is almost ready to land. But there is one last
> little bit of it I'm not sure I understand correctly. I'm requesting
> review
> of my code and assumptions.
>
> Presently the adjustment and synch distance are calculated this way:
>
NTP Classic announced 10 new CVEs yesterday. Of them, six have no
impact on NTPsec:
CVE-2016-9311: Trap crash
CVE-2016-9310: Mode 6 unauthenticated trap information disclosure and
DDoS vector
CVE-2016-7427: Broadcast Mode Replay Prevention DoS
CVE-2016-7428: Broadcast Mode Poll Interval Enforcemen
On 11/1/16, Eric S. Raymond wrote:
> Gary E. Miller :
>> Yo All!
>>
>> More tea leaves to read from ntpwg...
>
> I'm getting a there's-drama-going-on-we-can't-see vibe from this.
Note that Harlan rescinded this erratum the day after he reported it.
No explanation was given. The erratum was illogi
On 10/6/16, Gary E. Miller wrote:
> This is NOT an all or nothing decision. There are other ways to
> mitigate this problem that do not involve major silent breakage.
You've argued this a few times, but you still haven't specified what
you have in mind.
Here's one option that came to mind recen
On 10/6/16, Eric S. Raymond wrote:
> It wouldn't take much to persuade me to drop this 'feature', then.
I still need to re-implement it in the refactored protocol code, but I
see no need to drop it permanently. It's not a lot of code because a
separate daemon (part of Samba) does the heavy liftin
On 10/6/16, Hal Murray wrote:
>> The special case being all Windows boxes.
>
> No, only the ones that use feature xxx. (I don't know what that is. It has
>
> something to do with security and AD (Area Directors?).)
AD is Active Directory. Windows NTP works just fine without MS-SNTP.
The acrony
On 9/30/16, Gary E. Miller wrote:
> So any upward extensible is fine, but trivial back-compatibility is
> essential.
So what do you propose? We currently have insecure defaults. This must
change, and *tautologically*, such a change necessarily involves
breaking backward compatibility somewhere. I
one which will break for very few people.
On 9/30/16, Eric S. Raymond wrote:
> Daniel Franke :
>> With all that said, I'm not actually advocating for removing it,
>> because I want to keep it around to use as a testbed for the
>> DTLS-encapsulated-NTPv4 portion of my NTS
On 9/29/16, Gary E. Miller wrote:
> I use that [peer mode] all the time. Why would someone not? it allows some
> optimizations in the protocol and in the relationship between servers.
Compared to simply making two hosts clients of each other, the only
optimization you get is a 50% reduction in
On Sep 29, 2016 8:22 PM, "Eric S. Raymond" wrote:
>
> Gary E. Miller :
> > > But we have one mission imperative that trumps drop-in replacement:
> > > security. And what makes these modes targets for removal is that,
> > > according to Daniel, there are fundamentally impossible to secure.
> >
> >
On Sep 29, 2016 2:23 PM, "Gary E. Miller" wrote:
> Then maybe a worth while experimment to copy the kernel PLL into ntpd
> to see how it works there?
I can't conceive of how you'd do that. It's too tightly integrated with the
rest of the kernel timing subsystem and other internal kernel APIs.
__
On 9/28/16, Gary E. Miller wrote:
> The knerel PLL and the ntpd userspace PLL are supposed to be using the
> same algorithm and constants. Might be worth checking if the constants
> are still the same.
They aren't. In ntp_loopfilter.c, we have
#define CLOCK_PLL 16. /* PLL loop gain (l
This whole module is a big mess of undefined behavior.
If you're going to store time as a count of nanoseconds, then of
course you're going to overflow a 32-bit integer quickly. 'long' is 32
bits on most 32-bit ABIs. You want all your working variables to be
int64_t. The correct way to express an
On 9/27/16, Gary E. Miller wrote:
> On Tue, 27 Sep 2016 15:16:55 -0400
> Daniel Franke wrote:
>> But in that case, what's the point of using signals?
>
> So the user can also niely terminate a thread. Or so a system shutdown
> can nicely terminate the thread.Or if
On 9/27/16, Gary E. Miller wrote:
> There is more than one way to 'kill' a thread. The nice way is to
> 'kill -HUP', which politely tells the thread to commit seppuku in the
> cleanest way the thread knows how.
Sure, but the default signal handler for that just terminates the
thread immediately
On Sep 27, 2016 15:00, "Eric S. Raymond" wrote:
>
> Hal Murray :
> > man 7 signal has a long list of what you can do in a signal handler.
(all
> > other system calls are unsafe)
> >
> > Is there something similar that applies to killing threads? If so,
where is
> > it documented?
> >
> > For exam
On Sep 27, 2016 14:51, "Hal Murray" wrote:
>
> man 7 signal has a long list of what you can do in a signal handler. (all
> other system calls are unsafe)
>
> Is there something similar that applies to killing threads? If so, where
is
> it documented?
>
> For example, if I kill a thread that is i
In Python, there's a minimal generic interrupt handler which calls
Py_AddPendingCall() to schedule a call to a more complete handler. The
main interpreter loop then calls Py_MakePendingCalls() every few
iterations or on return from any system call. The default behavior for
handling SIGINT is to rai
On 9/24/16, Hal Murray wrote:
> There is also libntp/ntp_calendar.c
> It's used all over the place, mostly for simple date/time conversions, I
> think, for example for setting up the names for log files. I expect some of
> it could be POSIXified. It's also tangled up with leap seconds.
It's tan
On 8/25/16, Eric S. Raymond wrote:
> (Remember that the user story assumes a big hardware budget.)
A big hardware budget should have room for a rubidium GPSDO,
in which case you can get away with freerunning for a lot longer.
___
devel mailing list
deve
Not straightforwardly, but the change you originally proposed months ago
when you first observed this bug was correct AFAICT.
On Aug 24, 2016 8:10 PM, "Eric S. Raymond" wrote:
> Daniel Franke :
> > On 8/24/16, Hal Murray wrote:
> > > That's the easy part. Fir
On 8/24/16, Hal Murray wrote:
> That's the easy part. First we have to understand the code and find the
> bug.
It should already be fixed in my branch. If you wanted to unfix it, at
ntp_proto.c:415 change MDF_ACAST to (MDF_ACAST | MDF_POOL).
___
devel
Updates to previous status:
* Successfully tested authentication.
* Fixed a nasty bug in extension parsing. This was found by
inspection; the feature is still not tested.
* Replaced the missing call to record_raw_stats().
On 7/8/16, Daniel Franke wrote:
> Current status is as foll
1 - 100 of 128 matches
Mail list logo
