Re: Tracker bugs and our release process

I have read ESR's writeup on our buglist, and agree with his assessments. ..m On Tue, Aug 15, 2017 at 5:27 AM Hal Murray via devel wrote: > > * I need to work on #348: reverse function for restrict > > * unpeer should be made to fully work from ntpq :config. This one is >

Re: I think we can drop the Jupiter driver.

I find it unlikely we're going to find a real Jupiter to test against, if nobody has raised this issue against NTP Classic. ..m On Tue, Apr 25, 2017 at 5:22 PM Gary E. Miller via devel wrote: > Yo Hal! > > On Tue, 25 Apr 2017 17:16:58 -0700 > Hal Murray via devel

Re: Does anybody have a sample of a NMEA device with the 1024 week bug?

How hard is it to write a fake NMEA device simulator in Python, and use Linux IPC control magic to have it appear at a fake serial device? ..m On Sun, Apr 16, 2017 at 4:46 PM Hal Murray wrote: > > I'd like to get one for testing. > > > -- > These are my opinions. I

blog/_drafts/gps-pivot.ad

Hi! I just created blog/_drafts/gps-pivot.ad It's a lightly edited transcript of a conversation about GPS rollover and pivoting. I'm going to work it into a blog post. Anyone with a good grasp of the GPS rollover issues is invited to work on it as well. Thanks! ..m -- Mark Atwood

Re: blog/_drafts/gps-pivot.ad

This blog post will be about GPS receiver firmware pivoting issues and about GPS system 1024 week era wrapping issues. There will be another different blog post about about NTP era wrapping and pivoting Analysis of the time_t wrapping is getting too far out of our remit, and other people have

Re: NTPsec on MIPSbe

Thanks! On Mon, May 22, 2017 at 2:32 AM Sanjeev Gupta via devel wrote: > After a fruitless two months trying to find a big endian machine, I > finally booted a qemu instance. > > Running Debian 7, 256M RAM, 32 bit. gcc 4.6, kernel 3.2 > > buildprep fails because Debian 7 did

Re: logging/debugging

I often use DEBUG_MRA_FOO, and then use judgement and taste as to leave it in or not. I use "is it worth writing the documentation for it" as part of deciding to leave it in or not, and also "am I absolutely sure I have characterized and fixed this bug such that I'm sure it's fixed, and will not

Re: ✘ISC_PLATFORM_USEBACKTRACE

I remain a fan of ripping out unused and useless code. As you remove stuff, do please keep each conceptual chunk of removal in it's own well defined git commit. ..m On Fri, May 26, 2017 at 9:12 PM Gary E. Miller via devel wrote: > Yo All! > > I see a lot of libisc code that

Fwd: New Defects reported by Coverity Scan for ntpsec

- Original message - From: scan-ad...@coverity.com Subject: New Defects reported by Coverity Scan for ntpsec Date: Tue, 06 Jun 2017 15:06:19 -0700 Hi, Please find the latest report on new defect(s) introduced to ntpsec found with Coverity Scan. 1 new defect(s) introduced to ntpsec

Re: ✘HPUX ??

Hilariously, I don't know where we can get a HPUX lab machine. I want to support it, but I also want us to stick to "POSIX only, unless it's really important". How much HPUX only code is there? What does it do? ..m On Tue, Jun 6, 2017 at 6:42 PM Gary E. Miller via devel

Re: Heads up: USE_PACKET_TIMESTAMP tangle

That is worth filing a bug against BSD for. On Mon, Jun 5, 2017 at 9:41 PM Hal Murray via devel wrote: > > FreeBSD supports both SO_BINTIME and SO_TIMESTAMP > > SO_BINTIME provides 32 bits of fractions of a second. > SO_TIMESTAMP provides microseconds - timeval. > > So the

Re: ✘HPUX ??

ok, kill that code. Sanjeev, keep those servers mothballed, unless you have a personal itch make hpux work. ..m On Wed, Jun 7, 2017, 1:25 AM Eric S. Raymond wrote: > Sanjeev Gupta via devel : > > I am not sure that there will be any Sysadmins who will install

Re: More SNMP dependency questions, also assertions. [FWD because reply error]

