Re: Interleaved Mode (Was: Re: Using Go for NTPsec)

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 > >>

Re: #ifdef cruft in Go/Rust

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? > > >

Re: Blog announcing NTS

cation 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" , &

Re: Release gymnastics

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

Re: Has anybody seen a system without STA_NANO?

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

Re: Has anybody seen a system without STA_NANO?

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.

Re: warnings from libaes on Fedora 32

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

Re: [Ntp] Last Call:

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

Re: cloudflare refers NTS users to wrong page

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 - > >

Re: [PATCH] ALPN validation fix

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

Re: [PATCH] ALPN validation fix

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

Re: Another server at Netnod, bug fix

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

Re: Future directions

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

Re: Driver strategy - we need to decide among incompatible goals

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

Re: NTS AEEF extension confusion

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

Re: Installing ntpd.service

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

Re: NTS: config and initialization

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

Re: How not to design a wire protocol

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 > unanimous. You ca

Re: Tangle - cookie keys file

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

Re: Tangle - cookie keys file

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

Re: What's left to doo on NTS

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 correct: ensurin

Re: What's left to doo on NTS

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

Re: timer_create

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

Re: How not to design a wire protocol

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

Re: How not to design a wire protocol

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. ___

Re: How not to design a wire protocol

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

Re: How not to design a wire protocol

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

Re: How not to design a wire protocol

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

Re: What's left to doo on NTS

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

Re: What's left to doo on NTS

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,

Re: SO_TIMESTAMP may go away

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

Re: SO_TIMESTAMP may go away

. 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 > > never happens. >

Re: SO_TIMESTAMP may go away

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 tim

Re: SO_TIMESTAMP may go away

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

Re: SO_TIMESTAMP may go away

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

Re: What's left to doo on NTS.

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

Re: What's left to doo on NTS

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

Re: What's left to doo on NTS

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

Re: What's left to doo on NTS.

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 wrote:

Re: What's left to doo on NTS.

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.

Re: NTS off the ground - time for testing

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

Re: libaes_siv release candidate

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

Re: libaes_siv release candidate

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

Re: libaes_siv release candidate

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

libaes_siv release candidate

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

Re: linking to libaes_siv

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

Re: linking to libaes_siv

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

Re: linking to libaes_siv

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

Re: Setting up libaes_siv

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 >

Re: Setting up libaes_siv

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, nothing shou

Re: Setting up libaes_siv

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 looks like namespace pollution of some kind -- perha

Re: Setting up libaes_siv

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

Re: Setting up libaes_siv

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

Re: The libaes_siv dependency

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 don'

Re: The libaes_siv dependency

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,

Re: ntpsec vulnerabilities / latest ntp round

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: > >

Re: Blue-sky thread - ideas for well after 1.0

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

Re: Blue-sky thread - ideas for well after 1.0

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

Re: Future of 32 bit time_t?

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

Re: Future of 32 bit time_t?

On 3/13/17, Eric S. Raymond <e...@thyrsus.com> wrote: > Daniel Franke <dfoxfra...@gmail.com>: >> 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

Re: Future of 32 bit time_t?

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

Re: Current status of --enable-crypto

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

Re: Current status of --enable-crypto

On 1/27/17, Eric S. Raymond <e...@thyrsus.com> wrote: > Daniel Franke <dfoxfra...@gmail.com>: >> 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 Ac

Re: Current status of --enable-crypto

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

Re: Crypto tangle

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 >

Re: Hash function support, MD5 / SHA256, strawman proposal

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

Re: Current status of --enable-crypto

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

Re: the MSNTP feature and author, Andrew Bartlett

On 1/17/17, Sanjeev Gupta <gha...@gmail.com> wrote: > On Tue, Jan 17, 2017 at 10:22 PM, Daniel Franke <dfoxfra...@gmail.com> > wrote: > >> Putting it back should be easy if someone can provide me with a working >> test environment, including a correctly configu

Re: the MSNTP feature and author, Andrew Bartlett

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

Re: Replacing C

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.

Re: ntpkeygen patch

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

Re: The end of the beginning is in sight

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

Re: Request for code & logic review

On 11/25/16, Achim Gratz <strom...@nexgo.de> 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 sen

Re: Request for code & logic review

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

