Re: NTPsec 1.2.3 released
On Tue, Jan 02, 2024 at 08:52:53PM -0800, Fred Wright via devel wrote: > It should, though if the timestamps get updated in the process it would > trade bad name ordering for bad timestamp ordering. The ideal thing would > be to fix the names but keep the original timestamps. Three of the four > files have the name(s) embedded, so a simple rename wouldn't work. That > makes it a little dishonest to keep the old timestamps, though it matches > the spirit of the timestamps. :-) I fixed the file names/contents (and re-signed) and I used the timestamps from the original files. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.3 released
On Tue, Jan 02, 2024 at 08:55:38PM -0800, Fred Wright via devel wrote: > That explains it. I don't subscribe to the announce list, based on the > expectation that announcements would be cross-posted here. Cross-posting > only needs to be done by the sender, while cross-subscribing would need to > be done by every subscriber. I cross-posted the message to all 3 lists, but our smtp server and/or mailman instance ate the delivery to the devel@ and user@ lists. I may dig into this at a later date. Or I'll update my docs to send to each of the 3 lists individually for the short-term. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.3 released
On Tue, Jan 02, 2024 at 07:21:39PM -0800, Fred Wright via devel wrote: Hi Fred, > There are a couple of minor issues that I should have noticed in the RC but > didn't: > > 1) The 1.2.2a entry is missing from NEWS. This is presumably because of the > way the patch release was forked off of the master branch, though the entry > still should have been included in master. As far as the master branch > history goes, 1.2.2a never existed. This is easily fixed. I see 1.2.2a at https://gitlab.com/NTPsec/ntpsec/-/blob/master/NEWS.adoc?ref_type=heads#user-content-2023-08-02-1-2-2a Where do you see it missing? > 2) This RC version was named 1.2.3rc1 instead of 1.2.3-rc1. This screws up > the sort order and makes it look like the RC version is newer than the > release version. It didn't follow the precedent of 1.2.2-rc1, which did it > correctly. E.g.: > > MacPro:~ fw$ port livecheck ntpsec > ntpsec seems to have been updated (port version: 1.2.3, new version: 1.2.3rc1) I'm not familiar with "port livecheck". If I repack/rename the tarballs on the website to include a hyphen, will that make the port command happy? Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release
On Wed, Dec 06, 2023 at 01:56:51AM +, Matthew Selsky via devel wrote: > Sounds good. I'll aim to release ~15-Dec-2023. Hi all, Sorry for the delays. I have a release candidate tarball available: https://ftp.ntpsec.org/pub/releases/ntpsec-1.2.3rc1.tar.gz https://ftp.ntpsec.org/pub/releases/ntpsec-1.2.3rc1.tar.gz.asc I'll wait until late Saturday and then publish a final tarball. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release
On Sun, Dec 17, 2023 at 08:17:23PM -0800, Fred Wright via devel wrote: Hi Fred, > The main issue I've found is that the "struct var" in ntp_control.c, is > relying on anonymous unions, which are a relatively new language feature. > They were originally a GNU extension, eventually becoming official in C11. > But significantly increasing the compiler requirements just for one table > doesn't seem terribly desirable. Should our use of "-std=c99" have caught this? Or is that flag not intended to catch features newer than standard X? > There are also a bunch of warnings with some compilers, which might be worth > looking at. They're often fairly easy to fix, and sometimes indicate actual > problems. Do you have specifics on distros/compilers that are showing warnings so we can run these to ground? > I also stumbled across something (which may not be new) where it appears > that if libaes_siv is installed as a system library, it's preferred over the > bundled version. That probably doesn't change the actual behavior, but may > lead to opportunistic builds. Interesting. Which distro includes libaes_siv as a system library? We don't modify libaes_siv so using the system version should be fine. Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release
On Sat, Dec 02, 2023 at 08:09:00PM -0800, Hal Murray wrote: > > I think you should release what we have as soon as it is convenient. > > There are many more things I would like to include but we aren't making much > progress so it's time to do it. Hi Hal, Sounds good. I'll aim to release ~15-Dec-2023. Can you and others make sure that NEWS is up-to-date, especially for user-facing changes? I'm thinking about AES becoming the new default for ntpq, etc. I'll review this as well. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: [Git][NTPsec/ntpsec][master] Fix mode 6 client to round up to 4 bytes (was 8)
On Sun, Nov 26, 2023 at 11:43:14PM +, Hal Murray (--- via vc wrote:
> Hal Murray pushed to branch master at [1]NTPsec / ntpsec
>
> Commits:
>
> • [2]d98ce8d7
>by Hal Murray at 2023-11-26T15:42:51-08:00
>
> Fix mode 6 client to round up to 4 bytes (was 8)
>
> 1 changed file:
>
> • [3]ntpd/ntp_control.c
>
> Changes:
>
>• [4]ntpd/ntp_control.c
>
>══
>
> ... ... @@ -879,7 +879,7 @@ process_control(
> 879 879 properlen = req_count + (int)CTL_HEADER_LEN;
> 880 880 /* round up proper len to a 8 octet boundary */
> 881 881
> 882 - properlen = (properlen + 7) & ~7;
>882 + properlen = (properlen + 3) & ~3;
> 883 883 maclen = rbufp->recv_length - (size_t)properlen;
> 884 884 if ((rbufp->recv_length & 3) == 0 &&
> 885 885 maclen >= MIN_MAC_LEN && maclen <= MAX_MAC_LEN) {
Hi Hal,
Does the comment on line 880 also need to be updated?
Cheers,
-Matt
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: Time for a release?
On Sun, Oct 29, 2023 at 10:50:56PM -0700, Hal Murray via devel wrote: > > The last time this was suggested, I encouraged waiting until we fixed mssntp. > Well, I think we have it fixed but we haven't found anybody to test it. Sounds good. Can you please update NEWS.adoc with mssntp and other news? > Time for lots of testing. And documentation checking/cleanup. What sort of testing did you have in mind? Any specific doc cleanup? > Does anybody have any features that should or must go in or bugs we should > fix? > (I haven't looked through issues yet.) Here are the open issues the caught my eye: https://gitlab.com/NTPsec/ntpsec/-/issues/806 https://gitlab.com/NTPsec/ntpsec/-/issues/802 (is this resolved with our latest FIPS changes, and do we have an environment to test it?) Do you think these or any others should delay the release? > What is the policy on ntpq documentation? We have tuned the code for use > with our version of ntpd, but it still mostly(?) talks to the old > Mills/classic version. I noticed lots of references to multicast and > broadcast in the man page. We removed the code that supported that stuff > ages ago. The *cast references are now clutter if you are interested in our > code, but might be relevant if you are looking at an old old system. Should > we leave the *cast documentation in or clean it out? Are we able to use our ntpq to probe *cast fields on other ntp daemons that support it? If so, leave it in. > I have 3 hacks that were used to debug talking to Samba. Is a subdir under > attic a reasonable place for them? Sure. Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: What's magic about /tmp/? ntpd can't find UNIX socket
On Thu, Oct 19, 2023 at 02:27:56PM -0700, Hal Murray via devel wrote: > It works fine from my test program. What's different about ntpd? Hi Hal, Are you running ntpd with --jaildir (or -i) or some chroot-like functionality? Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: What's magic about /tmp/? ntpd can't find UNIX socket
On Wed, Oct 18, 2023 at 09:37:06PM -0700, Hal Murray via devel wrote: > I put the samba socket in /tmp/ > ntpd couldn't see it. My test programs work fine. > > 18 Oct 20:52:00 ntpd[5671]: SIGND: can not connect socket > '/tmp/fake-samba-socket/socket': No such file or directory > > What's magic about ntpd and /tmp/? > I'm running on Fedora. > > It works when I move the socket to /home/murray/, but I was trying to keep my > name out of it so somebody else could run my hacks without any edits. Hi Hal, Are you using selinux or something that would prevent access to /tmp? You can disable selinux temporarily by following the directions at https://www.tecmint.com/disable-selinux-in-centos-rhel-fedora/ It could also be auditd and then something like "audit2why -a" might show you why auditd blocked the access. Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: I just pushed ntsstats and ntskestats
On Mon, Sep 25, 2023 at 04:29:37PM -0700, Hal Murray via devel wrote: > I have a slight preference for double, but it doesn't really matter. > > I've seen some example with double on the left bar and single on the > top/bottom. > That was probably the web version. Hi Hal, Do you have an example of something that renders the way that you want? I don't think the man page backend for asciidoc renders "delimited literal block" in a special way (see https://docs.asciidoctor.org/asciidoc/latest/verbatim/literal-blocks/ for the asciidoc description). I'll see if I can find the man page backend code for asciidoc to see what it's doing. > I thought I send in an Issue but can't find it... > > Please check the bottom few lines on the man pages. At least one of them > didn't get updated to use our trailer stuff and still has the Mills version. Which man page shows this issue? Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
On Mon, Sep 04, 2023 at 02:25:46PM -0700, Gary E. Miller via devel wrote: > From RHEL: > > "The RHEL 8 AppStream Lifecycle Page puts the end date of RHEL 8's > Python 2.7 package at June 2024." > > https://access.redhat.com/solutions/4455511 Hi Gary, Is the implication that we can safely drop python2 support after June 2024? Are there any other distributions that ship python2 that we want to maintain support for? How much does it cost us to maintain python2 support in our own code? Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.2a released
On Mon, Aug 07, 2023 at 02:14:40PM -0500, Richard Laager via devel wrote: > That said, I did advocate for merging it back in to master (as a no-op). But > I don't feel particularly strongly about that. The code fix itself is already in master. I'll merge the 1.2.2a NEWS into master later this evening. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
NTPsec 1.2.2a released
The NTPsec Project is pleased to announce the tagging of version 1.2.2a * Fix a crash in ntpd if NTS is disabled and an NTS-enabled client request (mode 3) is received. (CVE-2023-4012) #794 For other changes since the previous release, please consult the project NEWS.adoc file at https://gitlab.com/NTPsec/ntpsec/-/blob/master/NEWS.adoc Getting this release You can clone the git repo from https://gitlab.com/NTPsec/ntpsec.git and you can download the release tarballs with sums and signatures from https://ftp.ntpsec.org/pub/releases/ This release is signed with the GPG key id E57235D22764129FA4F2F4D17F52608ED0E49D76 -- Matt Selsky Release Manager NTPsec Project ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.2a released
On Fri, Aug 04, 2023 at 01:47:29PM -0700, Fred Wright via devel wrote: > And for that matter, what exactly is 1.2.2a, given that there's no git tag > for that version? Hi Fred, 1.2.2a is 1.2.2 + the 2 line patch to avoid the crash. We'll release 1.2.3 in late August with all of the changes in HEAD since 1.2.2 Please use "git fetch origin --tags" to pull the https://gitlab.com/NTPsec/ntpsec/-/tags/NTPsec_1_2_2a tag Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.2a released
On Thu, Aug 03, 2023 at 11:38:25PM -0700, Hal Murray wrote: > Should that also go to users@ and devel@? I'll do this shortly. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: [Git][NTPsec/ntpsec][master] 3 commits: Minor cleanups to restrict
Hi Hal, >• [10]libntp/pymodule-mac.c > >══ > > ... ... @@ -143,6 +143,10 @@ void do_mac(char *name, > 143 143 *maclen = 0; > 144 144 return; > 145 145 } > 146 +/* Coverity CID 462307, 2023 June 11 > 147 + * CMAC API is undocumented and deprecated in OpenSSL 3. > 148 + * See libntp/macencrypt.c */ > 149 +/* coverity[checked_return] */ > 146 150 CMAC_Update(cmac_ctx, data, (unsigned int)datalen); > 147 151 CMAC_Final(cmac_ctx, mac, maclen); > 148 152 if (MAX_MAC_LENGTH < *maclen) I think this needs to be "coverity[CHECKED_RETURN]". The man pages for CMAC_Update document that the return is either 0 or 1. Do we want to check this return code? >• [12]tests/unity/unity.c > >══ > > ... ... @@ -1002,6 +1002,7 @@ void UnityAssertFloatSpecial(const >UNITY_FLOAT actual, > 1002 1002 is_trait = !isinf(actual) && !isnan(actual); > 1003 1003 break; > 1004 1004 > 1005 +case UNITY_FLOAT_INVALID_TRAIT: /* Supress warning */ > 1005 1006 default: /* including UNITY_FLOAT_INVALID_TRAIT */ > 1006 1007 trait_index = 0; > 1007 1008 trait_names[0] = UnityStrInvalidFloatTrait; > ... ... @@ -1142,6 +1143,7 @@ void UnityAssertDoubleSpecial(const >UNITY_DOUBLE actual, > 1142 1143 is_trait = !isinf(actual) && !isnan(actual); > 1143 1144 break; > 1144 1145 > 1146 +case UNITY_FLOAT_INVALID_TRAIT: /* Supress warning */ > 1145 1147 default: /* including UNITY_FLOAT_INVALID_TRAIT */ > 1146 1148 trait_index = 0; > 1147 1149 trait_names[0] = UnityStrInvalidFloatTrait; Has this fix been submitted upstream to https://github.com/ThrowTheSwitch/Unity? Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Does anybody use (aka test) MDNS?
Hi Hal, I do not use it. My servers are all configured directly in ntp.conf Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
On Wed, Feb 08, 2023 at 11:16:53AM -0800, Gary E. Miller via devel wrote: > The coverity scans are not part of the GitLab CI. They run off the > GitHub mirror. The GitLab CI triggers the scan. See https://gitlab.com/NTPsec/ntpsec/-/pipeline_schedules Coverity then points at GitHub for some reason. But the Coverity intermediate .o files, etc, are uploaded for analysis by GitLab CI. Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: New Defects reported by Coverity Scan for ntpsec
On Mon, Feb 06, 2023 at 10:51:02PM -0800, Hal Murray via devel wrote: > > > Do you have a coverity account? > > https://scan.coverity.com > > Then go to "My Dashboard" and "Add project". > > Should we document that? Where? The account creation seems self-explanatory. Or did you want to document something else? > It looks like Coverity is running over on github. Yes, Coverity is pointing at the GitHub mirror. > Is our copy-to-github stuff documented? It's a 1-line checkbox in our GitLab repo. There's no documentation, per se. > I'm waiting for somebody to approve me. I approved your account. > >> Date: Thu, 02 Feb 2023 05:48:37 + (Wed 21:48 PST) > > It was detected on Feb 5. > > So the turn around is days rather than hours. No. We run the Coverity CI job weekly via a schedule, not on every commit since I was concerned about abusing the Coverity scanner minutes and other reasons. I think we can re-evaluate that decision since our merge rate is low enough and run Coverity on each commit, but after merging since it relies on a GitLab runner that not everyone may have access to (for reasons that I don't want to go into here). I'll work on running Coverity post-merge. Do you need the ability to run Coverity offline on your development host before you push? Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Release coming, take 2
Hi all, I plan to cut a release on Thu 12/22/2022. I'm sorry about the delays in getting this release out the door. If there's anything that absolutely must be in this release and can't wait until the next release, please let me know. Otherwise, I plan to tidy up the NEWS file as needed and then ship what we have. Going forward, I'll try to make sure that I'm doing releases more regularly, maybe 6 months or so? Thanks everyone for your patience. Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: devel/make-tarball broken
On Wed, Dec 14, 2022 at 03:39:29PM -0800, James Browning via devel wrote: > 'Do not apply transform to symbolic link targets' [1] Which I > got from googling 'gnu tar transform' IIRC. It is also a > gnuism, but I do not see a portable transform type option as > tar on macOS uses -s and some BSDs seem to lack even that. I'll take a look this weekend about using "gtar" on macos so we get the GNU semantics. > > I added PIVOT.h last Jan 29, so this has been broken for almost a year. > > > > Is gitlab running option-tester weekly or monthly? Can it test > > make-tarball > > too? > > I don't think we need a bunch of runners testing devel/make-tarball, > one should be sufficient. Agreed. We don't need cross-platform compatibility at this time. > > Matt: > > I have updated PIVOT.h > > Is testing make-tarball on Mark's list? > > (before doing the mechanics of the release) > > despite not being Matt... > no, but it's called in devel/release before any repo changes > are made. Thanks, James! Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release, wildcards, etc
On Fri, Apr 22, 2022 at 12:13:25AM -0700, Hal Murray via devel wrote: > nts nowildcards at the top level to set the default > nowildcards at the server level > wildcardsOK at the server level to override the default Hi Hal, Sorry, I'm not following what you mean here. Do you have a patch or merge request that I can look at? Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Wildcards on NTS certificates -- security
On Fri, Feb 25, 2022 at 12:02:34PM -0800, Gary E. Miller via devel wrote: > Yo Hal! > > On Tue, 22 Feb 2022 14:39:21 -0800 > Hal Murray via devel wrote: > > > They don't work. See https://gitlab.com/NTPsec/ntpsec/-/issues/729 > > > > There is a single line of code that disables them. > > > > They are less secure. But is that "less" practical or theoretical? > > > > They are deprecated in RFC 6125 > > https://datatracker.ietf.org/doc/html/rfc6125#section-7.2 > > > > Should we: > > remove or comment out that line of code > > add an option to the server line to allow wildcards > > reject the bug report > > ... > > I'd go with making it optional, not the default. > > > Anybody have any opinions? How strong? > > Not strong, but I see how some people woule need them. See https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/ section 3 which says: A technology MAY disallow the use of the wildcard character in DNS names. If it does so, then the specification MUST state that wildcard certificates as defined in this document are not supported. https://datatracker.ietf.org/doc/html/rfc8915 doesn't mention that wildcards are not supported. So we should allow wildcards once this errata is published (or now?), with the X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS flag. And this should be built-in, not optional. We don't need another config flag. Cheers, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: waf: --disable-attic
On Tue, Feb 15, 2022 at 01:16:26PM -0800, Hal Murray via devel wrote: > > I have a simple patch that will turn off building things in attic/ > > Should we make off be the default and change that to --enable-attic? Hi Hal, Are we worried about the speed of the build, lack of build support on particular platforms, or something else? Thanks, -Matt ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Using Go for NTPsec
On Tue, Jun 29, 2021 at 04:41:30PM -0400, Eric S. Raymond via devel wrote: > Well, first, the historical target for accuracy of WAN time service is > more than an order of magnitude higher than 1ms. The worst-case jitter > that could add would be barely above the measurement-noise floor at worst, > and more probably below it. Hi Eric, Our target is < 1 us, even for WAN time service. We would want to keep/improve this accuracy target. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: New email address
On Mon, Jun 14, 2021 at 11:27:06PM -0700, Hal Murray via devel wrote: > > I think I've updated the mailing lists, but hmur...@ntpsec.org forwards to my > old email and I can't figure out how to change that. > > My notes include: > https://devel.ntpsec.org/settings/panel/email/ > but that host doesn't exist any more. > > How should I change it these days? I can update this for you tonight. I'll let you know when it's complete. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fw: New Defects reported by Coverity Scan for ntpsec
On Mon, Jan 25, 2021 at 03:21:10PM -0800, James Browning via devel wrote: >Someone twisted a knob somewhere A new client for Coverity was released and it's more picky than the old client apparently. See https://scan.coverity.com/ "Coverity Upgrade to 2020.09" Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Missing build bots for tags, websites down.
On Mon, Dec 21, 2020 at 06:48:39PM +, Matthew Selsky via devel wrote: > www.ntpsec.org was moved back to GitLab pages and it should be working now. > docs.ntpsec.org is still pending some work by GitLab support. GL support fixed docs.ntpsec.org per https://gitlab.com/gitlab-com/gl-infra/production/-/issues/3214 Let me know if you find anything else that's not working properly. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Missing build bots for tags, websites down.
Hi James, >We currently do not have builders for the tags freebsd-11, freebsd-12, and >ubuntu-1604-lts. It would appear that in the late unpleasantness that the >builders detached. This should be fixable by having the >builders admin(s) reattach them in the settings. It should be possible to >migrate the cross builder to Docker. I will work on that shortly. The FreeBSD/cross-builder images are failing due to an unrelated snafu for our GCP VMs. Moving the cross-builder to Docker would be excellent! Can you also mark all 3 CI targets as allow-to-fail in order to allow everything else to proceed? We can revert that once the GCP issues are worked through. >Also, [1]docs.ntpsec.org and [2]www.ntpsec.org still seem to be down. It >is claimed to fixable from respective settings menus, by making them >public. www.ntpsec.org was moved back to GitLab pages and it should be working now. docs.ntpsec.org is still pending some work by GitLab support. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Runtime testing, What's the CI environment like?
On Sun, Sep 06, 2020 at 06:18:40PM -0500, Richard Laager via devel wrote: > On 9/6/20 5:43 PM, Hal Murray via devel wrote: > > Anybody using the modem driver? > > I tested in November, for fun, not any practical reason. NIST's service > is still up. The USNO service was dead. I emailed them and received no > response. USNO number in DC does not answer when I tried it just now. USNO number in CO does answer. The tycho.usno.navy.mil site is down and it seems to have been temporarily replaced by https://www.usno.navy.mil/USNO/time/telephone-time (there's a note that tycho may return in Fall 2020). Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Pre-release cleanup
I also previously setup Codacy in order to see what other SAST systems could do. See https://app.codacy.com/gl/NTPsec/ntpsec/dashboard Let me know what you think. If either are useful, I'll integrate them more tightly in our workflows. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Pre-release cleanup
On Wed, Sep 02, 2020 at 08:53:41AM -0400, Eric S. Raymond via devel wrote: > Sanjeev Gupta : > > They support *any* git repository. > > Huh. Their docs are out of date, then. I tried adding our GitLab repo today and I get an error message that new GitLab repos have been disabled by the site administrator. I previously added our GitHub mirror and it's visible via https://lgtm.com/projects/g/ntpsec/ntpsec/?mode=list But without the direct GitLab support, we don't get the benefit of recommendations during merge requests. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: BSD-4-Clause-UC license usage
On Thu, Apr 30, 2020 at 08:03:26PM +0800, Sanjeev Gupta wrote: >Hal, >I have sent in a MR, >https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1121 >for your review. Hi Sanjeev! I submitted https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1122 before I saw this. My MR also updates ntpd/ntp_dns.c Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
BSD-4-Clause-UC license usage
Hi Hal and team, Much our of NTS code uses BSD-4-Clause-UC instead of BSD-2-Clause (our preferred license for new code). What this license selection intentional? Is BSD-4-Clause-UC intended for code owned by the University of California, or does it make sense for others to use this license as well? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: CI stuff is broken: gentoo-hardened-basic
On Tue, Apr 21, 2020 at 04:57:04PM +, Robin H. Johnson via devel wrote: > Can you please log the IP of the host you used that did not have the > file? > > distfiles.gentoo.org is a bouncer with many mirrors Hi Robin, We call "emerge-webrsync" in our CI. Are you asking us to log the output of "dig distfiles.gentoo.org", or is there a debug flag for emerge-webrsync that you want us to enable for a bit? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Bye bye TLS 1.2
On Thu, Mar 26, 2020 at 12:57:33PM -0700, Hal Murray via devel wrote: > I just pushed the change. Can we bring back support of older OpenSSL releases for builds that don't need NTS support? OpenSSL 1.0.2 is supported via paid extended support per https://www.openssl.org/policies/releasestrat.html Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: waf help: OPENSSL_VERSION_NUMBER from openssl/opensslv.h
On Tue, Mar 24, 2020 at 12:40:42PM -0700, Hal Murray via devel wrote: > I'd like to check the OpenSSL version number and give a sensible error > message > rather than some mumbo jumble from the compiler. I would model the check that we removed in https://gitlab.com/NTPsec/ntpsec/-/commit/6d17955b03ca65d67f2cc2ceba01bd60e07d5fd4 Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Does cross compiling work?
On Mon, Jan 20, 2020 at 11:53:44AM -0800, Hal Murray via devel wrote: > If so, can somebody send me an example script. See https://gitlab.com/NTPsec/ntpsec/blob/master/.gitlab-ci.yml#L450 and https://gitlab.com/NTPsec/ntpsec/blob/master/INSTALL.adoc#user-content-cross-compiling Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python, testing
On Mon, Jan 13, 2020 at 05:06:01PM -0800, Hal Murray via devel wrote: > A year or 2 ago, I put together a script to test as many build time options > as > I thought reasonable. It's in ./tests/option-tester.sh > > Does anybody other than me use it? > > It's a bit of a CPU hog -- too much to run routinely. Can we set things up > to > run it on the gitlab OS collection weekly or manually when we get close to a > release? > > At the back end of each build step, it runs each of our python programs far > enough to print out their version string. That's far from a thorough test, > but a whole lot better than nothing. (Thanks to the people who put that in.) > > In particular, it does (should?) check loading the libraries. I think the > same code gets run post install. > > There is also a tests/python3-tester.sh that explicitly uses python3 > I added a clone for python2 a day or two ago. (but forgot to finish typing > this message) I'm not certain how these scripts are much different than our existing CI jobs... we already have CI jobs for both Python2 and Python3. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python, testing
On Mon, Jan 13, 2020 at 05:06:01PM -0800, Hal Murray via devel wrote: > How does waf tell the c compiler which Python.h to use? > My system has: > /usr/include/python2.7/Python.h > /usr/include/python3.7m/Python.h ./waf --python=/path/to/python OR /path/to/python waf > What can we do about testing things like ntpq? > > Is there a ntpd running on the gitlab build boxes? Is it worthwhile to just > run commands without checking the answers? (catch crashes but not much else) Most of the build boxes are containers. There's no persistence, or daemons that exist beyond the time that the build is running. What sort of testing would you like to do with ntpq, specifically? Test specific sub-commands? What would that test look like? Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's name for the gitlab thing that checks post-push and sends yes/no mail?
On Mon, Dec 09, 2019 at 11:35:05AM -0800, Hal Murray via devel wrote: > > I haven't seen that mail recently. Authors are emailed for failed pipelines See https://docs.gitlab.com/ee/ci/pipelines.html We also email specific users for failed pipelines. See https://gitlab.com/NTPsec/ntpsec/-/services/pipelines_email/edit Let me know if you need more information. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.8 build error
On Sun, Dec 01, 2019 at 10:45:28AM +0100, Udo van den Heuvel via devel wrote: > On 01-12-2019 10:14, Udo van den Heuvel via devel wrote: > > The macro _wrong_version_format_terminate_build can be used to work > > around this issue: > > Perhaps also in this way: > > rpmbuild -bb --define '_wrong_version_format_terminate_build 0' > SPECS/ntpsec.spec Udo, Do you have a local patch that updates SPEC/ntpsec.spec for the version information of each new release within the spec file? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntploggps not installed by waf
On Sat, Sep 21, 2019 at 01:09:30PM -0700, Paul Theodoropoulos via devel wrote: >On 9/21/2019 13:00 PM, James Browning wrote: > > On Sat, Sep 21, 2019, 12:55 PM Paul Theodoropoulos via devel > <[1]devel@ntpsec.org> wrote: > >Just a quick note, as I'm vetting all my installations - after running >'./waf configure --refclock=all', followed by './waf install', all of >the >applications in main/ntpclients are installed - except for ntploggps. > >I don't know the magic of waf sufficiently to point to why, where, or >how >it is overlooked... > > I think it is deliberately excluded if you do not have a recent gpsd > install detected. You do have a _recent_ gpsd installed I assume? > >Yep, 3.19 release. Hi Paul, Can you attach the full output from "./waf configure"? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
On Tue, Sep 17, 2019 at 09:39:15PM -0700, Hal Murray wrote:
> > Only thing left to revert is missing guards near "switch (rl_what) {"
> > near line 3630 in ntpd/ntp_config.h
>
> The whole point of this change was to get rid of ifdefs that weren't needed
> because the symbols they were checking are in POSIX. Are we running on any
> systems that don't have RLIMIT_NOFILE or RLIMIT_STACK?
I'm talking about this snippet that was removed:
<--->
switch (rl_what) {
-#ifdef RLIMIT_MEMLOCK
- case RLIMIT_MEMLOCK:
- /* ignore - for backward compatibility only */
- break;
-#endif /* RLIMIT_MEMLOCK */
<--->
>
> Is this one of those half-in-POSIX cases where they say this is how to do it,
> but it's optional?
I'm still talking about RLIMIT_MEMLOCK.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
On Tue, Sep 17, 2019 at 08:42:18PM -0700, Hal Murray wrote:
> > Can you partially revert ...
>
> I thought I had fixed it. Have you done a recent pull? Is the current code
> still broken?
Only thing left to revert is missing guards near "switch (rl_what) {" near line
3630 in ntpd/ntp_config.h
> Again, thanks for catching this.
You're welcome. Friendly nudge poke for using merge requests and peer review
pre-merging into master :-)
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cruft
On Sun, Sep 15, 2019 at 06:18:47PM -0700, Hal Murray via devel wrote: > > There are various #ifdefs testing RLIMIT_MEMLOCK and friends > > The Linux man page for setrlimit says: >getrlimit(), setrlimit(): POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD. > So I think we can assume it exists and remove the #ifdefs. > > Any reason not to? getrlimit()/setrlimit() are part of POSIX, but RLIMIT_MEMLOCK is not. This symbol is Linux/BSD-specific. Can you partially revert https://gitlab.com/NTPsec/ntpsec/commit/fb0c11c9db45709448383d1963b4cdf72a442f55#f4db43d91d9d4fe0fe143a20b21c2b3cd3a01a15_3635_3625 and https://gitlab.com/NTPsec/ntpsec/commit/36128757fbb6613fc4cea2705cc3717fbd7dc7fb? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'ntpq -c ":config"' does not work (it probably never did)
On Mon, Sep 09, 2019 at 08:46:26AM -0700, James Browning via devel wrote: >While working on a script, I stumbled across this issue. the cmd.Cmd >class does not call its precmd function from its onecmd function in >either Python 2.7 or 3.6. I see several possible paths forward. > >1. Ignore the issue and hope it goes away. >2. Report it upstream. >3. Change over to hot_config option exclusively. >4. Add a wrapper to onecmd that fixes things. >5. More extensive fixes to cmd.Cmd. >6. Change to a new command-line interpreter. >7. Another path I am not even considering. > >I would advocate for the wrapper or changing to hot_config as the least >not good options at this time. Ignoring it stacks up technical debt for >later. Upstream would probably say it works as intended. Changing to a >new interpreter would throw away all the good work on this one. More >extensive work is possible but probably beyond my capabilities. Yes, please talk to upstream and see what they recommend. And this change should be documented in our incompatible changes list until we have a compatible function (or we decide to leave the feature out) Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘Warnings on OSX
On Fri, Aug 30, 2019 at 08:01:59PM -0700, Fred Wright via devel wrote: > > On Thu, 29 Aug 2019, Gary E. Miller via devel wrote: > > > Warnings on OSX: > > > > [ 73/131] Compiling libntp/ntp_calendar.c > > ../../ntpd/ntp_control.c:2612:27: warning: format specifies type 'unsigned > > short' but the argument has type 'unsigned int' [-Wformat] > >socktoa(rmt_addr), (unsigned)SRCPORT(rmt_addr)); > > ^~~ > > 1 warning generated. > > > > > > [106/131] Compiling ntpd/ntp_dns.c > > ../../ntpd/refclock_gpsd.c:2118:6: warning: implicit declaration of > > function 'strlcpy' is invalid in C99 [-Wimplicit-function-declaration] > >strlcpy(pp->a_lastcode, tc, sizeof(pp->a_lastcode)); > >^ > > ../../ntpd/refclock_gpsd.c:2118:6: warning: this function declaration is > > not a prototype [-Wstrict-prototypes] > > 2 warnings generated. > > > > Anyone want to fix them? > > The second one, which was present on FreeBSD as well, seems to have been > caused by the definition of _XOPEN_SOURCE in refclock_gpsd.c. And in spite > of what the comment says, this definition does *not* seem to be needed to > get strptime(). So simply removing it gets rid of the warning, and doesn't > break anything AFAICT. https://linux.die.net/man/3/strptime says: "This function is available since libc 4.6.8. Linux libc4 and libc5 includes define the prototype unconditionally; glibc2 includes provide a prototype only when _XOPEN_SOURCE or _GNU_SOURCE are defined." Maybe that man page out of date? /usr/include/time.h on my Debian Stretch system (glibc 2.24) has: # ifdef __USE_XOPEN /* Parse S according to FORMAT and store binary time information in TP. The return value is a pointer to the first unparsed character in S. */ extern char *strptime (const char *__restrict __s, const char *__restrict __fmt, struct tm *__tp) __THROW; # endif _GNU_SOURCE implies _XOPEN_SOURCE... So we need _XOPEN_SOURCE set (or something that implies it) somewhere upstream to get this prototype on newer glibc versions. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: waf checking - fail on warnings?
On Mon, Aug 26, 2019 at 10:51:58PM -0700, Hal Murray via devel wrote: > > A relatively quick search suggests mandatory=True as an argument. > > That makes waf fail if the code chunk doesn't work. You want "mandatory=False" since this is a probe, not a requirement. And you want to pass "-Werror" (I'm not certain how off the top of my head) to the compiler so that warnings are fatal. waf sees the compiler exit zero with or without warnings, so they look the same. > I'm trying to make the code chunk not-work if it gets a warning, but then let > waf put a comment in config.h to indicate that a feature test didn't work > rather than put a #define to indicate that it did work. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: %m, #614
On Mon, Aug 26, 2019 at 04:55:48PM -0700, Gary E. Miller via devel wrote: > _GNU_SOURCE should not always be defined, but it does need to be defined > in certain cases. For example, on glibc < 2.10, you need to define > it to get strnlen() and struct ifreq. > > From glibc 2.10, you instead need _POSIX_C_SOURCE >= 200809L glibc 2.10 was released 2009-05-17. Do we still need to support it? Or can add a fatal waf error for glibc < 2.10 and then use the more modern symbols? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: gitlab testing broken for Fedora
On Sat, Aug 24, 2019 at 02:42:08AM -0700, Hal Murray via devel wrote: > Stage: build > Name: fedora-rawhide-refclocks-gpsd > Trace: GPG Keys are configured as: > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora- > 31-x86_64 > Public key for glibc-common-2.30.9000-1.fc32.x86_64.rpm is not installed. > Failing package is: glibc-common-2.30.9000-1.fc32.x86_64 > GPG Keys are configured as: > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_ > 64 > Public key for glibc-minimal-langpack-2.30.9000-1.fc32.x86_64.rpm is not > installed. Failing package is: glibc-minimal-langpack-2.30.9000-1.fc32.x86_64 > GPG Keys are configured as: > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-x86_ > 64 > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: GPG check FAILED > section_end:1566637579:build_script > [0Ksection_start:1566637579:after_script > [0Ksection_end:1566637580:after_script > [0Ksection_start:1566637580:upload_artifacts_on_failure > [0Ksection_end:1566637582:upload_artifacts_on_failure > [0K[31;1mERROR: Job failed: exit code 1 > [0;m Likely related to https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/TNH7RJCWIILV5VYT3N3IA3VZQIOFNZ53/ Fedora seems to have fixed their repos and our Rawhide builds are succeeding again. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Point release of NTPSec
On Fri, Aug 23, 2019 at 02:12:21PM -0400, Eric S. Raymond via devel wrote: > Sanjeev Gupta : > > We need a point release. Significant things that have happened recently: > > > > > >- The g and G suffixes > >- Removal of neoclock4x > >- Some doc changes > >- The ALPN change > > > > The last is critical, it throws into doubt all the interop we have with > > other NTS implementations. We need a tag to describe our implementation, > > so that we can test again. > > > > Please note only the first point above is captured in the NEWS file. > > I just added notes about the neoclock removal and the ALPN change. > > I concur that a oint release is indicated. Does it make sense to call this 1.2.0 instead of 1.1.7? Especially since we have the ALPN compatiblity fix? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘NTS and ALPN
On Mon, Aug 19, 2019 at 06:33:52PM -0700, Gary E. Miller via devel wrote: > For some reason GitLab has not allowed me to merge from their web pages > for a few weeks. I have to merge manually... Hi Gary, Sounds like you ran into https://gitlab.com/gitlab-org/gitlab-ee/issues/12686 I'm not sure why Dan's fork of the repo doesn't have jobs enabled... Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Fri, Aug 02, 2019 at 06:31:34AM +0200, Udo van den Heuvel wrote: > Builds successfully after adapting the directories in the %files section. Excellent! > URL: http://www.ntpsec.org > Requires(post): systemd-units > Requires(preun): systemd-units > Requires(postun): systemd-units > BuildRequires: systemd-units > BuildRequires: bison gcc openssl-devel > BuildRequires:libcap-devel libseccomp-devel > BuildRequires: pps-tools-devel > BuildRequires: avahi-compat-libdns_sd-devel > BuildRequires: libcap openssl-libs pps-tools > BuildRequires: python-devel libxslt asciidoc m4 > BuildRequires: python-psutil asciidoc docbook-style-xsl wget > BuildRequires: /usr/bin/pathfix.py > BuildRequires: python3-devel python3-psutil You can likely remove python-devel and python-devel. Are your RPM packages published anywhere? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 07:19:02PM +0200, Udo van den Heuvel wrote:
> On 01-08-19 19:00, Matthew Selsky wrote:
> > You may need to specifically use %{__python3} when you call "waf" in the 2
> > places in the %build section.
>
> So maybe not use --python=%{__python3} for waf?
"--python" should not need to be passed to waf.
> Without this the rpm builds OK.
Please change these:
CFLAGS="-O2" ./waf configure \
CFLAGS="-O2" ./waf build
DESTDIR=$RPM_BUILD_ROOT ./waf install
To:
%{__python3} ./waf configure \
%{__python3} ./waf build
DESTDIR=$RPM_BUILD_ROOT %{__python3} ./waf install
Let's see if that helps. waf sets a reasonable CFLAGS already.
Is there a git repo for your spec file work?
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 05:02:58PM +0200, Udo van den Heuvel wrote:
> On 01-08-19 16:39, Udo van den Heuvel via devel wrote:
> > The 1.1.6 code does not.
>
> The workaround now works when I use the pathfix.py line with this
> addition: %{buildroot}%{_sbindir}/*
>
> The whole SPEC then looks like the stuff below.
Awesome.
Can you change the BuildRequires to "python3-devel" and "python3-psutil"?
>
> How can we explain the existing shebangs?
And can you change the pathfix line to:
--snip--
pathfix.py -pni "%{__python3} %{py3_shbang_opts}" .
--snip--
And move it to the %prep section instead of the %install section.
You may need to specifically use %{__python3} when you call "waf" in the 2
places in the %build section.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 04:31:52PM +0200, Udo van den Heuvel wrote: > On 01-08-19 16:27, Matthew Selsky wrote: > > On Thu, Aug 01, 2019 at 04:18:30PM +0200, Udo van den Heuvel wrote: > > > > See > > https://gitlab.com/NTPsec/ntpsec/commit/3ee8e4c3c3cf4b2d6f010874e7f447a23a1710cf > > for the change that we made to our CI targets. > > Sure, but why then is there a complaint from the Redhat Fedora tool(s)? I don't think the Fedora tools use anything related to our CI targets so our change should have neither helped, not harmed. > > The debian package replaces the shebangs. You can see how at > > https://sources.debian.org/patches/ntpsec/1.1.3+dfsg1-2/hardcode-python3-path.patch/ > > > > You likely want to use the RPM macro that does the equivalent. I'm not > > familiar enough with RPM packaging to give more specific advice. > > > We have a tool OK, cool. I'd be happy to review what you come up with if you want. And if you have suggestions for improving packaging/packaging.adoc, I'd be happy to hear them. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 04:18:30PM +0200, Udo van den Heuvel wrote: > The build shows otherwise, else there would not be an error. > Or did I miss a step in the build process? See https://gitlab.com/NTPsec/ntpsec/commit/3ee8e4c3c3cf4b2d6f010874e7f447a23a1710cf for the change that we made to our CI targets. > Because the shebangs are not explicit the build fails. > At least that is what I understand from the errors. The debian package replaces the shebangs. You can see how at https://sources.debian.org/patches/ntpsec/1.1.3+dfsg1-2/hardcode-python3-path.patch/ You likely want to use the RPM macro that does the equivalent. I'm not familiar enough with RPM packaging to give more specific advice. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 03:32:40PM +0200, Udo van den Heuvel via devel wrote:
> On 01-08-19 15:24, Udo van den Heuvel via devel wrote:
> > The script will exit with nonzero exit code, rendering the build failed.
>
> When trying to work around this in my spec file, I use:
> pathfix.py -pni "%{__python2} %{py2_shbang_opts}"
> %{buildroot}%{python2_sitearch} %{buildroot}%{_bindir}/*
[..]
> QUESTION:
>
>
> Can someone please fix the /usr/sbin/ntpdig error? it makes the
> workround fail...
Our code works on both Python2 and Python3. Given F30's recent changes, we
switched our CI targets to explicitly point at python3.
If you're going to mangle the shebang as a package maintainer, feel free to
change all of the shebangs to explicit python3 on Fedora.
We're going to leave the shebangs alone in the source for maximum compatibility
with upstream PEP recommendations. See also packaging/packaging.adoc in the
repo.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On Thu, Mar 28, 2019 at 04:38:44PM -0700, Gary E. Miller via devel wrote: > Potential extra security is just an added feature that you get for free > once you add certificate pinning to handle the ostfalia case. > > Check the pin, but do not check the chain: > > server ostfalie.de noval pin XXX > > Check the pin, and check the chain: > > server rellim.com pin YY > > Now if someone can trick a CA into giving them a valid rellim.com cert > the connection will still be secure. Do you have an example of software the implements pinning as BOTH a central trust store + a specific pin? postfix allows the user to specific a trust-anchor file per destination. So a typical postfix tls policy table (when you need specific TLS policy rules) might have: foo.com secure tafile=/etc/ssl/certs/QuoVadis_Root_CA_2_G3.pem bar.com secure So foo.com is required to match a specific commercial CA and bar.com is allowed to match any CA in the system trust store. See http://www.postfix.org/postconf.5.html#smtp_tls_trust_anchor_file Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On Thu, Mar 28, 2019 at 04:06:05PM -0700, Gary E. Miller via devel wrote: > > I think public key (as opposed to certificate) pinning is the common > > approach these days. The application simply requires that one of the > > public keys in the chain match the pinned public key. The user can > > decide if they want to pin the server public key, the intermediate CA, > > or the root CA. > > Tell that to Matt Selsky. He changed the ntpsec.org pinning to > be that if the signing cert. Updating the pins every 90 days > was a PITA. In the LE cert via GitLab Pages case, yes, cert pinning to the leaf was too much trouble, so I created TLSA records for the LE root certificate. But I can see a case where longer lifetimes are used, or the certs are self-signed, then having the flexibility to match anything in the chain would be quite useful as Richard was describing. > > That said, we need to think carefully about the intended interactions > > between pinning and validation (or lack thereof with noval). > > Not need to think about it. Lot's of prior art. Just use that. > The DANE is well thought out. So we want to support the equivalent of DANE's 311 and 211 modes? > > I think that you in particular are using pinning to avoid adding the > > server operator's private root certificate that you don't trust. > > Today, yes. And no way I'll ever add a provate root cert I don't > have enourmous trust in. You probably wouldn't add a private root cert to your system trust store, but you might allow it for a specific NTS server entry. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: CI: debian-oldoldstable
On Mon, Mar 25, 2019 at 04:00:23AM -0700, Hal Murray via devel wrote: > > I thought it had been removed. [...] > Stage: build > Name: debian-oldoldstable-basic > Trace: Err http://deb.debian.org oldoldstable-updates/main amd64 Packages > 404 Not Found [IP: 151.101.248.204 80] > W: Failed to fetch > http://deb.debian.org/debian/dists/oldoldstable/main/binary- > amd64/Packages 404 Not Found [IP: 151.101.248.204 80] I submitted an MR to remove it (https://gitlab.com/NTPsec/ntpsec/merge_requests/986) but that MR was failing CI because openSUSE was having issues with their repo mirroring system (https://status.opensuse.org/incidents/184) The openSUSE infrax recovered sufficiently Monday morning (EDT) to allow the Debian "oldoldstable" MR to proceed. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS update
On Fri, Mar 22, 2019 at 06:32:10PM -0700, Gary E. Miller via devel wrote: > I think this is what you want: Perfect. > I tried to modify the wscript to do that, but failed... In ntpd/wscript, try replacing this: use="libntpd_obj ntp M parse RT CAP SECCOMP PTHREAD NTPD " "SSL CRYPTO DNS_SD %s SOCKET NSL SCF" % use_refclock, With: use="M SSL CRYPTO DNS_SD parse RT CAP SECCOMP PTHREAD NTPD " "%s SOCKET NSL SCF libntpd_obj ntp" % use_refclock, And see how that goes. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS update
On Fri, Mar 22, 2019 at 04:52:33PM -0700, Gary E. Miller via devel wrote: > Yo Hal! > > New issue. I have a really old server that has been running NTPsec > git head until recently. Now it fails, the openssl is too old. > > # openssl version > OpenSSL 1.0.2o 27 Mar 2018 > > I know I can update the openssl, but many people will not be able to... > > How do I disable building with openssl? > > The problem starts here: > > [137/137] Linking build/main/ntptime/ntptime > /usr/local/ssl/lib/libssl.a(t1_lib.o): In function `tls1_check_chain': > t1_lib.c:(.text+0x6e96): undefined reference to `X509_certificate_type' > /usr/local/ssl/lib/libssl.a(t1_lib.o): In function `SSL_check_chain': > t1_lib.c:(.text+0x7ba3): undefined reference to `X509_certificate_type' > /usr/local/ssl/lib/libssl.a(t1_enc.o): In function `tls1_change_cipher_state': > t1_enc.c:(.text+0x715): undefined reference to `COMP_CTX_free' > t1_enc.c:(.text+0x735): undefined reference to `COMP_CTX_new' > t1_enc.c:(.text+0xac4): undefined reference to `COMP_CTX_free' > t1_enc.c:(.text+0xae0): undefined reference to `COMP_CTX_new' Gary, This sounds like: https://ubuntuforums.org/archive/index.php/t-985136.html "The solution is simple, for some reason, when linking the library, -lssl must be in front of -lcrypto." Can you run "./waf build -v" to confirm the order of the linker arguments? And then swap them to confirm the fix? I'd be happy to rejigger the wscript files once you confirm the fix itself. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Coverity scan builds are busted for me
On Tue, Mar 19, 2019 at 06:42:48PM -0400, Eric S. Raymond wrote: > I'm confused. That YAML isn't Docker description? What interprets it? No, it's not Docker description. See https://docs.gitlab.com/ee/ci/yaml/ for the documentation. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Coverity scan builds are busted for me
On Tue, Mar 19, 2019 at 03:08:48PM -0400, Eric S. Raymond wrote: > Matthew Selsky : > > On Mon, Mar 18, 2019 at 08:13:27PM -0400, Eric S. Raymond via devel wrote: > > > Coverity scan builds are busted for me. Log enclosed. Are the ones > > > triggered by the CI system working? > > > > Yes, the CI triggered coverity builds are working. See > > https://secure-web.cisco.com/1vwrdWkJJ8wOhfp3pdW20_KLCAJj-iCT892_7bjgZyb_1HOyqd4IOUoYSdMt4YeTbyiBk4s2uiJi0RyaefzpvxN5gCgUEyOeY_B4lBZ9KRH7imo2NMA8ivRi_QOpl_7uKFiLTINpHgGWKMVPGh4iaPAhedFcsMmT_aKprder7so4WmUi4ldCBD-rakbT8ZZ_QFuKgexqbrSwhoV5C1B3atW0EtmWCS30NWL2PwpNAsj1wavBi0o8wj83s7pO4Lo3Z15B54zl3GYOju-JucV0KQA/https%3A%2F%2Fgitlab.com%2FNTPsec%2Fntpsec%2Fpipelines%2F52498442 > > Arrgh. Now I need to figure out how the CI enviroment is different from > coverity-submit's. Is the CI enviroment described by a Docker file? > If so, where is it? No, the CI environment for Coverity runs on one of our VMs. The commands are documented at https://gitlab.com/NTPsec/ntpsec/blob/master/.gitlab-ci.yml#L579 If you can find a docker image that has coverity, I would be happy to switch over to that. I wasn't able to find one that last time I checked docker hub. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Coverity scan builds are busted for me
On Mon, Mar 18, 2019 at 08:13:27PM -0400, Eric S. Raymond via devel wrote: > Coverity scan builds are busted for me. Log enclosed. Are the ones > triggered by the CI system working? Yes, the CI triggered coverity builds are working. See https://gitlab.com/NTPsec/ntpsec/pipelines/52498442 Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: REFCLOCK rises again
On Tue, Mar 05, 2019 at 12:46:29PM -0600, Richard Laager via devel wrote: > On 3/5/19 12:45 PM, Gary E. Miller via devel wrote: > > Yo Eric! > > > > On Tue, 5 Mar 2019 02:11:52 -0500 > > "Eric S. Raymond via devel" wrote: > > > >>> That would leave the configure option. I've never used it. > >> > >> I think we can justify both removals on security. If Mode 6 is a > >> read-only channel there can never be any exploits over it. That's > >> a significant gain in provable bulletproofness. > >> > >> You want to reconfure your ntpd? Bounce it. This won't happen often. > > > > Ugh, wrong. I've got to agree with Achim here. It takes days for > > my ntpd's to converge, that is why you don't bounce it often. > > How often are you reconfiguring your running ntpd today, and by what > mechanism (i.e. are you using the Mode 6 writable parameter(s) being > proposed for removal)? I reconfigure ntpd periodically. I push a new ntp.conf via my configuration management system and then restart ntpd. My reconvergence takes ~10 minutes for stratum-1 clocks since my maxpoll is 2 seconds. Saving more state so that the reconvergence is faster would be great, but the current performance is sufficient. Reconfiguring via ntpq is not something I would ever use at scale. This mostly seems useful for tinkering/debugging. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's left to doo on NTS
On Mon, Mar 04, 2019 at 12:11:07PM -0800, Gary E. Miller via devel wrote: > Given the Comodo mess of last week I expect a lot more people will want to > do pinning next month. Do you have a reference for this mess? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Blizzard of errors from tests/ntpd/nts on 32 bit systems
On Fri, Feb 22, 2019 at 01:51:28AM -0800, Hal Murray via devel wrote: > > My bad - warnings, not errors. > > It works. (on 32 bit systems) I've filed https://gitlab.com/NTPsec/ntpsec/issues/561 to track this. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: no ssl.h on macos?
On Sat, Feb 09, 2019 at 05:28:16AM -0800, Hal Murray via devel wrote: > I thought we got farther than this last night. > > Does macos have OpenSSL? What version? > > Stage: build > Name: macos-basic > Trace: ../../include/nts.h:7:10: fatal error: 'openssl/ssl.h' file not found > #include > ^~~ > 1 error generated. https://gitlab.com/NTPsec/ntpsec/-/jobs/158846691 makes the error a bit more clear: [2/2] Compiling build/host/ntpd/ntp_parser.tab.c In file included from /Users/gitlab-runner/builds/FrHjVgVw/0/NTPsec/ntpsec/ntpd/ntp_parser.y:16: In file included from ../../include/ntp.h:17: ../../include/nts.h:7:10: fatal error: 'openssl/ssl.h' file not found #include ^~~ 1 error generated. The parser generator includes ntp.h. ntp.h was recently changed to include nts.h. And nts.h needs openssl/ssl.h So we either need to add "SSL" to the "use" flag for the parser builder (not that the parser actually needs OpenSSL), or we change the chaining of the include files so that the parser doesn't have a transitive dependency on openssl/ssl.h My intuition is that the latter is the correct long-term answer, but I'm not sure how to appropriately re-arrange the header inclusions. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Update
On Sun, Feb 10, 2019 at 05:30:36PM -0800, Hal Murray wrote: > > If it's easy for waf, it would be nice to document the version of OpenSSL we > are using to build. The version that we built against, or the version that we're currently dynamically linked with? Eg, we might build with 1.0.2n, but then run with 1.0.2r. Which do you want to report, and where? In ntpd --version output? Or were you thinking of somewhere else? Or did you just want "waf configure" to report the version of openssl that it found? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: no ssl.h on macos?
On Sun, Feb 10, 2019 at 05:02:48PM -0800, Fred Wright via devel wrote: > > On Sat, 9 Feb 2019, Hal Murray via devel wrote: > > > I thought we got farther than this last night. > > > > Does macos have OpenSSL? What version? > > > > Stage: build > > Name: macos-basic > > Trace: ../../include/nts.h:7:10: fatal error: 'openssl/ssl.h' file not found > > #include > > ^~~ > > 1 error generated. > > You can always install it via MacPorts if needed. From my (10.9) system: > > MacPro:~ fw$ for o in $(which -a openssl); do echo -n "$o: "; $o version; done > /opt/local/bin/openssl: OpenSSL 1.0.2q 20 Nov 2018 > /usr/bin/openssl: OpenSSL 0.9.8zg 14 July 2015 Our Gitlab CI targets for macOS use the OpenSSL from Homebrew. MacPorts would also work. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Update
On Sat, Feb 09, 2019 at 02:19:50PM -0800, Hal Murray via devel wrote: > > e...@thyrsus.com said: > >> Are we ever going to want to use anything older than TLS1.2? Spec says > >> no, > >> but it might be interesting for testing. > > I'm not interested in complicating our lives with a surfeit of obsolete > > APIs. > > Sounds good. It's probably worth updating our requirements section to > include > a version of OpenSSL new enough to support TLS1.2 > > We should be able to add that check to waf. I looked into it a bit, but it > was going to take too long. > > We can get the version info either of two ways. > > Their command line tool is openssl. > $ openssl version > OpenSSL 1.1.1a FIPS 20 Nov 2018 > $ > It's not part of the -dev package and otherwise not (yet) necessary to build. > > We might end up using it for some testing, but I can't think of a good > example. > > OPENSSL_VERSION_NUMBER is defined in openssl/opensslv.h which gets pulled in > by openssl/ssl.h > It looks like: > # define OPENSSL_VERSION_NUMBER 0x1010101fL > There is also a text version: > # define OPENSSL_VERSION_TEXT"OpenSSL 1.1.1a FIPS 20 Nov 2018" > > I don't know what version we need, but I'm pretty sure I can track it down. > Their man pages are good about having a HISTORY section describing when a > feature was added. Per https://en.wikipedia.org/wiki/OpenSSL, OpenSSL added support for tls1.2 in version 1.0.1. And that version was end of support in December 2016. So any version of OpenSSL that we encounter on a supported operating system will have a "new enough" OpenSSL to support tls1.2. We can add a check for TLS1_2_VERSION (from openssl/tls1.h), if we want to be explicit about support for the feature. We definitely don't want to check for the version since features could be backported. Eric, shall I add that? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: macos help please
On Thu, Feb 07, 2019 at 05:28:33AM -0800, Hal Murray via devel wrote: > > I pushed the start of NTS-KE-client code, partly in order to find things like > this. > > > Job #157857979 ( > https://secure-web.cisco.com/16UbTIDf3-JpOVrQQQf2Lji3hOcnSngcm8aSRfJb9Y7vqNRqMTOrDAM-dEeUuENnnKgsbBlt5T1kxk0tJuU8h_W8-d2fZSmTlM2hoD3x_u1kHHBA7Q7TaQGtlR9KM5u0qGlIVLqSHmPl5sbG9-ILahM1cUTDX3UPj7ae9KmVqic5zdrjGSM6HmMWnm61LcXEdqKRLd26rIBrF0FbmV-2n2U5J6ItN3NW4LvWoRK4RvgAYdncb93uZx4RWHOzsxz5GvrE6Z4zLIWxVM8G5n2ieGg/https%3A%2F%2Fgitlab.com%2FNTPsec%2Fntpsec%2F-%2Fjobs%2F157857979 > ) > > Stage: build > Name: macos-basic > Trace: "_res_9_init", referenced from: > _open_TCP_socket in nts_client.c.1.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > Looks like it needs another library. Yes, or we just skip the res_init() like we do in libntp/ntp_dns.c I submitted https://gitlab.com/NTPsec/ntpsec/merge_requests/936 to fix this. macOS does have res_init(), but our detection of it doesn't work. The impact is that we don't re-initialize the resolver functions. That's probably OK. We really only need this on network changes that would have updated resolv.conf > Has anybody tried tests/option-tester.sh on macos? I haven't, but that wouldn't have helped here. The CI system caught it in the first commit (yours) that broke it. I think this worked out the way that we intended. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Amusing implications
On Mon, Feb 04, 2019 at 05:34:56PM -0800, Hal Murray wrote: > > Now, if it doesn't meet our accuracy thresholds, that's another story. > > Do we have any accuracy standards? See https://www.ntpsec.org/drivers.html INACCURATE Remove GPS drivers and time radios for which the hardware offers no better source accuracy than a timing GPS available for less than $75 in 2015; that is, about 5µs. (However, do not necessarily remove poorer-performing GPS-conditioned clocks, as they continue to supply time in holdover mode when the GPS cannot get satellite lock.) Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Amusing implications
On Mon, Feb 04, 2019 at 01:39:48PM -0500, Eric S. Raymond via devel wrote:
> I found a documentation error.
>
> The page for the modem driver says:
>
> This driver requires a 9600 bps modem with a Hayes-compatible command
> set and control over the modem data terminal ready (DTR) control line.
> The actual line speed ranges from 1200 bps with USNO to 14,400 bps
> with NIST. The modem setup string is hard-coded in the driver and may
> require changes for nonstandard modems or special circumstances. It
> can be overridden by setting the extended system variable
> "modem_setup" via ntpq.
>
> But look at this:
>
> setup = get_ext_sys_var("modemsetup");
> if (setup != NULL)
> modem_setup = estrdup(setup);
>
> Yes, that's right, the embedded underscaore in "modem_setup" is wrong.
> And we didn't do that - I checked Classic and the documentation bug
> dates back at least to 2012. Probably earlier, I can't be bothered
> to do a full bisect on this.
No, we added that incorrect documentation in 2016. See
https://gitlab.com/NTPsec/ntpsec/commit/d88b9dc4d1629885ec6500ff295110e8a512e025
> The system variable you might poke to make it work is misdocumented.
> And the misdocumentation has lingered for at least 7 years. That's
> long enough for a human to be declared legally dead.
We misdocumented it. 2 years ago.
> I'll fix it, but I think what we *ought* to do is nuke the whole sorry mess.
> Any objections?
Someone asked about it on the ntp questions list. See
http://lists.ntp.org/pipermail/questions/2017-July/041261.html So there seems
to be some usage of it, by real users.
Per
https://www.nist.gov/pml/time-and-frequency-division/services/automated-computer-time-service-acts,
ACTS in Colorado received 2,000 calls per day, and ACTS in Hawaii receives 100
calls per day. The page was last updated in April 2018, but the statistics
might be older.
Regarding commercial usage, the Symmetricom S300 contains a built-in modem for
connection to ACTS, PTB, etc, per
https://www.microsemi.com/document-portal/doc_view/135082-syncserver-s300-high-performance-enhanced-security-gps-network-time-server
eBays shows quite a few for sale per
https://www.ebay.com/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=SyncServer+s300&_sacat=0
So calling it dead might be premature. Now, if it doesn't meet our accuracy
thresholds, that's another story.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'AnsiTerm' object has no attribute 'buffer'
On Tue, Jan 29, 2019 at 07:18:20PM -0800, Gary E. Miller via devel wrote: > Yo Fred! > > On Tue, 29 Jan 2019 19:01:40 -0800 (PST) > Fred Wright via devel wrote: > > > > Well, the way we use sys.stdout is warned about in the Python doc. > > > That is enough for me to want it aligned with the python doc. > > > > The real question is why the build procedure thinks it needs to > > output 'bytes' to the terminal, > > Easy, to fix make the code work with Python2 and Python 3. > > See here: > > https://secure-web.cisco.com/1zPMHyXmnA2gt7hRrEsrSfZlzlA9KP9LRUJ4l78jZyR9GyKASS4D4Dl-imylIypoW9cc27We390WVl4SPRE3J_6Z2Jsb7lGG4CG4ZpjxYVazLDCnE0eGyB3V1F4w6Mlgh40QjP2R5ujoYRdjSoZ-PQRZqpcZKZdTGaX55WaccmEL4SzVxaN2r4W5E3TAmtnTcAbk3xFihp1z6LKJgjgNlTy0wyKvKzfIcRJyFmR9rpyuO4BZ9X8R3GL01Vxn2CI6rOb6Wqmbq5UCmL5WAOELjzA/https%3A%2F%2Fgitlab.com%2Fesr%2Fpractical-python-porting%2Fblob%2Fmaster%2Fpolystr-inclusion.py > http://www.catb.org/esr/faqs/practical-python-porting/ > > Weird, but no one has done better. > > > It can probably be worked around by prefixing the build command with > > "NOSYNC=1", which disables waf's AnsiTerm hackery. > > That worked. Thanks! Is this a waf bug, or a 'Practical Python Porting' bug? Btw, I tried to reproduce this failure with 3.5.6, 3.6.7, and 3.7.1, without success. Do you have any tips for reproducing? Input/output redirection? Environment variables? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Should we get a waf?
On Sun, Jan 27, 2019 at 06:44:59AM -0500, Eric S. Raymond via devel wrote: > Hal Murray via devel : > > It's up to version 2.0.14, Dev 2018, about a year since the version we are > > using. We're using a version from 6 months ago (https://gitlab.com/ita1024/waf-old/commits/waf-1.9) > At some point we'll have to, but there's a glitch in the way. Our present > waf build does something magic that doesn't work past 1.9 - I've fogotten > the details. waf 2.x dropped support for 'type_name' and 'field_name' as arguments to check_cc(). So we'll need to work-around that and any other incompatibilities. I'll work on this. @Hal, Are there any features in waf 2.x that you were looking forward to? Or do you just want us to avoid getting too far behind? Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Various cleanups: threads, STA_NANO
On Wed, Jan 23, 2019 at 01:36:33AM -0800, Hal Murray wrote: > > e...@thyrsus.com said: > > In particular, some of our targets (some BSDs, I don't remember which) have > > only microsecond, not nanosecond resolution in the clock-adjustment calls. > > NetBSD and FreeBSD have NANO. > > Matthew Selsky suggested Solaris. Can anybody confirm that? > Anybody know of others? I think we covered this in https://gitlab.com/NTPsec/ntpsec/issues/421 ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Various cleanups: threads, STA_NANO
On Wed, Jan 23, 2019 at 12:43:53AM -0500, Eric S. Raymond wrote: > That's because our actual support target is this: > > This software should build on any operating system conformant to > POSIX.1-2001 and ISO/IEC 9899:1999 (C99). In addition, the operating > system must have an ntp_adjtime(2) call. Also, it must support the > IPv6 API defined in RFC 2493 and RFC 2553. Finally, it must support > iterating over active UDP interfaces via getifaddrs(3) or some > equivalent facility. > > There is some point in listing known-good platforms (Linux is the > biggie), but no point in trying to be exhaustive about it, because > anybody with enough chops to build this on a Unix variant we don't > know about is necessarily clued in enough to apply this creterion > themselves. Agreed. Can we update https://www.ntpsec.org/supported-platforms.html to be less specific to avoid having yet another table that we need to update? We can list distros, since that won't change much. > Maybe we want to replace that with "we support the current (and current - 1) > versions of the following platforms/distros as long as they're supported by > upstream"? Or replace this section with a link to docs.ntpsec.org and the CI > system? If you're OK with some variation of this, I'll submit an MR. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 'AnsiTerm' object has no attribute 'buffer'
On Wed, Jan 23, 2019 at 12:23:26PM -0800, James Browning via devel wrote: >I think I remember seeing that. IIRC I was piping something somewhere. >That was back before pylib/poly.py though. Per https://docs.python.org/2/library/io.html#io.TextIOBase: buffer The underlying binary buffer (a BufferedIOBase instance) that TextIOBase deals with. This is not part of the TextIOBase API and may not exist on some implementations. Sounds like we need to add a hasattr() check for buffer before we mess with it. Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Various cleanups: threads, STA_NANO
On Tue, Jan 22, 2019 at 07:37:18PM -0800, Hal Murray via devel wrote: > > We have various cruft associated with threads. Can we add POSIX threads to > our list of requirements? Or is it already included in POSIX.1-2001 and > ISO/IEC 9899:1999 (C99)? POSIX threads are optional for POSIX.1-2001 per http://pubs.opengroup.org/onlinepubs/009695399/help/codes.html#THR We currently require any POSIX-style library. Either pthread or libthr. > The idea is to remove HAVE_PTHREAD_H and HAVE_PTHREAD from config.h and > remove > most of wafhelpers/check_pthread.py > > wafhelpers/check_pthread.py says: > ctx.check_cc(lib="thr", mandatory=False, > comment="thr library, required by some operating systems.") > Is that (still?) correct? If so, which systems? libthr is a FreeBSD thing. See https://www.freebsd.org/cgi/man.cgi?query=libthr=0=0=FreeBSD+12.0-RELEASE=default=html The check was added in April 2016 per db86d9f65b1055f49219dda7fe36e9229cfba532 https://gitlab.com/NTPsec/ntpsec/-/jobs/149004468 shows: Checking for library thr : yes You can examine the artifact at https://gitlab.com/NTPsec/ntpsec/-/jobs/149004468/artifacts/browse/build/main/ntpd/ to see if the binary has libthr.so as a runtime dependency. I haven't tested if it's possible to have a FreeBSD build with libthr, but without pthreads. Or the other way around. Our FreeBSD CI images are using the stock install. The C code has no #ifdefs for HAVE_PTHREAD or HAVE_PTHREAD_H, so we're only talking about cleaning up some waf python code, correct? > There is probably cruft in this area that I added to try to avoid libpthread > for the no-DNS case. That doesn't work now since libcrypto needs > pthread_once > and is less likely to work as we get NTS-KE working. > > -- > > We have various ifdefs for STA_NANO. We depend on clock_gettime which uses > timespec so all the systems we run on know about nanoseconds. Can we upgrade > our requirement for ntp_adjtime to be requires ntp_adjtime with STA_NANO? We added the STA_NANO checks to support systems that have some STA_ symbols, but not all. See https://lists.ntpsec.org/pipermail/vc/2017-December/003604.html We'd have to survey the platforms that we care about to see if they have these symbols now. https://docs.ntpsec.org/latest/#platforms doesn't give many specifics on what platforms we support. https://www.ntpsec.org/supported-platforms.html mentions specific (older) versions of distros and architectures. Maybe we want to replace that with "we support the current (and current - 1) versions of the following platforms/distros as long as they're supported by upstream"? Or replace this section with a link to docs.ntpsec.org and the CI system? Cheers, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: lockclock
Is it possible to make lockclock a run-time-only option, instead of a compile-time + runtime otion? If remains a compile-time option, then we'll need to add CI targets for it so that we're always testing that it compiles cleanly. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Out of date chunks in documentation
On Mon, Dec 24, 2018 at 11:14:47AM -0800, Hal Murray wrote: > > > That still makes this table a maintainence headache. Can we instead say > > that > > we built on modern/supported-by-upstream releases of popular operating > > systems and distributions. And we build test on the platforms supported by > > our CI system. See > > https://secure-web.cisco.com/1N2ohoYQV9HB6Eik5aubGlGNBSC-OoyV9dFeOMGXNbouVPsjDL_gYDAvD2A1DWIYGzIgBVNCG3K2UWTaZmjmkW7qvcZ8oxyMr7NhG218JCcGfJcrgtoDdPU69aVmeH6_4Pg8zTi_HQaPK8kM-Uueo05fQvxZaxsOVjelvonabSO7YPOETlk0M37Oyq7ybOaFjA_LcD0ktQf97cRU-i9UFtBwsTkcjDR--Z-tFNwtFmBkKENzYY3wqfQ6HWZlP5Ghbe41U_3viSKMLb1DiNARJ8A/https%3A%2F%2Fgitlab.com%2FNTPsec%2Fntpsec%2Fblob%2Fmaster%2F > > .gitlab-ci.yml for the specific platforms that we test on. > > Two issues: > > That only tests building. We also need to test actually running, and test > refclocks. Or at least document how much testing we actually do. Is there a way that we can fix refclock testing into CI? If you can describe how we'd run that test (don't worry about the platform details), I can work on a way to integrate it into our pipelines. Same question for running testing running without refclocks. > .gitlab-ci.yml isn't exactly user friendly. Yes, it is the truth if you want > to know obscure details, but I have troubles reading it. Where is the > documentation for that area? Where is the list of systems I get to pick from? https://www.ntpsec.org/supported-platforms.html says "NTPsec builds cleanly on at least..." There are some references to testing, but they're non-specific. See https://docs.gitlab.com/ee/ci/yaml/ for documentation on the YAML syntax. The job names try to be self-evident about what platform/version/feature they're testing. If I've missed the mark on any, please let me know. We may want to point the users at https://gitlab.com/NTPsec/ntpsec/pipelines so they can click "Stages" and see the line of jobs from the drop-down? > Are there any other places where we have the problem of our documentation > representing a snapshot in time? Sure. For example: https://www.ntpsec.org/plans.html https://www.ntpsec.org/removal-plan.html https://www.ntpsec.org/accomplishments.html Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Out of date chunks in documentation
On Mon, Dec 24, 2018 at 09:48:53AM -0500, Eric S. Raymond via devel wrote: > Hal Murray via devel : > > > > We need a mechanism to review/update things occasionally and a list of > > things > > that need occasional review. > > > > Here is a starter: > > https://www.ntpsec.org/supported-platforms.html > > Under test status, it says: > > Fedora 26 and 25 (i686, x86_64) > > and lots more. > > > > We could fix most of that by replacing specific version numbers by > > something > > like "supported versions" and maybe mentioning that many distros have a > > policy > > of supporting the current release and the previous release. > > One way we can dodge around this is by changing those assertions to "version X > and later". Forward-compatibility breaks affecting the stuff we use are so > rare that I think this is safe - and on thoe exceotional occasions they cause > enough ruckus that we are unlikely not to notice. > > What do you think of this policy? That still makes this table a maintainence headache. Can we instead say that we built on modern/supported-by-upstream releases of popular operating systems and distributions. And we build test on the platforms supported by our CI system. See https://gitlab.com/NTPsec/ntpsec/blob/master/.gitlab-ci.yml for the specific platforms that we test on. Otherwise, we're maintaining data in 2 places and it's going to get out of sync. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: POSIX lesson please
On Mon, Dec 24, 2018 at 03:50:33PM +0100, Achim Gratz via devel wrote: > Am 24.12.2018 um 11:32 schrieb Hal Murray via devel: > > You can see POSIX.1-2001, SUSv3, online for free here: > > http://www.unix.org/version3/ > > I prefer the online version from the Open Group: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/timer_create.html > > > http://www.unix.org/version3/inttables.pdf has a table that says "tmr" for > > the > > timer_xxx functions under the POSIX Base column. setitimer says xsi in that > > column. I assume those are tags for some sort of subset, but I haven't > > found > > the descriptions for them and/or what POSIX requires or what we require. > > No, XSI likely refers to the X/Open Systems Interface extension to the ISO C > Standard. > > http://pubs.opengroup.org/onlinepubs/9699919799/help/codes.html That's from IEEE Std 1003.1-2017 (which is a revision of 1003.1-2008). We support 1003.1-2004 per .../devel/hacking.txt http://pubs.opengroup.org/onlinepubs/009695399/functions/timer_create.html includes a note "TMR" that says: "The functionality described is optional. The functionality described is also an extension to the ISO C standard." So timer_create is optional for the minimum POSIX version that we support. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: puthon curses on NetBSD
On Tue, Dec 11, 2018 at 03:01:06PM -0800, Gary E. Miller via devel wrote: > > I am unaware of any other Python libraries not in the base Python that > NTPsec uses. For some reason *BSD don't like curses. > > You know any other used Python packages not in the base Python? What about the "gps" module? And maybe "argparse" since it's not part of python2.6? I can add non-fatal checks for these, similar to what I did for "curses". Everything else that we use should be part of the python core module set. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: puthon curses on NetBSD
On Mon, Dec 17, 2018 at 01:55:16PM -0800, Hal Murray via devel wrote: > > James Browning said: > > IIRC OpenSUSE does the same thing. I don't recall seeing a streak of red > > build fail indicators though. Possibly because I seem to remember adding it > > to the CI file. https://gitlab.com/NTPsec/ntpsec/commit/c433b80d98a162b9e1731c04bb03824752eda200 > Are you in a position to test buildprep on OpenSUSE and/or friends? It looks > to me like it needs python-devel. No, it needs the python-curses package. I've opened https://gitlab.com/NTPsec/ntpsec/issues/527 to track this. I'd like to see the software list (not the package list) added to .../INSTALL so that users on platforms not yet supported by .../buildprep can get a hint on what software is needed. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Why is ntpclients/ntploggps.py in ntpsec rather than gpsd?
Is there any value in my adding a waf check for the "gps" python module and skipping the checking/installation of ntpclients/ntploggps.py if it's not found, similar to what I did for the "curses" python module and ntpmon? It would take only a few minutes. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Leftover junk
> We can add it to the output of "./waf help" if that makes it easier to > discover. https://gitlab.com/NTPsec/ntpsec/merge_requests/854 Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Leftover junk
On Fri, Dec 07, 2018 at 01:37:44PM -0600, Richard Laager via devel wrote: > Traditionally, there has often been a "make uninstall" target that > removes everything that "make install" installs. Does NTPsec have a > ./waf uninstall? Yes. Waf provides it as a built-in. $ ./waf uninstall --- uninstalling host --- Waf: Entering directory `/home/selsky/src/ntpsec/build/host' Waf: Leaving directory `/home/selsky/src/ntpsec/build/host' --- uninstalling main --- Waf: Entering directory `/home/selsky/src/ntpsec/build/main' - remove /usr/local/lib/python2.7/dist-packages/ntp/ntpc.so - remove /usr/local/sbin/ntpd - remove /usr/local/bin/ntpfrob - remove /usr/local/bin/ntptime - remove /usr/local/lib/python2.7/dist-packages/ntp/__init__.py - remove /usr/local/lib/python2.7/dist-packages/ntp/__init__.pyc - remove /usr/local/lib/python2.7/dist-packages/ntp/__init__.pyo - remove /usr/local/lib/python2.7/dist-packages/ntp/agentx.py - remove /usr/local/lib/python2.7/dist-packages/ntp/agentx.pyc - remove /usr/local/lib/python2.7/dist-packages/ntp/agentx.pyo - remove /usr/local/lib/python2.7/dist-packages/ntp/agentx_packet.py - remove /usr/local/lib/python2.7/dist-packages/ntp/agentx_packet.pyc - remove /usr/local/lib/python2.7/dist-packages/ntp/agentx_packet.pyo - remove /usr/local/lib/python2.7/dist-packages/ntp/packet.py - remove /usr/local/lib/python2.7/dist-packages/ntp/packet.pyc - remove /usr/local/lib/python2.7/dist-packages/ntp/packet.pyo - remove /usr/local/lib/python2.7/dist-packages/ntp/poly.py - remove /usr/local/lib/python2.7/dist-packages/ntp/poly.pyc - remove /usr/local/lib/python2.7/dist-packages/ntp/poly.pyo - remove /usr/local/lib/python2.7/dist-packages/ntp/statfiles.py - remove /usr/local/lib/python2.7/dist-packages/ntp/statfiles.pyc - remove /usr/local/lib/python2.7/dist-packages/ntp/statfiles.pyo - remove /usr/local/lib/python2.7/dist-packages/ntp/util.py - remove /usr/local/lib/python2.7/dist-packages/ntp/util.pyc - remove /usr/local/lib/python2.7/dist-packages/ntp/util.pyo - remove /usr/local/lib/python2.7/dist-packages/ntp/control.py - remove /usr/local/lib/python2.7/dist-packages/ntp/control.pyc - remove /usr/local/lib/python2.7/dist-packages/ntp/control.pyo - remove /usr/local/lib/python2.7/dist-packages/ntp/magic.py - remove /usr/local/lib/python2.7/dist-packages/ntp/magic.pyc - remove /usr/local/lib/python2.7/dist-packages/ntp/magic.pyo - remove /usr/local/bin/ntpleapfetch - remove /usr/local/bin/ntploggps - remove /usr/local/bin/ntpdig - remove /usr/local/bin/ntpkeygen - remove /usr/local/bin/ntpq - remove /usr/local/bin/ntpsweep - remove /usr/local/bin/ntptrace - remove /usr/local/bin/ntpviz - remove /usr/local/bin/ntpwait - remove /usr/local/bin/ntplogtemp - remove /usr/local/bin/ntpsnmpd - remove /usr/local/bin/ntpmon Waf: Leaving directory `/home/selsky/src/ntpsec/build/main' 'uninstall' finished successfully (0.090s) We can add it to the output of "./waf help" if that makes it easier to discover. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Split out ntpleapfetch
On Thu, Dec 06, 2018 at 11:48:37AM -0800, Hal Murray via devel wrote: > I think we should remove ntpleapfetch from the main package and tarball - > probably move it off to a separate package. Classic includes a perl version of the script (as /usr/bin/update-leap) in their packaging. So we should have something in our package (in a language of our choosing), or we need to explain clearly why we diverged from Classic. > Leaf sites shouldn't need it. They can get the leap-tonight from their > upstream servers. > > Many sites that do need it can get it from their distro. We should encourage > distros to package it their time zone data. Yes, many sites won't need it. Either because they get the data from GPS, upstream, or their distro. But we can provide the tool for those that need it. > It has too high a chance of turning into a DDoS on the web servers providing > leap-seconds.list. Why? We're not shipping a cronjob that calls it. And neither are the packagers. Any DDoS would be the responsibility of the site admins for creating their own cronjobs that are out of control. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Warnings from asciidoc
Hi, Let me clear up two things: - The project doesn't build docs by default (https://gitlab.com/NTPsec/ntpsec/blob/master/wafhelpers/options.py#L90). You must specify "--enable-doc" to "waf configure". - Our CI doesn't attempt to build documentation for all targets in an effort to make sure each CI pipeline doesn't take so long that developers are encouraged to side-step it. We build docs only in the "pages" pipeline. See https://gitlab.com/NTPsec/ntpsec/blob/master/.gitlab-ci.yml#L1 We build using an Alpine image since it's super small and fast to prepare, compared to other distros. The underlying problem that Hal saw was first reported upstream at https://github.com/asciidoc/asciidoc-py3/issues/13, and a fix was committed upstream at https://github.com/asciidoc/asciidoc-py3/pull/14 It was previously reported on this list by Udo at https://lists.ntpsec.org/pipermail/devel/2018-October/006703.html The last message in that thread was https://lists.ntpsec.org/pipermail/devel/2018-October/006706.html. I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1655337 so that Fedora can fix their package. We could build docs in every target, but warnings from asciidoc won't fail any builds since asciidoc still returns a zero exit code and we wouldn't notice the warnings unless someone specifically looked. These warnings don't impact the html, etc, generated by asciidoc. They're just ugly. asciidoc-py3 still reports as 8.6.10 so there's little that we can check and warn the user about during our waf configure/build steps. Unless we want to hardcode a check for F29 and emit a warning... So I don't think our project needs to do anything. I've filed https://gitlab.com/NTPsec/ntpsec/issues/521 so that we can track upstream progress and have something to point users to. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Testing merge requests
On Sun, Nov 04, 2018 at 09:47:14PM -0800, Hal Murray via devel wrote: > [Was: Subject: Re: ntpleapfetch broken on FreeBSD 11.2 or NetBSD 8.0] > > > I was working on that a little try checking out merge request !831 > > How do I do that? > > That should be simple, but it's not in my working set. I think I asked a > while ago and didn't get an answer that stuck. There is probably an > interesting property in git or gitlab that I don't understand. > > I need a way to back out if I don't like the change. Work in a clone and > throw it away if you don't like it is a possible answer, but I expect there > is > something better. If you click the "command line" link on https://gitlab.com/NTPsec/ntpsec/merge_requests/831, you'll see a pop-up with instructions on how to checkout that branch and play around with it: git fetch https://gitlab.com/jamesb_fe80/ntpsec.git ntpleapfetch.sh git checkout -b jamesb_fe80/ntpsec-ntpleapfetch.sh FETCH_HEAD Or similar. See also these tips for shortcuts for checkout out MRs: https://docs.gitlab.com/ee/user/project/merge_requests/#checkout-merge-requests-locally Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: fedora 29 issue
On Fri, Oct 19, 2018 at 03:24:13PM +0200, Udo van den Heuvel via devel wrote: > When building ntpsec on fedora 29 I see things like: > > [ 29/167] Compiling docs/driver_oncore.txt > /usr/bin/asciidoc:471: DeprecationWarning: Flags not at the start of the > expression '^(?u)[^\\W\\d][-\\w]*$' > return re.match(r'^'+NAME_RE+r'$',s) is not None > > This did not happen on fedora 28. > Not all docs show this message. Hi Udo, It looks like this was reported upstream in asciidoc per https://github.com/asciidoc/asciidoc-py3/issues/13 and fixed in https://github.com/asciidoc/asciidoc-py3/pull/14 Does your asiidoc script include this patch? What version of asciidoc does Fedora 29 ship with? Is that asciidoc using python2 or python3? (it looks like waf itself is using python2) Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Blizzard of warnings on NetBSD 8
On Tue, Aug 28, 2018 at 11:54:42AM -0700, Hal Murray via devel wrote: > It makes us look sloppy. We worked hard to get (almost) no warnings. We > should maintain that reputation. > > Also, we should document the new warnings the linker gives about tempnam from > the python library. Python fixed these warnings in 3.x per https://bugs.python.org/issue1318 But I guess we're seeing these with a newer, more strict compiler on NetBSD 8, since the Python2.7 code likely hasn't changed? > Just curious. Where in wscript land does the python library get added to > ntpd? (I couldn't find it the other day.) See "conf.check_python_headers(features='pyext')" in pylib/wscript. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Blizzard of warnings on NetBSD 8
On Mon, Aug 27, 2018 at 05:20:45PM -0700, Hal Murray via devel wrote:
>
> What's the story?
>
> I'm catching up after being off line for several weeks. I updated a NetBSD
> box to 8.0 and now it produces lots and lots of warnings that I expect would
> get fixed before a release.
I brought up a NetBSD 8 VM on GCP a week ago, but it's not yet wired into the
CI jobs.
Are you seeing these same warnings on NetBSD 7?
> Most are complaining about %m. Sample:
> ../../libntp/msyslog.c:512:5: warning: %m is only allowed in syslog(3) like
> functions [-Wformat=]
I collected a few links to when NetBSD added these checks for glibc-specific
attributes in https://gitlab.com/NTPsec/ntpsec/issues/498 What's the best way
to fix? printf("%s", strerror(errno)), as Gary suggested?
> There is also:
> ../../ntpd/ntp_control.c:2628:8: warning: format '%u' expects argument of
> type
> 'unsigned int', but argument 4 has type 'int' [-Wformat=]
I filed https://gitlab.com/NTPsec/ntpsec/issues/496 a week ago for this. I
don't understand where the int is coming from since ntohl() [buried under the
mess of macros] returns unsigned int.
> /usr/pkg/lib/libpython2.7.so: warning: warning: tmpnam() possibly used
> unsafely, use mkstemp() or mkdtemp()
> /usr/pkg/lib/libpython2.7.so: warning: warning: tempnam() possibly used
> unsafely, use mkstemp() or mkdtemp()
I don't see these functions in our code. Are these warnings from the python
package?
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Initial test coverage report
Ian, Is there a way to have Unity spit out information on test coverage percentage? If so, tell me how and I'll take a look at wiring it into our gitlab CI. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