yes, this is to be an agentx implementation On Tue, May 2, 2017 at 12:43 PM Gary E. Miller via devel wrote: > Yo Ian! > > On Mon, 1 May 2017 21:09:08 -0500 > Ian Bruene via devel wrote: > > > > Do you intend to make this an snmp agent that would run under an

Re: NetBSD 6.1.5 doesn't have ldexpl in math.h

I agree, drop NetBSD6 and document why. Is NetBSD 6 still under development?If so, we can send them a bugreport. On the other other hand, do we still have any other compatibility shims anywhere else for any other OSes? floating point ops like this are "merely" some simple bit twiddles, as

Re: NetBSD 6.1.5 doesn't have ldexpl in math.h

NetBSD6 still supported, so it's still running in the wild. I know we've been removed most compatibility shims, but are they all gone? or do we still have a chunk of "if this OS, then define these missing functions"? ..m On Wed, Sep 13, 2017 at 12:16 PM Hal Murray

Re: Default config file behavior - request for comment

While I like choice #2 for friendlyness, I have to agree re not to hardwire the pool name without external consent. Code in choice #1, and if its easy to do, with a big loud warning to stderr and logerr that it's doing nothing. Supply a reference config file that implements #2 ..m On Wed, Sep

Re: Default config file behavior - request for comment

Achim is right, the ToS and documentation for pool.ntp.org forbids vendors from using pool.ntp.org as a default or a hardcoded entry. I have submitted an application for a vendor pool named ntpsec.pool.ntp.org In the meantime, our hardcoded default should be #1 "locked down do nothing", and our

Re: NetBSD 6.1.5 doesn't have ldexpl in math.h

. Raymond <e...@thyrsus.com> wrote: > Mark Atwood via devel <devel@ntpsec.org>: > > NetBSD6 still supported, so it's still running in the wild. > > > > I know we've been removed most compatibility shims, but are they all > gone? > > or do we stil

Re: NetBSD 6.1.5 doesn't have ldexpl in math.h

We could just grab from NetBSD7. Or if we know it's an IEEE754 float, just do the direct bit ops. Or the direct fp cpu op. ..m On Wed, Sep 13, 2017 at 4:05 PM Gary E. Miller via devel <devel@ntpsec.org> wrote: > Yo Mark! > > On Wed, 13 Sep 2017 22:31:31 +0000 > Mark Atwoo

Re: NetBSD 6.1.5 doesn't have ldexpl in math.h

Fair enough. We should still feed a bug report to NetBSD6, maybe one of their FP guys will patch it in. And we drop NetBSD6 now, because of that lack. ..m On Wed, Sep 13, 2017 at 5:52 PM Eric S. Raymond via devel wrote: > Gary E. Miller via devel : > > Yo

Re: ntpq: Tiny vs 0

On Thu, Sep 21, 2017 at 10:51 AM Hal Murray via devel wrote: > > Would it be interesting to hack the combination of ntpd and ntpq to show 0 > values as 0 and tiny values at 0.000 or with a command line switch 0.9E-xx? > I've worked on systems that did things like that, but

we released 1.0.0, thank you, and take a break

Last night, we tagged and released 1.0.0 of NTPsec blog post is https://blog.ntpsec.org/2017/10/10/version-1.0.0.html updated historical narrative is https://www.ntpsec.org/history.html press release is https://www.ntpsec.org/pressrelease-20171010.html gitlab commit

Re: Pulling - or clawing - data out of mode 6

Does the MIB or SNMP define "cannot determine or undefined". It's been too long since I did SNMP The "uptime" variable is used to by snmp clients to do "count per time" calculations, and also to notice how long after boot that that that daemon started, or if its restarting. If you need to,

Re: Getting things moving again

I'm also interested in the status of the latest NTP Internet Drafts. Are they solid enough for implementation? I'm inclined to say yes to the MacOS patches, but I want to hear the discussion, and read the patches myself. ..m On Sat, Nov 4, 2017, 2:54 PM Eric S. Raymond via devel

Re: NMEA driver - off by 1024 weeks but says 4096

I suggest running it with gpsd for a while instead of NTPsec, and see if gpsd's logging identifies the issue. Or if the ntpd log contains the NMEA strings, it may be possible to reconstruct a gpsd playback file, and play it into gpsd, and see what it says. ESR and GEM might could help with that.