Re: Incompatible changes, security, and good practice

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

Re: [time-nuts] Need Time Help

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)

Re: Killing threads

On 9/27/16, Gary E. Miller <g...@rellim.com> wrote: > On Tue, 27 Sep 2016 15:16:55 -0400 > Daniel Franke <dfoxfra...@gmail.com> 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 s

Re: Killing threads

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

Re: Killing threads

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,

Re: Killing threads

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

Re: How does ^C work in Python?

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

Re: Word size assumptions

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

Re: Stratum one autonomy and assumptions about GPS

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. ___

Re: Please abuse my proto-refactor branch while I'm gone

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 <dfoxfra...@gmail.com> wrote: > Curre

Re: Requesting code review on possible fix for nopeer/pool conflict

On 7/5/16, Hal Murray wrote: > The problem is that the ramp up on polling interval is happening on > refclocks. Maybe only on PPS refclocks. And the intended behavior is that refclocks should always stay at the minimum polling interval? Okay, I'll keep that in mind as I

Re: Requesting code review on possible fix for nopeer/pool conflict

On 7/5/16, Hal Murray wrote: > Please don't push any big changes until Eric and/or I get the polling tangle > fixed. I'm doing my work in a branch for the time being, so we can merge later. Anyway, I've completely rewritten the receive() and process_packet() functions

Re: Requesting code review on possible fix for nopeer/pool conflict

On 7/5/16, Eric S. Raymond wrote: > Hal's bug report reads like this: > > restrict nopeer kills using the pool command. (Try it.) The symptom is > that no slots ever show up in ntpq -p > > The nopeer restriction is intended to prevent attackers from > pretending

Re: Zero-configuration ntpd

On Jul 3, 2016 7:51 AM, "Eric S. Raymond" wrote: > There is currently no default drift file location. This is where > I am not sure of my ground - should there be one? If not, why not? I vote no. NTP shouldn't touch the filesystem unless you tell it to.

Re: Design proposal for a better ACL language

> I'm significantly concerned about part 3. In any transition like > this, there is a *lot* of potential for subtle bugs due to ontological > mismatches between the new and old ways of doing things. It's going > to be a defect attractor, potentially a very nasty one with security > impact (as

Re: My pre-1.0 wishlist

On 6/5/16, Eric S. Raymond wrote: > I will be delighted if you keep having boundary-busting ideas like > that, because some of them will work. But I have to be the guy to > tell you that, in our context, trading a very hard but in principle > deterministically solvable problem

Re: My pre-1.0 wishlist

On 6/5/16, Eric S. Raymond wrote: > Unless you set up behavioral replicability (that is, an environment in > which a known sequence of clock readings, I/O events, and other > syscalls leads to another known sequence, or at least correct > recognition teatures of same like ntpq

Concerning the ntp-4.2.8p8 security fixes

NTP Classic 4.2.8-p8 was released today, containing fixes for one high-severity and four low-severity vulnerabilities. Four of these five vulnerabilities, including the high-severity one, do not impact NTPsec. CVE-2016-4956 and CVE-2016-4957 were introduced into NTP Classic by the patches for

Re: on the NTP security issues and fixes

On 5/6/16, Gary E. Miller wrote: >> Do we have to live with long convergence times? Do you have any >> theory about what causes this and how it can be fixed? > > I have not gone deep into the PLL, grouping, and selection layers. > Daniel Franke's talk at Penguicon leads me to

Re: on the NTP security issues and fixes

Well, that was scary and a little overwhelming but it turns out we're in remarkably good shape: I've now merged patches for what look to be the only three out of the eleven issues that impact us, and two of those only dubiously qualify as vulnerabilities at all. Before I ask Mark to tag a release

Re: calc_tickadj: unknown env option

On 2/25/16, Sanjeev Gupta wrote: > The script itself seems perl , is the "-w" supposed to be passed to the > perl interpreter? That does not seem to make sense, either. Yes, I think it is. Look at commit 25d702fe88a303929bc940be9294d8a00e1554f5. The first line used to be #!

Re: An ontology of clocks

On 2/19/16, Gary E. Miller wrote: > No, resolution is the smallest time increment a clock can represent. > Precision is a measure of the quality of the clock time. I've seen "precision" used both ways by different authors, but I think you're right that resolution is a better