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 release manager henceforth. ..๐ฅ๐ธ๐ 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
Re: We need to capture data on corner cases
> I read on the Internet that comments are useless. I occasionally notice them > despite the fade to gray tendency. Yeah, I ripped out the following. It was > essentially invisible in my not-an-ide and the rat brain is fallible. > - /* > - ** Classic Bug 2672: Some OSes (MacOSX, Linux) don't block spoofed ::1 > - */ > >> Should we collect the descriptions in another file and add pointers both >> ways? > > Possibly. If it happens I would like to start the name suggestions with > 'codescars' after [1] and something I thought I had read on an Internet site > but can no longer find there. > It may be that people don't read comments, but even more true that they don't read "another file". Comments have a prayer of being seen. I like the term "codescar". Do feel free to use it and add searchable tagged comments in the source code. ..m ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 it will be ready when the RFC comes > > out rather than shortly after. Ok, we'll do the release on Friday the 25th. This will be version 1.2.0. Having NTS under RFC is worth a 0.X.0 version bump. Everyone, do the stuff. Wrap up your almost done WIPs, merge them, test them, and update the docs and the Changelog. ..m ..๐ฅ๐ธ๐ 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
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 have no idea when it will get published. > > I'd like to get an official release out that uses port 4460. > > The current code still listens on port 123 as well as 4460. I'd like to > remove that when the RFC comes out and we release 1.2 > > > > -- > These are my opinions. I hate spam. > > > > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 to support listening on 2 ports as more than a temporary > hack. > > How about we go through steps 1, 2, and 3 with me just sending email when I > push the changes? If the RFC comes out first, we just skip to the end. That makes more sense, do that instead. Thank you. ..m ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 steps. > We could complicate things with some conf options. > > Which one do you want to call 1.2.0? > > Plan B is to merge them all 3 steps and tolerate the brokenness until > everybody switches to the new port number. Let's do plan B, but with config options for operators that want to listen on the old port. ..m ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 of tagging 1.2.0 for when NTS is officially official. ..m ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 drivers, notable fixes, security issues fixed, and security issues that we avoided. ..๐ฅ๐ธ๐ 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
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: > https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ > > They decided to drop support for TLS 1.2. Details way down. > > They also tweaked the TLS export string used to make client-server keys. > That > will break things if the client and server don't use the same one, aka > everybody has to update in sync. There is no way to detect the change. The > symptom will be lack of response. Stay tuned for more info, maybe a flag day > announcement. > > > > OpenSSL has dropped support for older versions that don't support TLS 1.3. > That was roughly the start of 2020. There used to be many more OSes that > were > still shipping old versions of OpenSSL. Most of them upgraded. A few > haven't. > > The ones I know about that haven't upgraded are older (but still supported) > versions of CentOS, NetBSD, and probably Debian and Raspbian. > CentOS runs old/stable code. People running their old version are unlikely > to > be interested in NTPsec or NTS. > NetBSD is getting ready for a release that will drop support for the current > old/broken version. > > I don't have an old version of Debian handy. I do have old Raspbian which > usually tracks Debian. It has an old OpenSSL. > > I don't know about other OSes. > > > You can tell if you have older clients by scanning your log files for > "TLSv1.2". The server will say something like: > 19 Mar 14:27:31 ntpd[30185]: NTSs: NTS-KE from 192.168.1.29:65366, Using > TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384 (256), took 0.015 sec > > If your client is talking to older servers, it will say something like: > 22 Mar 06:42:19 ntpd[679]: NTSc: Using TLSv1.2, AES256-GCM-SHA384 (256) > > Our current code supports TLS 1.2 with a handful of ifdefs. (Actually, > mostly > #if checking the version number.) > > We can do several things: > 1) clean out the ifdefs that make things work with older versions of > OpenSSL. > That is drop support for systems that haven't upgraded their OpenSSL to a > supported version. > 2) leave things alone, ignore the RFC. > Or maybe add some nasty warning messages > How long? > 3) make a configure option to disable NTS so that NTPsec builds on older > OSes but doesn't support NTS. > > I propose option 1. Simple and clean. I don't think we will drop many > systems. > > -- > > (From n...@ietf.org) > > - No TLS 1.2 > During this work, it became apparent that keeping support for TLS 1.2 > and correctly covering for the differences between TLS 1.2 and TLS 1.3 > would be a lot of work, with the risk of getting something wrong or > missing on important issues, in the specification or in the > implementations. > > The last time the issue of 1.2 support was up for debate, there were > some operating systems that would not support TLS 1.3, and there was a > concern that this would impair the protocol adoption rate. Today most > (all?) major operating systems do have TLS 1.3 capable libraries in > their later versions. > > > > > -- > These are my opinions. I hate spam. > > > > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 for Amazon's OSPO and so examples will be happening soon > Do you have any legal analysis on this you > can share, publicly or privately? I can share privately f2f off the record. Will you be at Open Source Leadership Summit in a few weeks? Sharing the legal analysis publicly, especially under a corporate byline, turns into "giving legal advice". Which is frustrating, given all the petite lawyers who want to get all "well, actually..." and "its not broke, dont change things" this. > > I'm asking for three reasons: > 1) My own curiosity Learning is always good. > 2) Wearing my Debian packager hat, in case this comes up with Debian >when I bring in the next NTPsec release with all the years scrubbed >and update debian/copyright to match. Do please scrub it from the Debian package. > 3) Because I'd like to convince others of this point, so I can stop >having to maintain copyright statements all over the place. Please do. Other Debian packager people are welcome to email me direct. In fact, they can do so to my work address at Thanks! ..m ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 the default case. > > Or maybe a runtime configure option. I like that idea. ..m ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 routines that ntpd uses? ..๐ฅ๐ธ๐ Mark Atwood Project Manager of the NTPsec Project +1-206-604-2198 On Thu, Oct 31, 2019, at 13:00, James Browning via devel wrote: > After looking at devel/HACKING, I do not see a policy on including > external python modules. > > The came up because I have a merge request (!1044), which adds support > for RIPEMD160, SHA-1, and AES128CMAC. The CMAC implementation currently > requires the pycryptodome[1] module. > > If external modules are not allowed, then eventually someone will need > to implement a substitute. > > [1] https://pycryptodome.readthedocs.io/ > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 with a ublox 6 evaluation kit that I picked up for cheap on eBay. > For this project, we could buy an equivalent current generation EVK-M8T > for $250 from e.g. Digi-Key. > > > What is the most cost-effective way to create three stratum 1 servers? Buy 3 of these for $50 each: https://www.etsy.com/listing/501829632/navisys-gr-701w-u-blox-7-usb-pps Im the seller, but I'm selling them at my cost, specifically for use cases like yours. 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
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 ..๐ฅ๐ธ๐ 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
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 you build". Given that the Python community is driving hard on deprecating Python2 on 2020-01-01, I'm inclined to drop Python2 support on that date. https://pythonclock.org/ I've read random suppositions that there may be a "renegade" fork to "Python 2.8" or "Python 2.9" but even if that happens, the distros will still be forced to clarify which one is installed. ..๐ฅ๐ธ๐ 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
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 remember any details. I always liked the idea of moving to a shm or a local socket "clockd" interface. (Under the hood, a UNIX domain socket or a 127/8 localhost socket is nothing more than merely a shm segment and two semiphore locks.) A clockd interface was, in fact, part of the original plan. Maybe make it the plan again? ..m ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 consider: > > > > Port randomization: > > https://tools.ietf.org/html/draft-gont-ntp-port-randomization-04 > > > > The basic idea is for the client side to use a random port number when > > sending > > packets so bad guys have a harder time attacking with junk packets if they > > can't monitor the traffic to see the port number. (Without this feature, > > they > > know the port number is 123.) > > > > There are two ways to implement it: random per-packet, or random > > per-target. > > Some routers include the source port when hashing to select among alternate > > routes. They suggest per-target which will hide the timing changes due to > > different paths. I would have picked per-packet in order to get some good > > data at the cost of discarding a higher percentage of samples. This area > > seems ripe for some experimentation and data collection. > > > > I'd guess somewhere between a day and a week to implement this. > > > > --- > > > > Better transmit timing... > > > > We get good time stamps on the receive path. The transmit path is messy. > > We > > grab the time before the call to send the packet so it is early. This gets > > worse with NTS or shared key MACs. > > > > There is a draft in the works: > > > > NTP Interleaved Modes > > https://tools.ietf.org/html/draft-ietf-ntp-interleaved-modes-02 > > It requires per-client state at the server. That's ugly in principle, but > > not > > a major problem if you believe that modern systems have lots of memory. > > > > I've skimmed it, but not studied it. > > > > I've been thinking of measuring the timing and bumping the time stamp to > > correct for the delay. Again, this seems appropriate for some > > experimentation > > and data collection. > > > > I'd guess a week or two. Maybe more if the data gets interesting. > > > > -- > > > > We should check RFC 8633 - NTP Best Current Practices > > https://www.rfc-editor.org/rfc/rfc8633.html > > Both good proposals. I had been thinking about doing the > transmit-timing one myself > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 thoughts? > > Daniel seems to think it;s more trouble than it's worth for an atttack that is > theoretical and very difficult to pull off. > > I think there might be some sizzle value in being able to say we have it. How hard do you think it would be to implement. Related question, how hard would it be to test? ..m ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 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
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&list=PLC86T-6ZTP5j2xKSoqW0_ajvdr58Fau6g&index=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 > think their techniques would not be very difficult to adopt. > > Draft RFC: > > https://tools.ietf.org/html/draft-schiff-ntp-chronos-02 > > Senior devs - especially Hal, Gary, and Daniel - please read carefully > and critique on this list. Any updates or thoughts? ..m ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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
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, Jonathan Gardner, and Andrew Benhase. Our first deliverable is a blog post announcing our partnership with them and announcing our intentions to make this happen. The draft of that post is checked into the blog/_drafts/ dir now, and I will publish it tomorrow. Here are the requirements: The NTS implementation shall: * Use OpenSSL 1.1.1 for its crypto functions. * Address RFC5705 Keying Material Exporting and AES_SIV (RFC5297) code support which may not be natively supported in OpenSSL. *comply with the standardized specification of NTS https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp * be interoperable with the other reference implementations in IETF hackathons. Our deliverables are a "first drop" and an "interoperable drop". The SOW schedule has the first drop by the end of February, and the second drop by the end of May. That same schedule hoped we would have all the paperwork done by the end of November. As long as we show progress, velocity, and good practice, those dates are not dropdead deadlines, just strong guidelines. This is going to be fun, and will get us a new cohort of users. ..m ..๐ ๐ธ๐ 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 implementation is open source, so we can pivot to self-hosted if we feel the need to. ..๐ ๐ธ๐ 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
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 emergency, I will usually be reachable on Signal. ..๐ ๐ธ๐ 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
Re: style question - testing pointers for NULL
Use "if (NULL != foo)" The second is OK, but convert them as you find them, please. On Thu, Jun 7, 2018 at 8:51 PM Hal Murray via devel wrote: > > Should I write > if (NULL != foo) ... > or is > if (foo) ... > OK? > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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" part. > > For what I'm after, msyslog is more convenient that DPRINTF. I'm willing > to > do an edit/build/restart cycle to get the printout I need. For now, I'll > try > my "if (0)" hack. If anybody thinks that's too ugly we can discuss > alternatives. > > >> extern int clocktime (int, int, int, int, int, time_t, > uint32_t, uint32_t *, uint32_t *); > > Fair point. Are you advocating outting the formal names back in? > > I don't have any strong opinions in that area. That's a particularly ugly > example. I ran into a few ugly ones when working on the CMAC > authentication. > It seems like something we could do better. > > [*CAST stuff in ntpd code] > > I agree with moving them to ntpclients. Anything that reeduces the > amount > > of ceuft ubthe ntpd code is good. > > I didn't find any usage in ntpclients so there probably isn't any need to > move them. We should concentrate on removing code from ntpd. > > If we find things like "if (xxx->flags & MCAST)" but there is no way that > the > flag ever gets set, then we can just remove the code. > > [counters that get reset every hour after writing to log file] > > Reasonable. Would you make ntpq parse the logfile? > > No, that's ugly and only works if you are on the system with the log files. > > I was thinking of having ntpd maintain 2 sets of counters. The new set is > parallel to the current set. It gets updated when the current set is > cleared. When ntpq asks, ntpd would return both values. > > [ntpq -p showing authenticated slots] > > No need. Just boldface the ones with authentication. > > I like it. What happens if I cut/paste into email? > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 written to, the interpreter actually allocates a new string and eventually GCs the old value. ..m On Wed, Jun 6, 2018 at 4:35 AM Eric S. Raymond via devel wrote: > Hal Murray via devel : > > I occasionally add msyslog lines when debugging. The DPRINTF stuff > isn't > > interesting - too much junk I don't want. When I'm cleaning up, should > I > > disable them with "if (0)", or delete them? Is there a better way? ... > > What I do is delete them unless I think they might have continuing value, > in which case I put them under DPRINTF. > > > Some/many of the prototypes in our header files are not very useful. I > think the problem is the lack of names on the parameters. If the types are > all different, that's enough, but if there are several integer parameters > that doesn't help. Here is an example: > > extern int clocktime (int, int, int, int, int, time_t, > uint32_t, uint32_t *, uint32_t *); > > Fair point. Are you advocating outting the formal names back in? > > > There is still some broadcast/multicast stuff around. grep for CAST > will find them. Should we leave enough around so that our ntpq can decode > things when talking to old servers? If so, I vote we move them to > ntpclients/ > > I agree with moving them to ntpclients. Anything that reeduces the > amount of > ceuft ubthe ntpd code is good. > > > Some of the counters that ntpq can display get written to a log file > every hour. That resets the counters so ntpq can only see what has > happened since then rather than the totals since startup. We should > probably maintain and display both. > > Reasonable. Would you make ntpq parse the logfile? > > > It would be nice if ntpq would show something if a server is using > authentication. I'd be willing to steal a character from the name column. > > No need. Just boldface the ones with authentication. > > > 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? > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be > your own. > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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, address masks, and interface names is that interfaces can go down, come up, get renamed, and have address masks added and removed from each, and trying to keep track of that in userspace is a nightmare. Sysadmins are used to having to bounce a database server when listener interface has an address event, but bouncing ntpd is much less okay. As I type and think more, I ask, "What does Chrony do?", and I look at [ https://chrony.tuxfamily.org/doc/3.3/chrony.conf.html]. It has a "bindaddress" directive, which uses IP address, not interface name. And only one bind address can be specified. It freely admits that that means Chrony is not the correct solution for serving down multiple controlled interfaces at once. Very simplifying, but not what we want. This reinforces my decision. Rip it. Maybe in the future we can carefully build back up to case Gamma. ..m On Thu, May 31, 2018 at 9:55 PM Hal Murray via devel wrote: > > Ian Bruene said: > > 1. Stop using work queue. Handlers are called directly by the receivers. > > 2. Remove work queue checking by mainloop() > > The receive loop is several layers down. The handler dispatching is up in > the main loop. > > You may want to move the receive loop up to the main loop rather than > moving > the handler dispatching down to someplace obscure. Whatever looks best > after > you find all the tail. > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 interfaces is that ntpd has the capability > to > > block incoming packets by interface of origin. In order to go to a single > > epoll we either need to (a) abandon this feature, or (b) find a way to > query > > the device a packet came through from the packet. > > Could that feature be moved to a packet filter? I think most OSes support > some form of kernel level packet filtering. I'm not familiar with any > details. > > Does anybody use interface filtering? > No modern sysadmin or devops shop is going to use or trust an userspace packet filter built into the userspace daemon they are defending. Direct-internet-connected boxes are going to use the kernel packet policy filter, and drop the packet before it ever reaches the daemon. Site-connected boxes are going to use their edge switch filters, and then maybe will use the kernel packet filter as a security alarm trip. Cloud-connected instances are going to use their cloud provider packet control APIs to permit inbound NTP packets, may run a policy relay instance on their VPC chokepoint, and again maybe will use the kernel packet filter. This is an ancient feature that is a fossil evidence that NTP was a known security tarpit predating the widespread deployment of the kernel packet filter or edge switch filters. We will drop this feature. We can explain why, and every netadmin and devops manager will agree with the reason. ..m -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 commit comment that references the incorrect commit text. That will stamp it into the history. ..m On Sun, Mar 25, 2018 at 5:28 PM Hal Murray via devel wrote: > > rlaa...@wiktel.com said: > >> Are there any alternatives? > > See `git notes` to attach notes to objects (e.g. > > commits) after the fact without changing the object itself. > > > Using the example from the man page, try something like this: > > git notes add -m 'The 674 should be 474.' c8c888f8 > > Thanks. > > That gives me a local note, but git push doesn't do anything and git clone > doesn't copy it. > > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 674 should be 474. > > commit c8c888f8f2ef295c0ea5f854127069b3812e4c09 > Author: Hal Murray > Date: Fri Mar 23 01:11:17 2018 -0700 > > Add logging of year(s) on large clock steps. Issue #674 > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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", "UT1", "TAI", etc for the time base, and the name of the constellation "GPS", "GLONASS", "MASER consortium" etc for the PPS source. How hard would it be for us to implement? If we are getting it from a clock driver, first cut we can just get it from the .conf file. Later, we work out best ways to get it from the clock drivers. If we are getting it from upstream, log WARNING if we're getting upstream time from different time bases. ..m -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 doing. ..m On Tue, Mar 20, 2018 at 2:29 PM Gary E. Miller via devel wrote: > Yo Eric! > > On Tue, 20 Mar 2018 17:19:38 -0400 > "Eric S. Raymond via devel" wrote: > > > Richard Laager via devel : > > > On 03/20/2018 01:59 PM, Matthew Selsky wrote: > > > > Sorry, I'm confused. Why has this option been rejected? > > > > > > Eric S. Raymond just wrote, "I think your objection to having waf > > > futz with them is sound." > > > > To clarify, Gary points out that "python" at runtime is not > > guaranteed to be identical to Python at waf config time. > > Yes. > > > You might say...well, that's an edge case that can only happen if > > you're manually intalling multiple Pythons for test purposes. > > Uh, no. Not an edge case, that is default Gentoo. A default Gentoo > install has many versions of python installed. Some different packages > specify exact python version. Other different packages use the system > default Python which is trivially selectable. > > So, unless Gentoo is an edge case, this is not an edge case. > > > But if you're not doing something that edgy, why do you want to set > > python to point to anything but the distro default? And if it's > > python 3, why not let the distro's patch master worry about it? > > Well, I think Richard is maintaining the distro patch master. > > It would appear that Debian is handling Python differently than other > distros. So he wants to move his patch set upstream into NTPsec. I > suspect some other distros might want to use it, but many will not. > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 <(541)%20382-8588> > > Veritas liberabit vos. -- Quid est veritas? > "If you canโt measure it, you canโt improve it." - Lord Kelvin > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 telling me it worked. > > Occasionally, I get 1 telling me it didn't. The last time, it worked when > I > poked Try-Again. > > This time, I got: > Subject: ntpsec | Pipeline #18075609 has succeeded for master | eef92d62 > Subject: ntpsec | Pipeline #18075609 has failed for master | eef92d62 > > Pipeline #18075609 ( https://gitlab.com/NTPsec/ntpsec/pipelines/18075609 ) > triggered by Hal Murray ( https://gitlab.com/hal.murray ) > had 1 failed build. > > Job #54445477 > > Stage: deploy > Name: pages:deploy > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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' SNMP has come back saying he setup the cacti script that talks > over ntpq > > I have posted a bounty offer on the cacti forum. > > Apologies for raising hopes. > > On 27 Feb 2018 7:40 pm, "Jason Azze via devel" wrote: > >> On Mon, Feb 26, 2018 at 7:18 PM, Richard Laager via devel >> wrote: >> > On 02/26/2018 06:16 PM, Sanjeev Gupta wrote: >> >> Richard, I am using cacti. >> > >> > That's what I was hoping to hear, since I also run Cacti. Are you >> > willing to share your templates? >> >> I'm also a Cacti user, though it has been years since I logged on to >> the Cacti forums to search for a template. If you have one that works, >> Sanjeev, I'd also like to get in on the action. >> ___ >> devel mailing list >> devel@ntpsec.org >> http://lists.ntpsec.org/mailman/listinfo/devel >> > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 too. > > I'll add a warning to the code that reads in keys. > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 admit "this is a global". On Wed, Feb 21, 2018 at 10:58 AM Hal Murray via devel wrote: > > > I've been looking at the code around mode 6 generation and discovered > that > > in some areas it's still globals all the way down. Translating these > > globals will make future refactoring/translating easier. > > I'm missing the big idea. > > The current case is that we have a lot of global variables. > > What does packaging them in a struct solve? We aren't going to pass a > pointer to the struct around all over the place. > > Should we cleanup the names so it's obvious which variables are global? > Should we reorganize the header files so it's easier to find all of them? > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/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: > > rlaa...@wiktel.com said: > > If you're going to move to time-based, you might consider quarterly > > releases? > > I'd be happy with quarterly releases. > > The next question is how seriously do we take the release date? I think > there are two approaches. The first is to try hard to release as > scheduled. > That means we have to be conservative and leave plenty of time for testing > and the associated cleanups. The other approach is to leave less time for > testing but slip the release if/when we find interesting problems. > > > > Longer release cycles allow developers and users of git to test some > changes > > longer, but that's only helpful if you have a freeze. > > I'm assuming there will be a freeze. Or at least a cooling off period > where > the changes are small and reviewed carefully, maybe smaller and more > carefully reviewed and tested as we get closer to the release. > > --- > > There might be a need for more time between releases if we ever make a big > change. I don't have any good examples right now. > > > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 wrote: > > > You need to be running an SNMP daemon and an NTP daemon. > > I've got plenty of ntp servers to experiment with. > > >> 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. > > > "Why SNMP?" I'm not sure I can tell you much more that a few minutes of > > quality time with a wiki could. > > There is a lot of stuff out there. A few good URLs would help people like > me > get started. I think "curated" is the right term. > > I assume I also have to setup a system to collect the data and show status > or > email alerts or whatever. What do you call that? I think there are > several > packages available. Do they all support NTP? Do they monitor NTP servers > directly with NTP packets? > > At any rate, I/we need the HOWTO level info for setting up the NTP side > and I > need a HOWTO for getting the collection end off the ground. > > (In case it's not obvious, I don't mean you have to write them. Links to > existing info is fine.) > > > > In case it's not on your list... > > ntpd can monitor other ntp servers. Just put "noselect" on a server line > pointed at the system you want to monitor. Then ntpq -p will give you a > line > of info and logging to peerstats and rawstats will get the normal data. > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 received network packets. (ntpd used to > grab the packets from an IO signal handler) > > The other is to remove the table lookup in the early stage of input packet > processing. It may have been a good way to handle all the complications of > multicast, broadcast, pool, and peer as well as the simple client/server > modes. I think it will be much cleaner to just dispatch by mode. > > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 up...exernal/marketing issue incoming. > > Hal Murray via devel : > > Is anybody using/testing it? > > Not as far as I know > > > We don't support receiving broadcast. > > No, I removed that after Daniel explained that it's unsecurable. > > > It used to support a ttl option. That got broken/dropped somewhere > > along the way. Should I restore that? Or maybe document that it is > > missing? ... > > I believe I already performed that documentationectomy. If there are > remnants, of course we need to fix them in one direction or the other > depending about the high-level decision aout supporting brodast mode. > > > Context is that I'm cleaning up the mode/ttl mess. The mode for > > refclocks used to live in the ttl slot. Since the ttl slot isn't > > used any more, I'm fixing up all the names. > > Good plan. > > About the major issue: > > I believe we retained bradcast mode thinking of a scenario where a bunch > of Windows machines on a lan are being fed time information from NTPsec. > > You're our NTP operations old hand. Do you think this is common? > > The big question is whetger this is an important scenario for us to cover. > In view of who we have an eye on as a target market, I'm inclined to > doubt it...but this kind of thing in Mark's bailiwick. > > I of course, would be happy to remove it to reduce complexity and > testing scenarios. > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be > your own. > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 shouldn't happen. Thanks, everyone! ..๐ ๐ธ๐ 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
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, insert into your subagent code when it first runs to grab the system clock value and store it, and then just sent back the diffence between "now" and that value whenever that variable is queried ..m On Mon, Nov 20, 2017 at 7:41 AM Ian Bruene via devel wrote: > > I'm trying to fill out the MIB for ntpsnmpd and have several items that I > do not know how to get data for. This also effects ntpq as so far my > primary method of discovering what to poke mode 6 with to get what I need > has been to see how ntpq does it. A side effect of ntpsnmpd will probably > be to expand ntpq's capabilities, or even mode 6's. > > Time Resolution (as distinct from time *precision*, which I can get from > the "precision" variable). > > Time distance: From the MIB: "The distance from this NTP entity to the > root time reference (stratum 0) source". The closest thing I can find that > sounds like match is the synchd() method in packet.py/SyncPacket. It is > only used by ntpdig. > > Current mode: There is a "peermode" variable, but I don't think it is > giving the information that the MIB wants. "hostmode" or "hmode" do not > exist. > > Active reference source ID: pretty sure this means which one is the > syspeer. I can get the address with "peeradr", but not the associd. This > could be brute forced by getting all of the peers and finding the right > one > > Uptime: well there is an uptime variable. But I do not know the format (it > *looks* like seconds since start), and the MIB wants a very specific and > unusual format. > > Date of next leap second: from what I can gather from the 2-bit leap > second code this is predicted a day in advance? > > Next leap second direction: so long as the 2-bit code is a usable source > this is a simple one. > > Heartbeat interval. > > -- > *"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 > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 wrote: > Apologies to all for having been rather invisible recently. What > happened was I got an emergency call for help from a project we rely on - > GNUPLOT. (Perhaps not everyone knows this is the graphics engine we use > in ntpviz, which is one of our sexier new features.) > > It seems that SourceForge, where GNUPLOT is hosted, is soon to shut > down CVS service (I don't remember the drop-dead date but I think it's > in November). The GNUPLOT guys decided they needed a git conversion > *immediately*, and they did, and I was the logical person to turn to. > > Which would have been no big deal except that CVS conversions are > horrible time- and attention-sinks. This one was only moderately > nasty as such things go, but that was enough to eat my bandwidth > for two weeks. Anyway, happy ending - GNUPLOT will not die and > ntpviz still has a back end. > > We have some loose ends from 1.0 to clean up. I took care of a few > of them today; unpeer needed to be upgunned so it can take a type/unit > pair rather than a magic IP address, and there was a pending dead-code > removal. I've also removed some obsolete to-dos. > > Here's what I see as the top of the near-term agenda: > > * Fred and Gary need to have, and resolve, their argument about what to > do to the build recipe around Python library installation. For > concreteness, this should probably start with a proposed patch from > Fred. > > * There are couple of Mac-support merge requests pending from > Fred. Whether to take them is not a technical question but a > policy one, how hardnosed we're going to be abour our C99/POSIX > baseline. In view of our adoption strategy, are older versions > if Mac OS X important enough to make an exception? Discuss; > once the pros and cons have been laid out we'll want a ukase > from Mark. > > * I would like us to plan on a short-cycle 1.1, to land early January, > with SNMP support as the big new feature. Ian: is this a realistic > timeframe? Is there any support you're not getting that you'll need > to get this done. > > Senior devs: please chime in with any goals you think we ought to > pursue for 1.1. > > I've got a really big one that's not going to get done in one release > cycle, but which I consider worth some thought beginning now. > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > The American Republic will endure, until politicians realize they can > bribe the people with their own money. > -- Alexis de Tocqueville > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 alt ** Ubuntu as an alt ** Fedora as an alt ** Yocto ** ipkg https://en.wikipedia.org/wiki/Ipkg ** opkg https://en.wikipedia.org/wiki/Opkg ** Automotive Grade Linux ** Amazon Linux (I plan to shamelessly use my dayjob position here) ** Scientific Linux * Once the snmp subagent is returning data: ** a TUI display app for it ** a GUI display app for it ** something cool: write another closely related snmp subagent for the GPSD service I agree with ESR about suggested work assignments: * GEM: startup jittery and time-to-stable * DFF: data hiding patch * ESR: local monitoring mode * Ian: make snmp return data * Hal: keep doing your amazing work * Everyone else: what would you like to do? ..m -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/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. ..m On Sat, Oct 28, 2017 at 11:36 PM Hal Murray via devel wrote: > I'm working with an old NMEA device. It sends things like: > > $GPRMC,062409,A,3726.0822,N,12212.2630,W,000.3,190.6,150398,015.5,E*6A > I've got a fudge time2 to fix that. It seems to be working. > > I'm seeing stuff like this in the log file: > 28 Oct 22:48:51 ntpd[2504]: NMEA(0) Changed GPS epoch warp to -4096 weeks > > Anybody know that chunk of code? Is that code actually doing anything? If > it is doing something, why is my fudge working as I expect? > > > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 https://gitlab.com/NTPsec/ntpsec/commit/3f72203164e9eebae0865f1b8dcd41b250bc232f I would like to thank everyone who has worked so hard to get us here, especially Hal Murray, Gary Miller, Daniel Franke, Eric Raymond, Cathy Raymond, Ian Bruene , John Bell, Matt Selsky, Fred Wright, Achim Gratz, and Susan Sons. I'm sure I've missed people in that list, and I apologize now for doing so. I would like to thank our past and present institutional sponsors and supporters, including Indiana University, the United States National Science Foundation, OARcorp, Hewlett Packard Cloud Computing Service, the Linux Foundation Core Infrastructure Initiative, Software in the Public Interest, Penguicon, Two Sigma Investments, Google Compute Service, Oregon State University Open Source Lab, the Internet Civil Engineering Institute, the Mozilla Foundation, and the Thiel Foundation. Everyone, take a break from NTPsec. I don't want to see any commits or any planning emails for the rest of the week. Thank you all again. ..m -- Mark Atwood Project Manager of the NTPsec Project +1-206-604-2198 PSTN/GSM/SMS/Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Our last-minute mess
My inclination is to keep his patch, document the lack of FHS compliance, and roadmap a fix to get_python_lib, possibly by nudging the WAF or python communities to write it. And we again specifically thank Fred for his patch. ..m On Wed, Sep 27, 2017 at 4:39 AM Eric S. Raymond via devel wrote: > Hal Murray : > > > > > I'd like to hear from the senior devs (and anyone else with something > > > intelligent to say!) on this. > > > > You need a steering committee to represent the customers on things like > this. > > Good idea. I'll keep that in mind as we get more customers. > > > I didn't find enough info in the wiki page to enlighten me. I get the > > general idea, but I don't know the tag that describes out software. Is > it > > real system software? What about devel mode? > > It's what FHS consider "non-essential system software" - needs to run as > root > at boot but is not required for single-user recovery mode. I couldn't > find a > reference to "devel mode" in the FHS spec, so I can't answer that question. > > > Distros aren't going to use our install script. They don't want to > install > > stuff, they want to package it up in a .deb or .rpm or whatever. How do > we > > get them the info they need in a format they can use? > > That's what the packaging/ directory is for. It's supposed to contain both > meta data examples and documentation that is guidance for packagers. > > > What are the plans for splitting out the python stuff? Do most distros > > include Python in their basic package? > > Python is effectively universal at this point. > > The rational partitioning is probaly (1) core daemon alone, (2) ntpq + > ntpmon, > (3) everything else. > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be > your own. > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 often they displayed "ZERO" or "". It's a neat idea. Not for 1.0 release, buy maybe soon after. ..m -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 reference example configuration should refer to ntpsec.pool.ntp.org, and hopefully NTPsec emits sane error messages if it's started before that DNS entry is created. Thank you for your feedback Achim. You helped us avoid a misstep there. ..m On Wed, Sep 20, 2017 at 12:47 PM Achim Gratz via devel wrote: > Eric S. Raymond via devel writes: > > I think the global pool name is a special case here. Why are they > advertising > > that service if not to be used in exactly this way? > > No, I think their rule (and no, you don't get to redefine it) is that if > you wanted to have a hardcoded/default pool association you'd have to > ask them for an ntpsec pool. That might be a possibility, but probably > not an immediate one. > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > SD adaptation for Waldorf rackAttack V1.04R1: > http://Synth.Stromeko.net/Downloads.html#WaldorfSDada > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 20, 2017 at 10:35 AM Achim Gratz via devel wrote: > Eric S. Raymond via devel writes: > > There are three obvious ways to address this. > > > > 1. The infosec-focused way. Change the default restrictions to be > > "allow nothing." This way, if you bring it up with no config, there's > > no harm. It just spins inaccessibly. > > If it does that without complaining loudly enough some folks might think > it's actually doing something and act surprised when it doesn't. > > > 2. User-friendly way. Bring it up with these permissions: > > > > restrict default kod limited nomodify nopeer noquery > > restrict -6 default kod limited nomodify nopeer noquery > > restrict 127.0.0.1 > > restrict -6 ::1 > > Stop it here. No pool (I think hardwiring pool names without consent of > the pool administrators is a no-no). Also, no drift file. You might > want to add "noserve notrust" to the last two statements. > > > pool pool.ntp.org iburst > > driftfile /var/lib/ntp/ntp.drift > > > > That is, the behavior 99.9% of all installations want. > > > > 3. Leave current behavior alone. > > The current behaviour was addressing a different target audience, so I > see no reason to keep it when we are targeting a different population. > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > Factory and User Sound Singles for Waldorf rackAttack: > http://Synth.Stromeko.net/Downloads.html#WaldorfSounds > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 Mark! > > > > On Wed, 13 Sep 2017 23:15:10 + > > Mark Atwood wrote: > > > > > We could just grab from NetBSD7. > > > > Nope, that is very low level FPU assembly code. Very arch dependent. > > Usually buried deep in the C compiler as a builtin. > > > > Just look at gcc for all the arch options it has for floating point! > > > > > Or if we know it's an IEEE754 > > > float, just do the direct bit ops. > > > > Sort of a float, it is a long double. The IEEE754 does not specify how > > big in memory a long double is. It may be 80 bits, or 128 bits, or? > > > > IEEE754 also does not specify how the bits are arranged in memory. > > > > > Or the direct fp cpu op. > > > > Assuming you even have a long double FPU. Remember this has to > > support various, ARM, i386, amd64, MIPS, sparc, etc. you may not even > > have any FPU. > > Mark: Rolling our own lldexp is getting into the territory of "really > bad ideas that raise the hair on my neck". > > The reason I'm getting that feeling is that lldexp is unlike - say - > strlcpy > in an important way. Floating-point code is a *notorious* defect > attractor. > It's infamously difficult to even test it in a way that catches all its > edge > cases, especially cross-architecture. > > I can all too easily see us committing to this, then spending an > amount of maintainence effort that diverges to infinity on code that > is never quite right, constantly delivering a trickle of unpleasant > low-level surprises. > > In principle, things could be different. If we had a dev with a strong > background in FP code and numerical analysis (say, as strong in that > domain as Daniel is in security/crypto), I might consider a homebrew > emulation a risk worth taking for an OS version that is minor-platform > and aging out rapidly. > > As it is, give the team we have, I'm going to strongly recommend not going > there. We're good, but we're no good enough at *this*. > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be > your own. > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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
wrote:
> Yo Mark!
>
> On Wed, 13 Sep 2017 22:31:31 +
> Mark Atwood via devel wrote:
>
> > How much complexity would it add to add the missing fp functions in
> > the same way the strlcpy function is?
>
> I think all we need for NetBSD 6.1 is ldexpl().
>
> Here is one way, a very slow way, to do it:
>
> long double ldexpl(long double value, int e)
> {
> if (value == 0 || value == INFINITY || value == -INFINITY || value !=
> value)
> {
> // Return +0.0/-0.0, +INF/-INF and NaN as-is
> }
> else
> {
> while (e > 0)
> value = value * 2, e--;
> while (e < 0)
> value = value * 0.5f, e++; // won't round denormals correctly
> }
> return value;
> }
>
> Ripped from:
>
> https://github.com/alexfru/SmallerC/blob/master/v0100/srclib/ldexp.c
>
> NTPsec only uses 32 and -32 values for 'e', so some simplification
> possible.
>
> The INF tests should likely be replaced with isfinite().
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com Tel:+1 541 382 8588 <(541)%20382-8588>
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you canโt measure it, you canโt improve it." - Lord Kelvin
> ___
> devel mailing list
> devel@ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
--
Mark Atwood
http://about.me/markatwood
+1-206-604-2198 Mobile & Signal
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: NetBSD 6.1.5 doesn't have ldexpl in math.h
How much complexity would it add to add the missing fp functions in the same way the strlcpy function is? It doesnt even have to be fully generic, just if NetBSD6 etc. If a BSD is still supported by it's community, I'm not happy about dropping it. ..m On Wed, Sep 13, 2017 at 1:17 PM Eric S. Raymond wrote: > Mark Atwood via devel : > > 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"? > > I think the last OS-related shim where we define substitute code is gone. > It was the kludge for pre-10.12 Mac OS X, which turned out not to work > because > (a) in some versions the system headers didn't match the docs, and (b) we > got > a report that in some versions the set-time primitive doesn't work. > > We still some compatibilty shims of a more suerficial kind, supplying > things > like strlcpy and friends if the native C library doesn't have them. > > We also have some code that is conditionally disabled if the native OS's > features don't support it. This is true notably in the sandboxing code, > where privileges are dropped at startup. > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be > your own. > > > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 wrote: > > > Is NetBSD 6 still under development?If so, we can send them a > bugreport. > > Development has moved on to 7 and soon to be 8. > > 6 is still supported which means security fixes get backported. > > > > > -- > These are my opinions. I hate spam. > > > > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 long as you know your arch and fp arch. .. On Fri, Sep 8, 2017 at 1:17 PM Gary E. Miller via devel wrote: > Yo Hal! > > On Thu, 07 Sep 2017 20:09:44 -0700 > Hal Murray wrote: > > > > No, NTP doesn't do anything interesting here. The code predates > > > the era whend long double was standardized and generally available, > > > a transition that might have been as late as C99. > > > > So it seems reasonable to assume that it's OK to run without the > > extra precision. > > Not reasonable, it fixed a bug. > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 <(541)%20382-8588> > > Veritas liberabit vos. -- Quid est veritas? > "If you canโt measure it, you canโt improve it." - Lord Kelvin > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 > mine too. > > There is a quirk tangled in this area. I don't know if there is a bug for > it. > > When the pool mode adds a server, if needed, it pokes a hole in the > restrictions. > > We need to remove that hole when that server is removed. > > I think we need to add a new flag to indicate that the restrict slot was > automatically added. > > Maybe we should add another flag to disable poking holes. Maybe it's an > enhancement rather than bug fix, but this would be the time to do it. > > --- > > I didn't see fixing ntpq retransmissions on your list. (I'm still catching > up so I might have missed it.) > > I think the way to fix this is to clean up the logging. > > I've never been particularly happy with the standard log level approach. > Maybe it would make more sense if there was a description of what the > levels > were intended to cover. > > Some of the cruft may be my fault. I hacked a lot of the logging to do > what > I needed when chasing some bug(s?). I may have broken any plan that you > had. > > Maybe we need log-to-file. > > In the context of fixing this bug, I think I would like a logging mode that > showed the command line and the packets. Reply packets can be verbose so > maybe we need a switch/level for that. Maybe we need another switch/level > to > show steps within long running commands. Mumble. > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 Mobile & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 NTPSec on > > HPUX, the few installations I know are strictly in "do not touch, very > > important business application running, last guy who understood this left > > three years ago". > > I share your skepticism. > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > Please consider contributing to my Patreon page at > https://www.patreon.com/esr > so I can keep the invisible wheels of the Internet turning. Give > generously - > the civilization you save might be your own. > > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/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 code is setup to prefer SO_BINTIME. > > Unfortunately,SO_BINTIME doesn't seem to work for IPv6. ?? > > I've disabled SO_BINTIME so it will use SO_TIMESTAMP. Back to testing. > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 wrote: > Yo All! > > Does NTPsec support HPUX? I see some code that only applies to HPUX. > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 <(541)%20382-8588> > > Veritas liberabit vos. -- Quid est veritas? > "If you canโt measure it, you canโt improve it." - Lord Kelvin > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 164518:(VARARGS) /libisc/error.c: 31 in isc_error_unexpected() /libisc/error.c: 39 in isc_error_unexpected() *** CID 164518:(VARARGS) /libisc/error.c: 31 in isc_error_unexpected() 25 char errbuf[256]; 26 static int unexpected_error_cnt = 0; 27 28 va_start(args, format); 29 30 if (unexpected_error_cnt >= MAX_UNEXPECTED_ERRORS) >>> CID 164518:(VARARGS) >>> va_end was not called for "args". 31 return; /* avoid clutter in log */ 32 33 msyslog(LOG_ERR, "%s:%d: unexpected error:", file, line); 34 vsnprintf(errbuf, sizeof(errbuf), format, args); 35 msyslog(LOG_ERR, "%s", errbuf); 36 37 if (++unexpected_error_cnt == MAX_UNEXPECTED_ERRORS) 38 msyslog(LOG_ERR, "Too many errors. Shutting up."); /libisc/error.c: 39 in isc_error_unexpected() 33 msyslog(LOG_ERR, "%s:%d: unexpected error:", file, line); 34 vsnprintf(errbuf, sizeof(errbuf), format, args); 35 msyslog(LOG_ERR, "%s", errbuf); 36 37 if (++unexpected_error_cnt == MAX_UNEXPECTED_ERRORS) 38 msyslog(LOG_ERR, "Too many errors. Shutting up."); >>> CID 164518:(VARARGS) >>> va_end was not called for "args". To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRaciFpIUwPZI-2Fd-2FFHWJ2pO-2Fd2R8mjOSXjO4mfMZb3eoig-3D-3D_w2FF8AYzKpBRjzA7UjULRUPBwnqYRQu4vsrZcGe8M1E58y8ueCmtep-2BJJCB6GCX-2F1lXrObn2teBdcw2-2FMZ8GVc50Q6Nh8y3bbqjVtn2bu2LAy6UVglpyB6c9Zmcc2s54Wl-2FuGA31qx8idrkcCWVtqVJ0BJtjrngWLDmEe4TWkNzdh9CQQw79Ig5atW8GzRdj4WzRBiGIjP6aUcUltUNblov2S9QePlbPAwcjVNb-2BgPE-3D To manage Coverity Scan email notifications for "m...@mark.atwood.name", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4Vp7-2BrS139Us2-2Bc0cUP4m1FXTBMtbRIlyBBRBlV54D0t0NP3dLzlgVMJhtVR8EEORdb1j00NTRLd5XDYZ7LdU32kE0zwp1gSq4km8aiElwOU-3D_w2FF8AYzKpBRjzA7UjULRUPBwnqYRQu4vsrZcGe8M1E58y8ueCmtep-2BJJCB6GCX-2Fio6P1o79pt61iKa-2BE-2BhsGbV0A-2BX2zhMQTolXzLxMrUDvmamRMc7QG6UKRec-2BpEoCHehr37J0tkYzqEzfD8wvIXp3hkpzQRMEKSA3MFtE2W71ASMZJ-2FCjARRCWNjBdR8nDKjdOXrx3-2BqQsVYuZVhMuzJHnCwDNQ7t9B09Uv5liSk-3D ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 I'm not sure NTPsec needs. Has anyone > used the set and used ISC_PLATFORM_USEBACKTRACE? In single threaded > code like ntpd, and with modern gdb I see no point to that code. > > I wonder if it even works at all. I'd like to rip it out if no one cares. > > Anyone care? > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 <(541)%20382-8588> > > Veritas liberabit vos. -- Quid est veritas? > "If you canโt measure it, you canโt improve it." - Lord Kelvin > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec on MIPSbe
ISTR years ago seeing some C magic, where in a compile time declaration, one packs bytes into a struct union with an integer, and then at runtime looks at the integer value to determine the endianess on the fly. Downside: it has to be tested at runtime, which means the compile time optimizer is less likely to remove the unused code paths. Is it the case that the C standard or the POSIX standard do not define a standard #define that tells the current endianess? That seems like just the sort of thing that the standard should do... ..m On Tue, May 23, 2017 at 11:59 AM Hal Murray wrote: > If you are keeping track... > > It builds and runs on a 32 bit PowerPC MAC-Mini, both Debian and FreeBSD. > > #define WORDS_BIGENDIAN 1 > > There are problems with the firmware setting up the time keeping parameters > incorrectly. I can patch it via Open Firmware, but haven't figured out how > to make it stick over reboots. > > > -- > These are my opinions. I hate spam. > > > > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 not have libseccomp. I installed > python-dev, bison, and build-essential manually. > > waf configured, built, passed checks, and installed. Running now for 12 > hours > > Will upgrade to Debian 8.8 now. > > -- > Sanjeev Gupta > +65 98551208 <+65%209855%201208> http://www.linkedin.com/in/ghane > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 recur". Often, I once I'm done, I will remove the DEBUG_MRA_FOO and replace it with an assert, again using judgement and taste. I will leave it to your judgement and taste. ..m On Fri, May 19, 2017 at 12:21 AM Hal Murray via devel wrote: > > Have you thought about logging and/or printout for debugging? > > We have DEBUG and DPRINTF. I almost never use them because the signal to > noise is so low - it prints stuff from all over but I'm only interested in > one small corner. > > I occasionally add various msyslog lines when I'm chasing a bug and throw > them away after I have found it. > > Would it make sense to preserve them with something like an ifdef DEBUG_FOO > symbol? > > Or if (DEBUG_FOO) so it only adds one extra line of source code rather than > 2? (no endif) > > Or just put a // in the front of the ones you don't want. > > > > -- > These are my opinions. I hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Test formatting standard
That sounds useful and productive. Unless GEM, ESR, or Hal have any objection, feel free to go through the other existing tests and clean them up the same way. Thanks! ..m On Wed, May 17, 2017 at 6:34 PM Ian Bruene via devel wrote: > Currently the tests follow a general format of a comment line describing > what a particular test is attempting to test, followed by the test. I > propose that the first line of each test_* function be the assignment of > a shorter name for the function being tested. For examples see a number > of the tests in test_util.py. > > Reasoning: > It greatly reduces the number of unnecessary characters typed. > It eliminates the potential of typos in the function name when making > new tests, which due to the sheer length are more annoying to track down > than they should be. > It is added semantic information; clearly establishing the correct > function in a similar way to a docstring. > The cost of doing it this way is negligible: one very simple line of > source, and one assignment. > > I've already been doing this with the tests I write, and it looks > cleaner than the alternative. Again, see test_util.py for examples. > > -- > In the end; what separates a Man, from a Slave? Money? Power? > No. A Man Chooses, a Slave Obeys. -- Andrew Ryan > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 > > > existing net-snmp daemon and communicate via the AgentX (RFC2741) > > > protocol? Or are you thinking of a stand-alone snmp daemon? > > > > I assumed a standalone program, but I had no knowledge of other > > options. > > > On any system under remote management you can assume the SNMP port is > already in use. So AgentX is the way to go. > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 <(541)%20382-8588> > > Veritas liberabit vos. -- Quid est veritas? > "If you canโt measure it, you canโt improve it." - Lord Kelvin > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 already written deeply and well on it. ..m On Wed, Apr 26, 2017 at 11:40 AM Gary E. Miller via devel wrote: > Yo Hal! > > On Wed, 26 Apr 2017 11:26:42 -0700 > Hal Murray via devel wrote: > > > Unix/POSIX has the same problem with time_t > > It rolls over into the sign bit in 2038 > > Only for some. Not an issue with 64 bit Linux. > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 <(541)%20382-8588> > > Veritas liberabit vos. -- Quid est veritas? > "If you canโt measure it, you canโt improve it." - Lord Kelvin > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/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 hate spam. > > > > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpq vs new DNS
On Sun, Apr 16, 2017 at 11:16 PM Hal Murray wrote: > > Does anybody have any great ideas for how to take advantage of this extra > info? > I've been thinking that over for the past week, and I don't have a great idea on how to take advantage of that. ..m -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 wrote: > > > >> You could use it as an example of how to do it right. > > > Er, *what*? > > > > Fix the code. Do it right and cleanly. > > I'm all for that, but until we find a real Jupiter user we can't test, > and are fixing it to no purpose. > > > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 <(541)%20382-8588> > > Veritas liberabit vos. -- Quid est veritas? > "If you canโt measure it, you canโt improve it." - Lord Kelvin > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel -- Mark Atwood http://about.me/markatwood +1-206-604-2198 SMS & Signal ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