Re: Let's get back to work

Some additional suggested work items: * ntpsec.pool.ntp.org registered (I will take that one) * do we KNOW that the DEB and RPM distro packaging works? * get into the distros: ** setup an Ubuntu PPA (I will take that) ** setup a YUM repo (JDB, can you do that, working with GEM?) ** Debian as an

Re: Odds and ends

I like the "two sets of counters" idea. On Wed, Jun 6, 2018 at 10:18 PM Hal Murray via devel wrote: > > [if (0) on debugging msyslog] > > What I do is delete them unless I think they might have continuing > value, in > > which case I put them under DPRINTF. > > I agree on the "continuing value"

Re: Resuming the great cleanup

On Sun, May 27, 2018 at 11:56 AM Hal Murray via devel wrote: > > Eric said: > > SINGLESOCK: While messy and somewhat difficult, this is mostly a SMOP > > (Simple Matter of Programming). There is one potential technical risk, > > relatively minor I think. > > > The reason for iterating over

Re: SINGLESOCK - How much to strip away?

I still want to strip it all and delegate it to iptables, case OMEGA. But I do understand the pushback against that from GEM, and have been thinking about it for the past few days. As I type and think: one of the fundamental problems with having longrunner daemons try to keep track of addresses,

Re: Odds and ends

>> The code for freeing up key strings zeros them out first. How do we do that in python or go? > Same way you would in C, iterate over them writing zeros. Am I missing something? I may be not understanding something. I thought that strings were non-mutatable in Python, and every time one is

Mark will be on V until July 5

Hi! Starting Sunday, I will be on vacation in Barcelona and Paris, returning on July 5. I will not be bringing my laptop with me, and will not have access to any of my private keys, including GPG, SSH, 2FA, OTP. In the event of an event of an event, do the right thing. In the event of an

Re: Should we just remove the broadcast option?

I think all modern Windows machines get their address from their domain controller, or from ntp?.microsoft.com If its a snarl, Im tending towards removing it, and documenting it's absence. On Tue, Feb 20, 2018 at 5:16 PM Eric S. Raymond via devel wrote: > Mark! Heads

prep for 1.0.1

Hi! A few months ago, I announced prep for a 1.0.1 release. Turns out, it never actually happened. So, I'm declaring an intention for the 1.0.1 release the weekend after next, about March 3rd. As you work, consider stability, and avoid introducing instability. And let us know if it

Re: Future projects (post release)

Those both sound like good ideas. ..m On Tue, Feb 20, 2018 at 10:03 PM Hal Murray via devel wrote: > > There are two projects I've had my eye on for a while. > > The first is to remove the input buffer queue. That's leftover from before > kernels supported time stamps on

Re: How do I fix a typo in a git commit comment?

This is worth reading: https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things The if you have not yet added another commit on top of the one you need to change, the command is: git commit --amend ..m On Sat, Mar 24, 2018 at 7:51 PM Hal Murray via devel wrote: > > The

Re: How do I fix a typo in a git commit comment?

We can accumulate a list of typos and gltiches in the history. We will wait until something major, or it gets long enough, and then we can fix them all in one force push. In the meantime, for this typo, code up adding a comment to the relevant code about the typo, then commit the change with a

Re: Python shebang policy

I've read the thread. We will not do shebang munging for Python versioning. This is something for the distro packagers to do. I understand that it makes some work for Debian (and thank you for doing that!), but I like the Debian patch that does it: it's big, bright, clear and obvious what it's

Re: Fw: [LEAPSECS] current / future state of UT1 access?

> > About time the NTP told the user what time is being served? > Yes. It should got into an extension block. Two, one for time base, one for PPS source. What is the natural length of an extension block? My preference is a US-ASCII string or a UTF8 string, instead of a binary enum. "UTC",

Re: prep for 1.0.1

If Hal isn't happy, I'm not happy. I'll hold the release until this gets unsnarled. ..m On Thu, Mar 1, 2018 at 2:42 PM Hal Murray via devel wrote: > [truncate long digests] > > Bletch. No, we don't. > > Except that others are already doing it, so I guess we should do it

Re: Is gitlab flaky?

The pipeline process is a bit flaky. I'm probably going to be able to meet with the GitLab CEO this coming week, and that's one of the points I'm going to bring up. On Mon, Feb 26, 2018 at 1:21 PM Hal Murray via devel wrote: > When I push something, I normally get 2 messages

Re: 1.0.1 and ntpsnmpd

ntpsnmpd should be it's own Debian package, please. It's useful to both NTPsec and to NTP Classic installations. On Tue, Feb 27, 2018 at 3:45 AM Sanjeev Gupta via devel wrote: > Apologies. > > I checked an hour ago, and the guy who assured me that we were using > 'native'

Re: 1.0.1 and ntpsnmpd

Re ntpsnmpd My inclination is to include it, but document it as experimental, but also document in the release announcement as worth trying. Does waf build it by default? Does the Debian packaging have it be it's own package? ..m On Sun, Feb 25, 2018 at 5:18 PM Hal Murray via devel

Re: prep for 1.0.1

I am inclined towards quarterly release schedule as well, modified with doing a release when we discover an important enough issue, and we will delay a release if we discover an important enough issue. On Wed, Feb 21, 2018 at 1:41 PM Hal Murray via devel wrote: > >

Re: Future projects (post release)

Putting the globals into a controlled struct make them easier to reason about, both for humans and for source code analysis. And even if the resulting struct is little more than the "globals dumping ground", it does force that they all be declared in one single place, in a place where you have to

starting Network Time Security work

Hi! We need to pivot our development focus to implementing Network Time Security. Cisco is sponsoring this work, and has asked that we make our best effort at it. I'm confident that they will be very impressed with what our best effort is. Our contacts at Cisco are Panos Kampanakis,

NTPsec 1.1.3 has been released. https://blog.ntpsec.org/2019/01/13/version-1.1.3.html

NTPsec 1.1.3 has been released. https://blog.ntpsec.org/2019/01/13/version-1.1.3.html ..ѠѸђ Mark Atwood Project Manager of the NTPsec Project +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel

switching from Disqus to Commento

Hi! I am going to switch our blog comment processor from Disqus to Commento. Hopefully, this will be transparent, except for now there will not be nay more embarrassing adtech spam and tracking cookies injected into our blog. Commento has a free tier SaaS which is what we'll be using. Their

Re: Interesting talk on Chronos

On Sun, Jul 28, 2019, at 20:04, Eric S. Raymond via devel wrote: > https://www.youtube.com/watch?v=2HVtswVGmak=PLC86T-6ZTP5j2xKSoqW0_ajvdr58Fau6g=6 > > Interesting talk about changing the sampling algorithm to harden NTP > against time-shift attacks. This is very much on-mission for us and I >

Re: Interesting talk on Chronos

On Sat, Aug 24, 2019, at 20:54, Eric S. Raymond wrote: > Mark Atwood via devel : > > > Interesting talk about changing the sampling algorithm to harden NTP > > > against time-shift attacks. This is very much on-mission for us and I > > > > Any updates or tho

prep for point release of NTPSec, suggest 2019-07-31

There is discussion of a need for a point release of NTPsec. I agree, we've done a bunch of useful and user visible stuff. How does everyone feel about next Saturday, Aug 31 2019-07-31? That gives us a week to beat on our new features, and to merge and beat on pending merge requests. ..m

Re: Future directions

I like both of those, port randomization and better transmit timing. Plus it will make the IETF people happy. ..ѥѸђ Mark Atwood Project Manager of the NTPsec Project +1-206-604-2198 On Mon, Sep 16, 2019, at 03:00, Eric S. Raymond via devel wrote: > Hal Murray : > > > > Two areas to

Re: Future directions

On Mon, Sep 16, 2019, at 14:09, Hal Murray via devel wrote: > I think we should put the current stuff on the back burner and make a new SHM > interface where the clients are read only. > > Is shmget/shmat the right API to use? I remember discussions of there being > a > wrong API but don't

Considering dropping Python 2 support (was Re: Python.h quirk)

On Sat, Sep 21, 2019, at 11:03, Eric S. Raymond via devel wrote: > > The problem, of course, is that the Python 2 and Python3 development > package both want to own Python.h, > and the name is not versioned. > > I don't see any fix for this other than "have the right dev kit > installed whebn

getting reading for NTPsec 1.1.8 release

Hi! I would like to tag and release 1.1.8 this coming weekend, 2019-11-16 Please stabilize and push your work, and update the NEWS file as appropriate. Let me know if we shouldn't do this release on this schedule. Thank you for all your work, everybody. Especially a big thank you to Hal. ..m

Re: [OT] Splitting PPS?

On Wed, Nov 13, 2019, at 09:38, Richard Laager via devel wrote: > > It'd be nice if we could also replace the dead GPS master clock with a > directly connected GPS receiver, so we get PPS into the server (e.g. via > a serial port). That would make them stratum 1. I recently did this on > my own

Re: Clock fuzzing bugs

On Sun, Nov 24, 2019, at 19:32, Hal Murray via devel wrote: > > e...@thyrsus.com said: > > If we don't see any evidence of beat-induced quantization, I'm willing to > > say > > we drop this code. > > How about adding a --disable-fuzz configure option so we can experiment > without breaking

Re: policy and pylib/packet cmac/160 bit hmac support

We don't have a policy against 3p Python modules. On the other hand, I'm not a fan of importing the entire cheese shop. On the other other hand, I usually pull in the gpsd Python module on machines I'm running ntpd on. On the other other other hand, can we have a Python binding on the C crypto

Re: Copyright Statement Years

> Can you cite some examples of those large companies publishing open > source code without a year? Facebook https://github.com/facebook/react-native/blob/master/LICENSE Microsoft https://github.com/dotnet/core/blob/master/LICENSE.TXT Amazon I dont have any Amazon examples yet. I work

Prep for tagging NTPsec_1_1_9 on 2020-05-23

Hi! It's been a while since we tagged NTPsec_1_1_8 on 2019-11-18 and we have accumulated 17644 lines of diff in 245 commits since then. Unless someone pulls the stop cord, I will tag NTPsec_1_1_9 on 2020-05-23. Please update .../NEWS.adoc with text of interest, including features, clock

Re: NTS dropping TLS 1.2

I think that our implementing this is a good reason for make a point release. ..ѥѸђ Mark Atwood Project Manager of the NTPsec Project +1-206-604-2198 On Mon, Mar 23, 2020, at 01:24, Hal Murray wrote: > > A new version of the draft RFC is available: >

Re: How about a release soon?

HI, I've been waiting as well on the RFC for 1.2 Has there been enough user visible improvement to warrent a release of 1.1.10? ..m ..ѥѸђ Mark Atwood Project Manager of the NTPsec Project +1-206-604-2198 On Sat, Aug 29, 2020, at 11:58, Hal Murray wrote: > > The RFC isn't out yet and I

get ready for 1.2.0 on Friday 2020-09-25

On Fri, Sep 18, 2020, at 13:33, Daniel Franke wrote: > 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

thinking of tagging 1.2.0 for when NTS is officially official.

> In hindsight, we should have pushed a release when we made the incompatible > change to the new string used to make the c2s and s2c keys. (The draft RFC > changed a string constant There is no reasonable backward compatibility > hack.) You are correct. We should have then. I'm thinking

Re: thinking of tagging 1.2.0 for when NTS is officially official.

> > You are missing a key word in there. Listen "in addition" or "instead"? > > When I first read your message, I assumed you meant in addition since instead > doesn't really make sense to me. But maybe I'm missing something and > "instead" is what you have in mind. > > I really don't want

Re: thinking of tagging 1.2.0 for when NTS is officially official.

>> I'm expecting there will be a new port number assigned for the KE server. > Step 1 will be to listen on both old and new port # > Step 2 is to switch the client side to default to the new port #. > Step 3 is to stop listening on the old port #. > > I'm thinking a day or two between

get ready for 1.2.1 on 2021-06-01

Hi! Please get ready for 1.2.1 on 2021-06-01 Major contributors, please chime in, and merge your work that you think is ready. Please update the …​/NEWS and the …​/devel/TODO files with descriptions of your work. This will be the least release cranked out by myself. Matt Selsky will be the