Re: Alternatives to port 123
On 2024-05-02 22:20, Hal Murray via devel wrote: I don't like adding a new top level (extra) to the config file syntax. In general, I agree with you on that. I'd keep it under nts. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Alternatives to port 123
On 2024-05-02 15:48, Hal Murray via devel wrote: There are 2 new options for the config file: nts port extra port They do the same thing. Pick one. Why two options that do the same thing? -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Hack for monitoring NTP servers
On 2024-04-11 14:39, Hal Murray via devel wrote: If somebody feels like hacking, something like this should be fun. The idea is to setup a ntpd server watching the servers you want to monitor. (noselect on the server line does that) The new code is a program that watches that server to see if the servers to be monitored are responding correctly and sends you email if they aren't. I think you're looking for this (plus some monitoring program like Nagios, Icinga, etc.): https://nagios-plugins.org/doc/man/check_ntp_peer.html -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Certificate geekery
On 2023-12-03 03:22, Hal Murray via devel wrote: I'm working on devel-TODO-NTS. (mostly deleting things) Currently, if a bad guy hacks or arm-twists a certificate authority, they can sign a certificate that the bad guy can use for a MITM attack. Yes, that's how the CA ecosystem works. That is absolutely a threat. Keep in mind that if a CA gets caught doing that, they will get the CA death penalty, ending their money printing business. CAA records and Certificate Transparency are also mitigations of this threat. We can make that a lot harder if we lookup the current root certificate that a server is currently using, find that certificate in a system's root cert collection, and add a ca xxx to the server line. That doesn't take any changes to ntpd. If that's a thing you want to do on your system, you can. IMHO, it's not something that we particularly need to promote, nor would I find it desirable operationally. If my NTP server changes their CA provider, then I won't be able to talk to them any more until I take manual action to adjust the pin. Is that called pinning? If not, is there a term for it? Wiki has a page for a related proposal: https://en.wikipedia.org/wiki/Certificate_pinning It sounds like pinning to me, at least a form of the general idea. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: SHA1 or SHA-1?
On 2023-11-13 02:17, Hal Murray via devel wrote: I'm looking into making our documentation consistent. NIST and Wikipedia use SHA-1. NIST is the authority on SHA, so I'd follow their naming. -- Richard ___ 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
Is there any AppArmor involved? e.g. does /etc/apparmor.d/usr.sbin.ntpd exist or are there apparmor failure messages in dmesg? -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
On 2023-09-12 00:03, Hal Murray via devel wrote: Maybe it's time to switch to Go? The opportunity for that may have passed. There's a new ntpd-rs project writing an NTP daemon in Rust: https://github.com/pendulum-project/ntpd-rs It's certainly not a full ntpd replacement yet (e.g. no local refclock support), but they are still doing active development. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Is python2 dead?
On 2023-09-04 17:38, James Browning via devel wrote: On Sep 4, 2023 14:46, Matthew Selsky via devel wrote: 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? By dropping 2.6 support we would eliminate the need to check for argparse in a few place, glue to replace ordereddict?, be able to use with for resource allocatoion, and the need to pretend to test on 2.6. By dropping 2.7 we could probably assume secrets which simplifies ntpkeygen, simplify ntp.poly, be able to drop the now oldoldstable? runner testing for asciidoc on python 2 support, and also have the option of adding type hinting. Dropping support for Python 2 should allow for dropping most of the poly infrastructure. That code (pylib/poly.py) involves some contortions (see also [1]) to make it possible to run on both Python 2 and Python 3. The downside is that it is most definitely not Python 3 idiomatic. In fact, it's closer to Python 2 than Python 3. If you look at the code, you'll see that there's very little that happens in the Python 2 case and a lot more that happens in the Python 3 case. This was (presumably) a good trade-off when trying to minimize the work for an existing codebase to gain Python 3 support without dropping Python 2 support. But it does leave technical debt to be cleaned up when going full Python 3. If we dropped support for Python 2, that should come in a couple phases. Phase 1 would be removing anything relating to Python 2 itself. It should probably also include any changes relating to Python detection with waf. Phase 2 would be /carefully/ removing usage of the poly infrastructure, converting to idiomatic Python 3 approaches. Once that is done, then we'd be rid of the 2 -> 3 conversion baggage. These phases need not be separate releases, but should (IMHO) certainly be separate commits and likely be separate PRs. [1] http://www.catb.org/esr/faqs/practical-python-porting/ -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.2a released
On 2023-08-07 15:13, Fred Wright via devel wrote: On Fri, 4 Aug 2023, James Browning via devel wrote: On 08/04/2023 6:35 PM PDT Fred Wright via devel wrote: :::snip::: I notice that the two commits for that don't seem to be in any branch. Having commits only "owned" by a tag and not a branch seems fragile. I do not think it is particularly fragile; I mean the garbage collector is that aggressive, is it? It's not just about the garbage collector. Git's general philosophy is that non-transient commits are exepected to exist on at least one branch I'm not sure that I agree with that. In git, unlike other VCSs, commits are not part of a branch. A branch just points to a commit, which is then definitionally the head of that branch. A branch in git is basically like a tag that moves around. 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. Attempting to merge it into master now would just result in a conflict that would have to be resolved by turning it into an empty commit (and giving git explicit permission to do that). The commit will not be empty. git checkout master git merge NTPsec_1_2_2a # Undo the change to VERSION # Resolve the merge conflict in ntpd/nts_cookie.c in favor of HEAD. # Resolve the merge conflict in NEWS by keeping both bits. There will be a merge conflict, of which the code change can be thrown away, but the commit will not be empty. There will remain changes to the NEWS file. The resulting commit has these changes relative to master before you started: diff --git a/NEWS.adoc b/NEWS.adoc index 276f41c83..86170323e 100644 --- a/NEWS.adoc +++ b/NEWS.adoc @@ -34,6 +34,11 @@ on user-visible changes. * ntpdig shows packet delay in JSON output. +## 2023-08-02: 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) + ## 2022-12-28: 1.2.2 * Restore/cleanup NTPv1 support diff --git a/VERSION b/VERSION index 23aa83906..0495c4a88 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -1.2.2 +1.2.3 The real problem at that level is that the patch wasn't originally created via "git cherry-pick" git cherry-pick wouldn't have changed anything about the branch/tag situation. Using cherry-pick is fundamentally the same as using diff and patch. It doesn't preserve any metadata. which is because the original master commit combined multiple changes into one commit. This is one example of why that should be avoided. It's only in hindsight that one can say the original commit combined multiple changes. At the time the original commit was made, Hal wasn't aware of this problem. I might quibble a bit more about commit d9a786fe0fafa7ed7357783798b1f206884d28b7, though. That ideally should have been the commit that we shipped as 1.2.2a and then the other half adding the counters for it. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.2a released
On 2023-08-07 14:34, Matthew Selsky wrote: 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. If you do that with `git merge` rather than copy-and-paste, then the commit(s) on the 1.2.2a tag will be accessible from master. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTPsec 1.2.2a released
On 2023-08-04 20:35, Fred Wright via devel wrote: I notice that the two commits for that don't seem to be in any branch. Having commits only "owned" by a tag and not a branch seems fragile. I think it's fine for a backport fix release like this. 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. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: I am bidding for power and have yet more branches for consideration.
I reviewed all of these, am opposed to none, approved two, and merged one. Details on the tickets. I'd especially like to hear from Gary on the gpsd one. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
On 1/13/23 18:33, Gary E. Miller via devel wrote:
Yo All!
Looks like there are four cases to support with shmTime:
1: 64-bit time_t with 64-bit ints:
All known 64-bit distros (?)
Works after 2038
No change required.
2: 64-bit time_t with 32-bit ints:
All *BSD (?)
Works after 2038
No change required.
3: 32-bit time_t with 32-bit ints, No #define to get 64-bit time_t
glibc version 2.33 and before
Fails in 2038
No change possible
4: Optional 64-bit time_t with 32-bit ints. #define to get 64-bit time_t
glibc version 2.34 and later
Works after 2038
Incompatible with unmodified chrinyd, ntpd, htpshmmon, etc.
Fix possible.
So, looking only at option 4. The one that we can improve.
I think you have captured the options correctly.
I had over looked the "int dummy[8]" in shmTime that Richard pointed out.
CUrrently gpsd has set those fields to 0.
In that case, and only that case, change shmTime as follows:
From:
struct shmTime
{
[...]
time_t receiveTimeStampSec;
[...]
int dummy[8];
};
To:
struct shmTime
{
[...]
// because we use 64-bit time_t, but ntpd expects 32-bits
// ignore the sign bit
int receiveTimeStampSec;// lower 31-bits of 64-bit time_t
[...]
// use the first dummy, previously zero
int top_time_t; // upper bits of 64-bit time_t
int dummy[7];
};
Before 2038, top_time_t will always be zero.
After 2038, until 2106, top_time_t will be always one.
That maintains compatibility with existing SHM users.
That works with existing SHM users until 2038.
That works with modified SHM users until the end of 64 bit time.
I like it! In broad strokes, this seems like the right solution. Way
better than my ideas about trying to use a magic and detect where it is.
There is another time_t field in the struct. Does that also have to change?
Should top_time_t be unsigned? The original 64-bit time_t will be
signed, but you know that it is always positive. You put the lower 31
bits in the original field (which makes sense, as you don't want the
32nd bit to go in the sign bit spot of the original field). That leaves
64 - 31 = 33 bits to save. One of those is the sign bit. Since we know
it is positive, we can drop that. So top_time_t should be unsigned to
make that clear.
--
Richard
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘64-bit time_t on glibc 2.34 and up
On 1/12/23 19:10, Gary E. Miller via devel wrote: How does ntpd know what size time_t to use? And thus know the size of shmTime? How do we know portably, preserving backwards and forwards compatibility? In hindsight, maybe shmTime should have started with a 1 char version field,or magic field. But, no such luck. Here are some thoughts on various options. I don't know what valid values of "mode" are. Could that be used, possibly by setting some high bit(s) to indicate a 64-bit time_t and a 32-bit int? That would break backwards compatibility, though, as old readers would see modes they do not expect. There might be an option to do something around leap/precision/nsamples/valid if some of those have sufficiently restrictive legal values. I'm not immediately seeing something obvious. The closest I see might be something around valid vs precision. If valid, for example, is 0 or 1 (with only 1 being useful) and 1 is not a valid precision, then you'd be able to differentiate them heuristically. That is, look at it as a 32-bit time_t struct; if valid is 1, then it's a valid 32-bit struct. If valid is 0, then you aren't going to use it anyway. If valid is anything else, then it's actually a 64-bit time_t struct (and you were looking at precision). Do you know if, _in practice_, providers of shmTime are providing zeros for the dummy[8] padding? If so, then (subject to agreement from the various projects), part of that could be defined as a magic. Of course, the problem there is that you need to find dummy[x], which can be in different positions depending on the struct size (which is the issue at hand). One possible solution would be to burn a second integer of the padding and define e.g. dummy[3] as always 0 and dummy[5] as a magic. Then the reader looks at the structure in 32-bit time_t layout. If you find dummy[5] == magic && dummy[3] == 0, then it is the 32-bit time_t structure indeed. Else if dummy[7] == magic && dummy[3] == 0, then it is the 64-bit time_t structure. If neither of those match, then it is someone using the old-style no-magic structure and I suppose you have to assume the width of time_t is the same as what you were compiled with. mode mode count count clockTimeStampSec clockTimeStampSec (first 32 bits) clockTimeStampUSecclockTimeStampSec (second 32 bits) receiveTimeStampSec clockTimeStampUSec receiveTimeStampUSec receiveTimeStampSec (first 32 bits) leap receiveTimeStampSec (second 32 bits) precision receiveTimeStampUSec nsamples leap valid precision clockTimeStampNSecnsamples receiveTimeStampNSec valid dummy[0] clockTimeStampNSec dummy[1] receiveTimeStampNSec dummy[2] dummy[0] dummy[3] ZERO dummy[1] dummy[4] dummy[2] dummy[5] MAGICdummy[3] ZERO dummy[6] dummy[4] dummy[7] dummy[5] MAGIC dummy[6] dummy[7] Options (for 32-bit only): 1. Do nothing, stick with 32-bit time_t. Fail in 2038. If we can easily do better, we should. 4. gpsd and ntpd always use 64-bit time_t going forward. Admin needs to mix and match. I think ntpd (and probably gpsd too) should enable whatever option to use 64-bit time_t if the platform supports it. But do we need to still support existing 32-bit platforms where time_t is only 32-bit? Probably? [reordered for reply flow] 3. Add run time options to gpsd and ntpd to specify time_t size. If we can't detect automatically, it seems like this is part of the solution. So maybe this looks like: - Use 64-bit time_t (generally, at compile time, for the whole application) if the platform supports it. - For the SHM interface, default to using platform time_t size as now. - Provide a run time option to force the SHM size to 32 or 64 bits. - This option should take effect on 32-bit architectures only. For config file compatibility, it should be parsed the same everywhere. But then, on a 64-bit architecture, is specifying 32 bit time_t for SHM an error, or ignored with a log warning? The run-time configuration approach does not require any automatic detection or coordinating across multiple projects. It is both forwards and backwards compatible, but only by administrator action. The downside is requiring that administrator action, but that only happens in the case of mismatched time_t across the SHM boundary. -- Richard OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: proposal for sntp program: include 'delay' in json output
On 1/3/23 13:46, Gary E. Miller via devel wrote: Yo folkert! On Tue, 3 Jan 2023 08:58:40 +0100 folkert wrote: Can I please send the patch via e-mail? I've been struggeling with gitlab for an hour and whatever I do it keeps complaining that I'm not allowed to push to the project (my own clone, in a branch). I think you already sent the patch by email. Twice. Since you are not a developer you can not push to the project, but you can create a Merge Request or Issue. I just created an issue for this: https://gitlab.com/NTPsec/ntpsec/-/issues/758 I converted this to a MR so the CI runs against it and so it can be easily merged: https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1296 The change itself seems reasonable to me. -- Richard OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: We need to test leap smearing :)
On 12/21/22 17:26, Hal Murray via devel wrote: Does anybody use it? Do any distros build with it enabled? Should we add an "#warn untested" to the code? I was asked to enable it in Debian, but I did not. Note that my understanding was that "enable" meant "compile in the support such that users could choose to enable it in the config" not "enable it by default". I did not enable it because NTPsec's implementation of smearing (inherited from NTP Classic) does not match the smearing algorithm(s) used by the big players that use smearing (e.g. Google and Facebook, IIRC). -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
On 5/9/22 02:38, Hal Murray via devel wrote: Does anybody know how the initial time gets set on a Raspberry Pi -- before ntpd gets called? I believe you're looking for "fake-hwclock". It periodically saves the time to a file (allegedly* /etc/fake-hwclock.data) and restores it on boot. * My home pi died, so I can't immediately double-check this. Should we do something like set the time to the time stamp of the drift file? (if it is significantly newer than the current time) Probably not. I still think we need a more comprehensive approach to this bootstrapping problem. The problem is, I don't have the time to write it. But I gave my thoughts before: https://lists.ntpsec.org/pipermail/devel/2019-February/007576.html The only update I have is that this statement is not true: "A normal CA will not issue certificates that are valid longer than their root". Let's Encrypt is serving a chain to the expired DST Root for enhanced compatibility with old Android devices. That could backfire if, somehow, the system time got set into the future. I had that happen once. It might have been due to a GPS rollover. -- Richard OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Knob: certificates for NTS-KE vs web
Maybe not so easy in practice, given the CT issues today: https://www.reddit.com/r/sysadmin/comments/ugwkh2/all_of_the_sudden_seeing_chrome_error_err/ -- Richard > On May 3, 2022, at 03:40, Richard Laager wrote: > > That seems like low-hanging fruit. We would have to ship an > application-specific ct_log_list.cnf to cover distros that aren't shipping > one. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Knob: certificates for NTS-KE vs web
On 5/2/22 14:36, Hal Murray via devel wrote: I think I've figured out why I think my knob is interesting. For the web, there are zillions of clients, most non-technical. A client is likely to connect to many servers, often new/different ones on different days. It all has to just work, straight out of the box. For NTS-KE, an at least somewhat technical admin sets things up. A client will only ever contact the few servers that are explicitly configured by the admin. The S in NTS-KE is security. It seems reasonable to me for the admin setting things up, or at least some of them, to be willing to spend a bit of time making things more secure. My knob is a tiny step in that direction. Is it a worthwhile step, though? You're giving me a knob to turn off wildcard acceptance. This presumes that the server I'm using isn't using a wildcard certificate; if it is, I have to accept the wildcard certificate anyway (or use a different server). So this knob gives me a way, as the client, to ensure that a server that is not using a wildcard certificate today doesn't start using one in the future. If the server legitimately switched to a wildcard certificate, then turning this knob only achieved the result of gratuitously breaking my access to that server. But we're trying to protect against attacks, so let's focus there. So this knob gives me a way, as the client, to ensure that a server that is not using a wildcard certificate today cannot be MITMed by an attacker possessing a non-expired wildcard certificate (from a root that I trust) that covers its hostname. Where would the attacker get such a certificate? A. A compromised CA If misissuance is happening at any kind of scale, this should get caught by people paying attention to Certificate Transparency logs (discussed below), regardless of whether or not ntpd is checking CT logs. But a compromised CA could just issue a non-wildcard certificate, so the knob hasn't helped here. B. A compromised server at the example.com site that requested and approved *.example.com. Here again, it could just as well have asked for time.example.com or whatever. In fairness, I will admit that request a wildcard certificate once is easier, and allows it to be used against as-yet-unknown targets at example.com compromised in the future. On the other hand, sites that don't use wildcard certificates can use CAA to prevent issuance of them. C. A legitimate wildcard certificate from some other server at example.com. This seems like the most likely scenario. So this knob gives me a way, as the client, to ensure that a server that is not using a wildcard certiciate today cannot be MITMed by an attacker who gets a non-expired wildcard certificate from another system at the end site. That's not zero, but it's not some huge thing either. Unless we plan to change the default (which is a compatibility risk), how many people are ever going to turn that knob? So now we have a small benefit times a very small userbase. The code for the knob isn't free; there's bug risk and maintenance cost to everything. And this is in a security-sensitive pathway (certificate validation). The biggest risk that I can see is the root server collection that comes packaged with most distros. We should be able to write a script that figures out what cert in the root collection each server needs. You're on the path towards pinning. I'm pretty sure we've discussed that before here. In the browser world, pinning seems to have gone out of style in favor of Certificate Transparency logs: https://certificate.transparency.dev/howctworks/ https://en.wikipedia.org/wiki/Certificate_Transparency Code-wise, I haven't looked in any detail, but this might be a reasonable starting point: https://sites.google.com/site/certificatetransparency/certificate-transparency-in-openssl To test, I had to do the following: # Build a ct_log_list.cnf since my distro doesn't provide one # (grumble grumble) git clone https://github.com/tiran/ct_log_list.git cd ct_log_list make generate sudo install -m 644 ct_log_list.cnf /etc/ssl/ sudo ln -s /etc/ssl/ct_log_list.cnf /usr/lib/ssl/ # Then I can see that (unsurprisingly) I'm already serving a certificate # with SCTs. openssl s_client -connect ntp1.wiktel.com:4460 -ct So basically, can we make ntpd verify that? That seems like low-hanging fruit. We would have to ship an application-specific ct_log_list.cnf to cover distros that aren't shipping one. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Getting ready for a release, wildcards
I looked at 1268. I split it into a bunch of pieces and merged a bunch of it. That shrinks the diff, making it easier to follow. Further comments are on the MR. On 5/2/22 09:35, countkase--- via devel wrote: On Thursday, April 21, 2022, 09:20:06 AM PDT, Matt Selsky wrote: Hi James, I'm not sure if you're being serious or not with the "nah" :) The potential mac truncation seems serious. I'm not sure about the other 2 issues. Let me know what you think. 1254 temporarily resolved the NUL truncation issue before being reverted for breaking (EOL) FreeBSD 11. 1267 solved ntpqs' inconsistent formatting in * info and * stats. Finally, 1266 resolves the ineffective test log formatting with Python 3. In response to 1254 being reverted I crafted 1268 which changed the test to an AES-based ntpdig send that works on FreeBSD 11. I can not however approve or merge anything, having left the project over being unable to approve or merge my own stuff. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Getting ready for a release, wildcards
On 4/22/22 02:08, Hal Murray wrote: +1 to NOT making this a knob. Would you please say more. It would be invisible unless you go looking for it. Are you against unnecessary knobs in general? Yes. If I had pushed this code a month or 3 ago when we weren't discussing a release or wildcards, would you have spoken up against it? If I saw it, yes. I did speak up about the documentation change. That one is concerning in the same _way_, but to a far lesser _degree_. Granted I'm at a small shop, but I have a lot of operational experience with TLS. I've configured TLS in different daemons for a whole bunch of protocols. For a non-exhaustive list: * HTTPS (Apache & nginx) * FTP (ProFTPD) * IMAP/POP (Dovecot) * SMTP (Postfix and Exim & sendmail before that) * syslog (rsyslog) * IKE VPNs (strongswan on Linux & pfSense; Cisco ASAs) * NTS (NTPsec) of course They all work pretty similarly: * For a server, you configure the key, certificate, and chain (sometimes one file, sometimes two, sometimes three). * You can generally configure the cipher lists on both clients and servers (though I generally only bother with that on servers). * Servers (and only servers, given how the protocol works) often have an option to whether to "honor" (read: force) the server's cipher _order_. The alternative being to use the client's cipher _order_. * When you're acting as a client, you can generally configure the root CAs in some fashion. I'm not against adding the typical options to daemons. And in fact, I've worked with upstreams to do just that. In the case of rsyslog, I had to wrap with stunnel for a while due to some limitation. I worked with upstream and/or Ubuntu to get that fixed. In the case of ProFTPD, it didn't have the TLS1.3-specific configuration, I requested that as a feature, which they did add. I also worked with ProFTPD as well as WinSCP (and reported issues to another client or two) to make SNI on FTPS viable in the real world. I've also attempted to configure TLS in a daemon (and client) where it was clear the daemon author had absolutely no idea what they were doing. In that case, they wanted you to configure a CA (yes really!) and the daemon would generate server certificates on demand. That was clearly insane. In that case, I left them speaking plaintext and wrapped the connection with stunnel on both sides. This glaring issue left me very concerned about the quality of this daemon's implementation generally. Unfortunately, it's the only FOSS solution in that problem space, so I had to keep using it. You adding a knob about wildcards (and your recent documentation change) are red flags for me. While they certainly aren't as bad as the "give me a CA" example above, when you're doing things that deviate from widely established practice across different projects, I get concerned. It suggests to me that A) you don't know what you're doing in this space, and/or B) you're building what I call a "science fair project" (something fun to explore the technology that has little to no production use case). If you don't have a lot of experience in this area, that's totally fine. There's no shame in that. Not being a TLS expert doesn't take anything away from your experience in the time & NTP space generally. Please survey the landscape of existing daemons / other people to get a feel about what TLS options are normal. If you want to build a science fair project, by all means do that. But not in master for a critical daemon like ntpd. There may be cases where ntpd needs to deviate from established practice. For example, maybe we need some knobs related to bootstrapping, due to the unique role that ntpd plays (i.e. getting the time correct so that certificate NotBefore/NotAfter can be verified). I've talked about that at length before. So I'm not 100% against ntpd having a TLS option that isn't in other daemons, but it needs to be justified by something unique to ntpd/NTS. I see no reason that ntpd specifically should have different wildcard handling than typical TLS clients for various protocols. Now, I certainly understand there are security trade-offs inherent in wildcard certificates. And a lot of the benefit is lost once you're no longer dealing with certificates manually and are instead automating their issuance. Likewise for paid vs free. Here's what looks to be a decent write-up (and some good comments there): https://gist.github.com/joepie91/7e5cad8c0726fd6a5e90360a754fc568 But none of that feels ntpd-specific to me. I wonder how many unnecessary features there are in the current code base. A big part of the reason for NTPsec was removing unnecessary cruft from NTP Classic. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release, wildcards, etc
On 4/21/22 03:17, Hal Murray via devel wrote: There are 8 cases. I think I tested them all. If it will make you happy, I'll test again, being careful to check all 8 cases. 8 cases? I thought it was one setting, which would be 2 cases. Can you expand upon what you're actually proposing? Ideally as a merge request, but at least explain the knobs here. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Getting ready for a release, wildcards
+1 to NOT making this a knob. On 4/20/22 15:07, Matt Selsky via devel wrote: Hi Hal, If you're sufficiently happy with my code change, then you can click "approve" and "merge" on https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1264 I would rather not add knobs unless someone asks for this to be a knob. Thanks, -Matt From: Hal Murray Sent: Wednesday, April 20, 2022 2:12 PM To: Matt Selsky Cc: devel@ntpsec.org ; Hal Murray Subject: Re: Getting ready for a release, wildcards [The mail system is in sloth mode again.] matthew.sel...@twosigma.com said: I don't think we should have a knob for disabling wildcards. This is not the sort of knob that operators expect (what other software provides such a knob?) and we're just adding another code path to test. I'll be interested in other opinions. Just because nobody else does it doesn't mean it's a bad idea. Somebody has to go first. If it's extra code on our end, think of all the code in OpenSSL that we don't exercise if we don't allow wildcards. I have running code. The default is to allow wildcards so nobody will get surprised. I can push later today. If you want to go the merge request route, somebody will have to give me a lesson. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Getting ready for a release, wildcards
On 4/19/22 17:01, Hal Murray via devel wrote: One is to update the nts cert documentation to say that it doesn't do any checking on the certificate. - Present the certificate in _file_ as our certificate. + Present the certificate (chain) in _file_ as our certificate. + + + Note that there is no checking on the certificate. + In particular, it may have expired or may not cover the host name + used to get to this server or may not be signed by a CA that + is in the clients root-server collection. Sure, that's all true. But, I'm not sure why you felt the need to mention this. That is how everything works. In general, it's not even guaranteed that a TLS-speaking daemon knows its own (external) hostname. It obviously can't know what is in the client's trust store. The only one of those things it could possibly check is whether the certificate is expired. But I recommend against trying to do that. It's not an expectation that daemons check that. More importantly, as always in the NTP space, that can lead to chicken-and-egg problems. If I have an isolated (not connected to the Internet) server with GPS, it might not have correct time when ntpd starts, but will get it once the GPS locks. -- Richard OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS doesn't work with 1.1.8 shipped with Ubuntu 20.04 LTS
For clarity, the upcoming 22.04 LTS release has this fixed, as do the currently-supported non-LTS releases. The ntpsec in 18.04 LTS does not support NTS at all. So it's only 20.04 that is a problem. I've been aware this is a problem, but literally nobody has complained to me, so I haven't bothered to do anything about it. For work, I backport NTPsec myself into our PPA (note: it has other unrelated packages!): https://launchpad.net/~wiktel/+archive/ubuntu/ppa/+packages?field.name_filter=ntpsec&field.status_filter=published&field.series_filter= I'll try to file an SRU [1] request for the NTS label thing. Since this is in universe, it's not going to be a high priority for them. Additionally, it's a backwards incompatible change, so that's problematic. I think I'll leave the port number thing alone, as that can be addressed in the config file, as you noted. Is anyone here a paying customer? If so, once I file the public bug, you could file a case under your support contract, which will motivate them a lot more. I am a paying customer, but that might be a bad look for it to come from me. [1] https://wiki.ubuntu.com/StableReleaseUpdates On 4/7/22 12:39, Hal Murray via devel wrote: Ubuntu ships 1.1.8 with 20.04 LTS. NTS doesn't quite work. 1.1.8 was released before the RFC came out. There were a couple of late changes. The port number we can fix in the config file. There was an incompatable change to the string used to make keys. There is no easy fix for that. We could hack our NTS-KE server to also listen on another port and use the old string on that port. Aside from being an ugly hack, it only works for our servers. (and nts.ntp.se which already does something like that) Can anybody give me a lesson in Ubuntu release procedures? Are they likely to be interested in fixing this? (so NTS works) The fix to 1.1.8 is a simple change to a text literal. Can they fix their copy of the source if we send a patch file? Would it help if we released a patched version of 1.1.8? ... Could we convince them to update to Debian's 1.2.0+xx? (or our 1.2.0, or 1.2.1 our current release) -- Long story here: Incompatibility between NTS in ntpsec 1.2.1 and 1.1.8? https://gitlab.com/NTPsec/ntpsec/-/issues/732 -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
On 12/28/21 3:35 PM, Hal Murray via devel wrote:
Is there any magic not-before date in the ntpsec environment?
I think we used to have the build date in the version string but that was
removed to make builds reproducable. I thought we added something in a
#define someplace with the idea that it would get updated with each release,
but I can't find it.
This is what you're thinking of (slightly trimmed):
commit f76af8b7f4080ce7c1334f24c74c7259b84dc899
Author: James Browning
Date: Thu Dec 31 11:34:06 2020 -0800
Remove --build-epoch and replace it with arbitrary --build-desc text.
Passing '--build-desc=$(date -u +%Y-%m-%dT%H:%M:%Sz)' restores the
previous default extended version.
The build epoch has been replaced with a hardcoded timestamp which will
be manually updated every nine years or so (approx 512w). This makes
the binaries reproducible by default.
--- a/libntp/ntp_calendar.c
+++ b/libntp/ntp_calendar.c
@@ -38,7 +38,7 @@ ntpcal_get_build_date(
struct calendar * jd
)
{
-time_t epoch = (time_t)BUILD_EPOCH;
+time_t epoch = (time_t)1577836800; // 2020 Jan 01 -> 1863820800
- 2029 Jan 23
struct tm epoch_tm;
ZERO(*jd);
--
Richard
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: after network...
On 11/27/21 8:45 AM, Udo van den Heuvel wrote: On 26-11-2021 06:52, Hal Murray wrote: ntpd does not start, reliably. What goes wrong? Is there an error message? What I can find in journalctl -b: systemd[1]: Dependency failed for Wait for ntpd to synchronize system clock. That is a failure of ntp-wait.service, not ntpd.service. ntp-wait.service only serves a purpose (and only needs to be enabled) if something is going to depend on it. For example, on my email servers, I use a drop-in to configure dovecot.service to Requires= & After= ntp-wait.service. This way, dovecot does not start until ntpd has set the clock. This way, time never moves backwards, which Dovecot really hates. If you're not actually using ntp-wait.service, just disable it: sudo systemctl disable ntp-wait.service This is before the network scripts I still use (no network-manager...). network[2433]: WARN : [network] You are using 'network' service provided by 'network-scripts', which are now deprecated. network[2433]: WARN : [network] 'network-scripts' will be removed from distribution in near future. network[2433]: WARN : [network] It is advised to switch to 'NetworkManager' instead for network management. Thus I think it fails due to lack of network connectivity. If the above didn't answer your question, I'd check the following, probably in this order: 1) Are you sure that the issue is that ntpd is not dealing well with the network being up? 2) If so, can that be addressed with ntpd in some (trivial) fashion? 3) If not, try adding a drop-in (e.g. /etc/systemd/system/ntpd.service.d/network.conf) that adds Wants= & After=network-online.target. But note that your network subsystem must actually support the network-online.target. See also: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: after network...
On 11/16/21 12:42 AM, Udo van den Heuvel via devel wrote: Can we please adjust the service files so that also ntp-wait.service starts after we have network? Currently only ntpd.service has references to network... ntp-wait.service already has: Requisite=ntpd.service After=ntpd.service So ntp-wait.service can't start until ntpd.service has started anyway. What is the actual problem you are experiencing? -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python libraries: where to install?
On 11/5/21 1:43 AM, Hal Murray via devel wrote: ... How does waf decide where to put things? https://waf.io/apidocs/tools/python.html#waflib.Tools.python.check_python_version -- Richard OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Interleaved Mode (Was: Re: Using Go for NTPsec)
On 7/5/21 8:38 AM, Eric S. Raymond via devel wrote: There is a close-to-RFC to handle this area. "Interleave" is the buzzword. I haven't studied it. The idea is to grab a transmit time stamp, then tweak the protocol a bit so you can send that on the next packet. Daniel discovered it was broken and removed it from the protcol machine. Broken implementation or broken design? If the latter, is the current IETF proposal (wherever that is) still broken? -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Using Go for NTPsec
On 6/29/21 8:52 PM, Eric S. Raymond wrote: Richard Laager via devel : On 6/29/21 3:41 PM, 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. My two NTP servers are +- 0.1 ms and +- 0.2 ms as measured by the NTP pool monitoring system across the Internet. That's quite exceptionally good. It's normally hard to get to within an order of magnitude of that on a LAN, let alone a WAN. If this is surprising to you, perhaps I'm quoting the wrong thing. I was referring to the variance in the clock offset as plotted here: https://www.ntppool.org/scores/69.89.207.99 https://www.ntppool.org/scores/69.89.207.199 https://www.ntppool.org/scores/2600:2600::99 https://www.ntppool.org/scores/2600:2600::199 There are only two systems involved, but in practice, IPv4 and IPv6 can have different paths through the Internet. Do you have any theory of why your deviation is that low? Not particularly. Presumably it's just because of GPS PPS + good network? Both systems are GPS PPS. One uses a ublox demo board. The other gets its PPS from a telecom GPS primary reference source (that is also a BITS source for SONET and a telephone switch). The ublox one is the better of the two even thought it only has an indoor antenna. I think the GPS in that telecom PRS is not so great, and the oscillator is a TCXO, not Rubidium. Both servers are (older) server-grade hardware, dedicated to this task (way overkill even for public pool servers). ntpd at this moment is using ~22% of a single Intel Xeon L5420. They have 2x 1 Gig network connections (because that's standard here for redundancy) with two switches (a 1G then a 10G) before they hit my "core router". I'm the ISP. The ublox uses gpsd via SHM while the other uses the ntpd PPS driver. I fiddled with maxpoll a bit to optimize. The BITS clock PPS: server 127.127.22.0 minpoll 3 maxpoll 3 prefer fudge 127.127.22.0 refid PPS The ublox PPS: server 127.127.28.1 minpoll 1 maxpoll 1 prefer fudge 127.127.28.1 refid GPS -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Using Go for NTPsec
On 6/29/21 3:41 PM, 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. My two NTP servers are +- 0.1 ms and +- 0.2 ms as measured by the NTP pool monitoring system across the Internet. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Objectives for the next year
On 6/20/21 4:45 PM, Richard Laager via devel wrote: I get the impression that Go has a shallower learning curve (i.e. is easier to get started with), which is good, but may unfairly prejudice Go in quick Go-vs-Rust "bake off" comparisons. err... may unfairly prejudice Rust -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Objectives for the next year
On 6/20/21 2:31 AM, Achim Gratz via devel wrote: Eric S. Raymond via devel writes: My choice for a language to move to would be Go. Possibly one of you can argue for a different choice, though if you agree that Go is a suitable target I would find that information interesting. Since the last round of discussion both sides of the argument have been moving. If you believe that Rust will become a first-class implementation language for the Linux kernel, that would tip the scales in favor of rust considerably in my view. Most importantly that seems to ensure long-term support for one of the main target platforms for ntpsec. Both language eco-systems have drank a bit too much from the DevOps cool-aid (no, I don't trust any of your code registries or I could have installed an ntpd in Rust or Go already) and ntpsec would be well advised to figure out how to deal with the inevitable dependencies before it starts. I'd argue that Go would be a mistake for the daemon component and most of the library even without that consideration (Rust has deterministic runtime behaviour, Go does not -- by design). That's my "gut feeling" too. It seems that Rust is more geared to this sort of "systems programming" application. I get the impression that Go has a shallower learning curve (i.e. is easier to get started with), which is good, but may unfairly prejudice Go in quick Go-vs-Rust "bake off" comparisons. It also seems like a C-to-Rust conversion could be done incrementally. Various big projects are using Rust for part, but not all, of their application. I haven't tended to see that sort of thing with Go, but maybe it is happening there too. With the caveat that there is a LOT I don't know in this space, if it was my call, I'd aim for an incremental conversion of ntpd to Rust and leave the userspace tooling in Python. After the daemon is converted, I would re-evaluate whether the userspace tooling should be converted. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
ntpkeygen CVE-2021-22212 Follow-Up
In the course of looking at the fix (fc50a701fa) for CVE-2021-22212, I
found a couple of things that I think are worth mentioning...
The specific change is trivial, changing the starting point of the range
from 0x21 (!) to 0x24 ($). This avoids 0x23 (#). However, it differs
from the pre-bug version of this code in that it will not output 0x21
(!) or 0x22 (") either.
I see that the pre-bug version used random.randint(0x21, 0x7e) which is
inclusive on the upper end, while the new code uses 0x2[14] +
secrets.randbelow(0x5d) which is exclusive on the upper end. Thus, the
new code (both prior to and after the fix for this CVE) will no longer
use 0x7e (~). This is arguably a bug: the behavior differs between the
Python 3 / secrets and Python 2 / random versions for seemingly
unintentional reasons.
Both of these slightly reduce the entropy, but I'm not sure how much it
matters:
Pre-bug: [0x21, 0x7e] excluding 0x23 => 0x5d choices per char
Bug: [0x21, 0x7e) aka=> 0x5d choices per char
[0x21, 0x7d]
Now: [0x24, 0x7e) aka=> 0x5a choices per char
[0x24, 0x7d]
--
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: systemd-timesyncd
On 3/24/21 3:39 PM, Hal Murray via devel wrote: Do we have a HOWTO for setting up ntpsync? I also don't know what you mean by ntpsync. Does it include turning off systemd-timesyncd? NTPsec ships with etc/ntpd.service which has: Conflicts=systemd-timesyncd.service That Conflicts means ntpd.service and systemd-timesyncd.service can't both be running. Did that unit file get installed on your system (to e.g. /etc/systemd/system/ntpd.service), or did you end up some state where you only have /etc/init.d/ntpd (and thus the unit is coming from systemd-sysv-generator)? You can check where the unit is coming from with: systemctl status ntpd -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Lesson/Example please
On 3/15/21 2:06 PM, Richard Laager via devel wrote:
On 3/14/21 11:25 PM, Hal Murray via devel wrote:
Can anybody give me a pointer to code that does this? Or steer me in the
right direction, or ...
There is a recursive tangle of struct needs function and function
needs struct, but the function only needs a pointer to the struct so I
think that should work.
Personally, I'd probably typedef the struct:
typedef struct _NtpSomething NtpSomething;
struct _NtpSomething
{
void (*some_func) (NtpSomething *);
}
If you want to typedef the function too, something like this should work:
typedef struct _NtpSomething NtpSomething;
typedef void (*NtpSomeFunc)(NtpSomething *);
I failed to edit this after copying-and-pasting. Correction:
struct _NtpSomething
{
NtpSomeFunc (NtpSomething *);
}
--
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Lesson/Example please
On 3/14/21 11:25 PM, Hal Murray via devel wrote:
Can anybody give me a pointer to code that does this? Or steer me in the
right direction, or ...
There is a recursive tangle of struct needs function and function needs struct,
but the function only needs a pointer to the struct so I think that should work.
Personally, I'd probably typedef the struct:
typedef struct _NtpSomething NtpSomething;
struct _NtpSomething
{
void (*some_func) (NtpSomething *);
}
If you want to typedef the function too, something like this should work:
typedef struct _NtpSomething NtpSomething;
typedef void (*NtpSomeFunc)(NtpSomething *);
struct _NtpSomething
{
void (*NtpSomeFunc) (NtpSomething *);
}
--
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: discrete units
On 1/20/21 4:24 PM, Hal Murray via devel wrote: If you split the file it's a flag day for all users (no small matter when the uservase is as conservative and risk-averse as ntpd's) We should be able to write a script to do the splitting. It's a concern even beyond risk-aversion. My production ntpd configs are written by Ansible. So even if there's a script available, and even if the ntpsec package in Debian runs it by default (e.g. I do that wearing my packager hat), I still need to modify my Ansible configuration. And I'll likely end up needing to support systems before and after the transition for a while, so that adds some complexity. By all means, change what needs to be changed. I'm NOT arguing against changing the config. I just want to point out some consequences for users. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: GitLab | Projects forced to "Private" (#294196)
On 12/17/20 9:01 PM, Fred Wright via devel wrote: I'm not sure that is recoverable by users directly. And the "if you broke it, you fix it" rule ought to apply to the GitLab folks. They're still working on this. I think they thought they had everything, but they definitely don't. I've let them know on the support ticket I opened. I'm also seeing that www version of the website (and likewise for gpsd.io) is broken, while the non-www version works. I let them know about that too. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Blizard of mail from GitLab-Abuse-Automation
I got a response from GitLab's (presumably first-level support) on the ticket I filed earlier: "I see you're being affected by our @GitLab-Abuse-Automation bot. This could be related to Content Violation. I'm raising this internally and we will get back to you soon." The first part, at least seems like a form response, but hopefully the second part means someone will actually look at it. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Blizard of mail from GitLab-Abuse-Automation
Thanks. I added that to the GitLab ticket. Maybe that will help them get to the bottom of it. No response from them yet. On 12/16/20 5:38 PM, James Browning via devel wrote: After looking at it a little more it appears that something temporarily disconnected several forked projects and during the disconnect, a perfectly routine bot noticed the projects were 'gone' but did not notice when they 'came back'. As a result, the merge requests can not be reopened as the projects of the source branches are 'gone'. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Blizard of mail from GitLab-Abuse-Automation
GitLab Abuse folks: A user (bot?) named @GitLab-Abuse-Automation closed a bunch of legitimate NTPsec merge requests: https://gitlab.com/NTPsec/www/-/merge_requests/33 https://gitlab.com/NTPsec/www/-/merge_requests/42 https://gitlab.com/NTPsec/www/-/merge_requests/63 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/277 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1091 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1135 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1137 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1147 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1167 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1173 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1174 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1175 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1176 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1181 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1198 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1199 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1200 Worse, I (@rlaager) seem to be unable to reopen the MRs, so I can't fix this. For example, I tried reopening these two: https://gitlab.com/NTPsec/www/-/merge_requests/33 https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1091 Can you help? Other NTPsec developers are confused too: On 12/16/20 12:06 PM, Hal Murray via devel wrote: Can somebody tell me/us what happened? Why? ... On 12/16/20 2:04 PM, James Browning via devel wrote: > My guess is that GitLab deployed a new bot and it (probably) somewhat > overzealously closed almost all of the merge requests. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libntpc.so
On 12/14/20 8:14 PM, Hal Murray via devel wrote: I think we should install such a file containing LIBDIR on systems where/etc/ld.so.conf.d/ is a directory. No, please don't, for many reasons. If you attempt this, you're going to encounter a lot of pain points as you try to deal with exceptions for packaging scenarios (DESTDIR), non-system installs, etc. If a distro isn't searching any /usr/local lib directory by default, any application with a shared library is going to have trouble. (Also, this is regardless of whether that application is using autotools, waf, or whatever.) Additionally, the distro is inherently inconsistent if they have /usr/local/bin in the PATH, but no /usr/local lib directory in the ld.so.conf search path. I'm perfectly content to tell people to configure their system in that case. If we really want to do something to make that work out of the box, then I'd make the Python code search for the library in a fixed location (either instead of or in addition to the current behavior) and subst in LIBDIR. That way, the solution is application-local. Installing an application like NTPsec should not change global system state. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: libntpc.so
On 12/14/20 3:21 PM, Hal Murray via devel wrote: I setup a new machine over the weekend. Fedora 33, Python 3.9.0 After a build and install, ntpq couldn't find ntp.ntpc I fixed things by setting up /etc/ld.so.conf.d/ntpd.conf containing /usr/local/lib64/ and running ldconfig. Yeah, that's apparently what you have to do on Fedora (for any library built from source, not just NTPsec). See this old bug, for example, and various StackOverflow posts: https://bugzilla.redhat.com/show_bug.cgi?id=144967 The pro of not including /usr/local is that you avoid random old user-built stuff breaking the system. The con is that you force users to jump through extra hoops if they want to build things from source. I have a Fedora 32 box, Python 3.8.6, that works without the extra directive to ldconfig. I can't figure out how. Interesting. Check /etc/ld.so.conf, /etc/ld.so.conf.d/*.conf, LD_LIBRARY_PATH, all those folders for ntpc.so*, and the PYTHONDIR/PYTHONARCHDIR folders too. A Debian box has: /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf /etc/ld.so.conf.d/libaes_siv.conf /etc/ld.so.conf.d/libc.conf /etc/ld.so.conf.d/x86_64-linux-gnu.conf with a couple of /usr/local/lib in there but no /usr/local/lib64 Debian doesn't use the "lib64" style naming. It has the traditional "lib" and then uses what it calls "multiarch", so you have things like /usr/lib/x86_64-linux-gnu (and /usr/local versions too). I'm getting /usr/local/lib by default from waf, which is listed in /etc/ld.so.conf.d/libc.conf. So that's how that works. ntpq says: import ntp.ntpc Should that ntp be there? We aren't installing in xxx/ntp/ any more. It is correct as is. Those details are unrelated to each other. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘Python 2.7 broken
On 12/12/20 9:17 PM, Gary E. Miller via devel wrote: No, the tests are run before installing in DESTDIR. So that you can stop and not install broken things. You want to be using the built files before installing in DESTDIR. Agreed 100%. The tests run before install and need to work in the _build_ directory, not the installed location (PREFIX, LIBDIR, PYTHONDIR, PYTHONARCHDIR) and not the temporary install location (DESTDIR/PREFIX, DESTDIR/LIBDIR, etc.). [Replying to Hal here too.] On 12/12/20 11:33 PM, Hal Murray via devel wrote: > You want to test before install. It would also be good to test post > install, but that gets complicated if you have installed into DESTDIR > rather than the normal working place. As Fred said, things need not work in DESTDIR. DESTDIR is for building packages. It is reasonable to want "as installed" testing (which you and I have discussed before) at some point. What we have right now is post-build/pre-install testing. But either way, neither of those involve DESTDIR. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘Python 2.7 broken
On 12/12/20 7:53 PM, Gary E. Miller via devel wrote:
On Sat, 12 Dec 2020 19:46:22 -0600
Richard Laager via devel wrote:
On 12/12/20 7:07 PM, Gary E. Miller via devel wrote:
NTPsec git head broke Python 2.7, badly.
I believe James B is looking at test failures under certain
conditions, but I've never been able to reproduce them. I wonder if
this is that issue. Do the installed binaries break in the same way
when run normally, or are they only broken at the test step?
Installed python files run fine. The pure python module runs fine
installed.
So only broken during the test? That sounds like what James B was
looking into. I can't speak intelligently to that issue without more work.
I probably can help, at least somewhat, with this:
ntpc.so still getting
installed in the wrong place (/usr/local/lib64/python2.7/site-packages)
I agree that's not right. It should be something like /usr/local/lib64.
I just pushed a tiny change to master:
commit eee4607b256a5fb4263bd83b75f311e36be3a9ad
Author: Richard Laager
Date: Sat Dec 12 20:02:10 2020 -0600
configure: Print LIBDIR
This may be helpful for debugging install issues.
Signed-off-by: Richard Laager
diff --git a/wscript b/wscript
index 3b4eb869c..2db41c581 100644
--- a/wscript
+++ b/wscript
@@ -886,6 +886,7 @@ int main(int argc, char **argv) {
msg_setting("LDFLAGS", " ".join(ctx.env.LDFLAGS))
msg_setting("LINKFLAGS_NTPD", " ".join(ctx.env.LINKFLAGS_NTPD))
msg_setting("PREFIX", ctx.env.PREFIX)
+msg_setting("LIBDIR", ctx.env.LIBDIR)
msg_setting("Droproot Support", droproot_type)
msg_setting("Debug Support", yesno(ctx.options.enable_debug))
msg_setting("Refclocks", ", ".join(sorted(ctx.env.REFCLOCK_LIST)))
Can you run that and see what LIBDIR is set to for you at configure time?
Since the file is not in the right place ldconfig does not
know to look there. Nor should it.
Agreed.
--
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: ✘Python 2.7 broken
On 12/12/20 7:07 PM, Gary E. Miller via devel wrote: NTPsec git head broke Python 2.7, badly. I believe James B is looking at test failures under certain conditions, but I've never been able to reproduce them. I wonder if this is that issue. Do the installed binaries break in the same way when run normally, or are they only broken at the test step? Are you able to provide a commit where this works and preferably bisect this? I wonder if it's the FFI change or something else. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 2020/12/19 merges planned
On 12/12/20 10:00 AM, James Browning via devel wrote: On 2020 December 19, I intend to merge > !1196 Merged. Thanks! Closed #680. (the first patch of) !1167 I left some comments and questions there. !1189 LGTM. Approved. I'll leave it to you to merge. It'd be nice to have a "Fixes #558" in this commit message. > This should also close ... !957 Agreed and done. !1137 I can't (presently, at least) speak intelligently to that one (or the version of it in !1147). -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Is anyone else having trouble running ntpviz w/ 1 gps? (w/ patch)
On 10/6/20 8:29 AM, James Browning via devel wrote: > So, I was running ntpviz rarely, I updated to a (recentish git head), I > added a gpsd module symlink under ntpclients/, and boom breakage. I > followed the traceback to a line, I patched the line a couple of times, > and I requested the following patch. Was anyone else running into this? That format string was obviously broken. I merged your patch. Thanks! -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Syntax tweak: hostname@IP-Address
On 11/11/20 7:07 PM, Hal Murray via devel wrote:
> I've been thinking about something like this for a while. The idea is to be
> able to specify the IP Address to be used for contacting a NTP or NTS-KE
> server.
If you want to specify the IP address, just specify the IP address
("server 1.2.3.4") and don't bother with a hostname. Specifying an IP
instead of a hostname has historically been relatively popular with NTP,
especially in "network devices" (as opposed to "servers").
With NTS-KE, then you have the problem of certificate validation. That
is, the server needs to present a certificate with the IP address in the
subjectAltName. (Does NTPsec properly verify such a certificate today?)
Such certificates are available from paid CAs (and can be generated by
your own internal CA) but are not yet available from Let's Encrypt. The
good news is that they have finally put this on the TO DO list,
primarily because of demand from DNS-over-TLS:
https://letsencrypt.org/upcoming-features/#ip-addresses-in-certificates
https://github.com/letsencrypt/boulder/pull/4920
> There was discussion on the IETF-NTP list today about how to get NTP started
> on systems without (or broken) CMOS/TOY clocks whem you are using DNSSEC
> which
> needs time.
ntpd could maintain a cache (in /var/lib or better /var/cache) of the
results of DNS lookups. Specifically, something like this:
1. On startup, read the existing cache from disk, if present. This is
now an in-memory cache.
2. When ntpd gets a DNS query result, add it to the in-memory cache. If
the entry is new or different than the existing entry, set a flag that
the cache has changed. Cache entries will also have a timestamp of when
they were obtained. If ntpd has not yet set the system clock, use 0 as
the timestamp.
3. Once ntpd sets the system clock for the first time, update any cache
entries with 0 as the timestamp to the current time. Then, start a
periodic check: every X period of time, check to see if entries need to
be expired. If so, remove them and set the flag. If the cache
modification flag is set (from either adds or expirations), write out
the cache to disk and clear the flag. (The flag and periodic check are
to avoid a disk write for every DNS lookup.)
Only using timestamps after ntpd has set the clock should be a way to
safely set timestamps and handle cache expiration. The cache entry
lifetime should be very long.
Alternatively, instead of using timestamps to expire cache entries,
maybe a better policy would be to keep everything for the hostnames of
the configured servers/pools (and nothing else).
Then, of course, we need to actually use the cache:
4. If a DNS lookup fails (either a SERVFAIL or timeout), check the
cache. Perhaps this is _only_ used until ntpd sets the system clock?
So for a system with no battery-backed clock, on boot, ntpd will read
the old cache from disk. It will then try to resolve things via DNS,
which will fail because the on-box DNSSEC-validating resolver cannot
validate DNSSEC or the resolver cannot validate the DNS-over-TLS
certificate or whatever. That failure will result in the ntpd DNS cache
being used. Now it can spin up associations as normal.
There's still the chicken-and-egg issue with validating NTS certificates
without having valid time, but I have discussed that before:
https://lists.ntpsec.org/pipermail/devel/2019-February/007576.html
https://gitlab.com/NTPsec/ntpsec/-/merge_requests/942
--
Richard
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's the status of the work on shebangs and/or ctype?
On 9/17/20 7:07 PM, Gary E. Miller via devel wrote: > On Thu, 17 Sep 2020 16:52:06 -0700 > "Gary E. Miller via devel" wrote: > The fallback, goal 4, is "/usr/bin/env python". Does anyone object to making that "/usr/bin/env python3"? >>> >>> I am in favor of that change. I'm happy to implement that in a >>> follow-up commit. Here is the change from `/usr/bin/env python` to `/usr/bin/env python3`: https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1173 Gary identified some related issues before I sent this mail, so I went and worked on those first. Some are addressed in: https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1175 (trivial) https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1176 An open issue is: https://gitlab.com/NTPsec/ntpsec/-/issues/671 which is that attic and contrib currently contain scripts which are not installed, so there is no waf subst, so they can't have substed shebangs. There are any number of solutions. Let's discuss; ideally in #671, but here works too. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's the status of the work on shebangs and/or ctype?
On 9/17/20 11:54 AM, Gary E. Miller via devel wrote: > I agree with the first of 4 goals of the MR. ... > Rather than go around and around, how about a simple MR that only > implements goals 1 and 4? That is the first commit. I will merge that commit soon, barring any objections to that piece. > The fallback, goal 4, is "/usr/bin/env python". Does anyone > object to making that "/usr/bin/env python3"? I am in favor of that change. I'm happy to implement that in a follow-up commit. I would describe this change as "Make Python 3 the default". Should we do that now, or one release later? Any objections to now? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: What's the status of the work on shebangs and/or ctype?
I touched up the the shebang MR !1166 just now. It consists of three commits: The first commit is: Subst installed Python shebangs This adds a ./waf configure --pyshebang option. This is used as the shebang in the installed Python scripts. (Scripts that are not installed by waf have been left alone.) The default is still "/usr/bin/env python", so this is a no-op by default. There are various Python issues open. There are _at least_ these three: 1. Switch the Python module to use FFI? 2. Drop Python 2 entirely? 3. Make Python 3 the default (e.g. for waf)? Under any combination of those, I think the above commit is desirable. The closest we get to not needing it is if we want to entirely drop Python 2 support. In such a case, we would use `/usr/bin/env python3` by default. Even in that case, it is desirable to me to have it customizable, as the Debian package needs `/usr/bin/python3` (`env` is prohibited by Debian Python Policy). Granted, NTPsec upstream could just tell me to use sed, and that would work. So this isn't a clear _need_, but a nice-to-have _want_. One of the problems here is that we have a variety of interlocking issues. It would be nice to make some forward progress by pruning the decision tree. I'd like to merge at least that first commit now, even if there is more discussion needed on the second. The second commit is: Automatically detect the Python shebang The Python shebang is detected with the following priority: 1. If the user explicitly specifies --pyshebang, use that. 2. If the user explicitly specifies PYTHON or --python, use that. If it is not an absolute path, run under `/usr/bin/env`. 3. If the user ran waf under an explicit interpreter (e.g. `python3 waf` is a common idiom), use sys.executable, which is the interpreter's idea of its own name. (There is no way to get the original interpreter as typed, as sys.argv[0] is still "waf", not e.g. "python3".) 4. Use `/usr/bin/env python` as before. Examples: These use /usr/bin/env python: ./waf configure ./waf configure --python=python PYTHON=python ./waf configure These use /usr/bin/env python3: PYTHON=python3 ./waf configure ./waf configure --python=python3 PYTHON="/usr/bin/env python3" ./waf configure These use /usr/bin/python3: PYTHON=/usr/bin/python3 ./waf configure ./waf configure --python=/usr/bin/python3 This uses Python's sys.executable for python3 which might be /usr/bin/python3 or something else, depending on the system: python3 waf configure Fixes #667 waf (as in upstream waf, not the NTPsec configuration of it) has a stock option named --python. If users choose to use that, they can easily get nonsensical results. For example, prior to this commit, if they use `./waf configure --python=python3` they would still get a shebang of `/usr/bin/env python`; if `python` is Python 2 (as it is typically on Debian and RedHat systems), this breaks. That's dumb. Let's fix that by merging this commit. If we drop Python 2 support, a lot of the practical reason for this commit goes away. But in principle, I still think we should provide working results for people who use waf's --python option. Maybe they're using a custom Python in /usr/local or ~ or something. If we change the default from `/usr/bin/env python` to `/usr/bin/env python3` but _keep_ Python 2 support, this commit is still valuable because we have the same problem in reverse. That is, people who need Python 2 should be able to run e.g. `python waf configure` or `python2 waf configure` and get a working result. The third commit is: Document how to run waf without `python` Some distros no longer ship a `python`. Ubuntu 20.04 and CentOS 8 are examples. This is a simple doc fix that adds: If you are running on a distro with no `python` executable, you will need to run waf as `python3 waf` rather than `./waf`. That should not be controversial. It depends on the second commit, though. If we cannot merge the second commit, then we could say this instead: If you are running on a distro with no `python` executable, `./waf` will not work. Instead, use: python3 waf configure --pyshebang="/usr/bin/env python3" python3 waf build python3 waf install -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: FFI module architecture decision was 'Python support policy'
On 9/7/20 11:03 AM, James Browning via devel wrote: > I (re)developed a Python wrapper around a C FFI stub[1]. It is largely > based around my merge request !1010 [2]. I'll repeat from here, in case people want to respond to those points: https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1010#note_282670775 Is converting the existing "manual" extension to use ctypes desirable? I think the usual progression is the other way: you get a quick FFI hooked up using ctypes and then you eventually convert it to be a full "custom" module. This MR is a wash on code size. The ctypes module is likely slower, but that is almost certainly meaningless, since this is not performance sensitive code. Is one easier to maintain than the other? (I don't know.) > The FFI stub would allow for simplified development of non-Python > libraries. That would be an advantage. Do we realistically expect any consumers other than the in-tree tools, thought? This eliminates the compiled "ntp" module, right? That significantly improves the Python shebang situation. To repeat that here, simplified: With a compiled Python module, the scripts MUST run under the same Python X.Y that the module was compiled against, because compiled-module ABI compatibility is only guaranteed within a minor version, not across minor or major versions; see PEP 3149. But if the "ntp" module itself is only Python, then that relaxes the constraint to Python source compatibility. Can you re-open !1010 or open a new MR with this? I've updated !1166 (Subst installed Python shebangs) to assume this FFI change is merged before or will be merged soon after. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Runtime testing, What's the CI environment like?
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. I posted a couple patches, which were merged; see `git log 9a85f93a` FWIW, I don't build that refclock in the Debian package. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
On 9/5/20 5:39 PM, Gary E. Miller via devel wrote: > It would be nice if you answered my objections Your primary concern seems to be that users will complain. Let me take smaller bites at that: RHEL 7 has Python 2.7.5 and Python 3.6.8. User "complains". We say, "run `yum install python3`". Is this acceptable? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
On 9/5/20 2:19 PM, Gary E. Miller via devel wrote: > And yet, Gentoo, and others still ship 2.7. And end users still use it. This is not a discussion about whether Gentoo should drop Python 2.7. It's not a discussion about whether users should stop using Python 2 entirely. Perhaps we can intuit each other's views on those topics, but that's not what is being discussed here. NTPsec currently supports: Python 2 >= 2.6 or Python 3 >= 3.3 There are four possible sets: A) !(Python 2 >= 2.6) and !(Python 3 >= 3.3). That is, it has neither version of Python at all or neither meets the minimum version. B) (Python 2 >= 2.6) and !(Python 3 >= 3.3). That is, either it has no Python 3 or its Python 3 is < 3.3. C) (Python 2 >= 2.6) and Python 3 >= 3.3. That is, it has both Python 2 and Python 3 in versions that meet NTPsec's minimums. D) !(Python 2 >= 2.6) and Python 3 >= 3.3. That is, it has an acceptable Python 3, but no acceptable Python 2. Category A is irrelevant, as NTPsec already does not run there. Category B is the relevant case to the main purpose of this thread: the proposal to drop Python 2 support. If a system is in category B because that particular system doesn't have Python 3 installed, but the distro ships Python 3 >= 3.3, the solution is simple: install Python 3. That doesn't change anything with their Python 2 environment. If the user has critical Python 2 code, it stays working just as it was. If a system is in category B because the distro does not ship Python 3 >= 3.3, then Eric's proposal to drop Python 2 support means dropping support for that distro. An example of that is RHEL 6. Because RedHat's support lifecycles are generally longer than other distros' support lifecycles, it is likely that RHEL 6 is the last example of such a distro. RHEL 6's security support ends in November. Once that happens, the affected population are users who both want to run the latest NTPsec and are running a distro version that is no longer receiving security updates. Why is that a scenario that NTPsec needs to support? Doubly so given NTPsec's otherwise aggressive stance on removing old stuff in the name of maintainability and security? Last year, the current release of essentially every distro was likely in category C. Users could use NTPsec with either Python 2 or Python 3 (but only whichever version was providing `python`; see below). Now that Python 2 has been end-of-lifed upstream, category D is likely to expand. In this category, users must use NTPsec with Python 3. Unfortunately, building/using NTPsec on a Python 3-only system without a `python` symlink to Python 3 (e.g. Ubuntu 20.04) currently does not work at all. The minor problem is that waf has a `python` shebang. If the distro does not ship `python` (as is the case on Ubuntu 20.04 out of the box), then `./waf` will not run. Whether a Python 3-only system should symlink `python` to `python3` is debatable. Both options have pros and cons. In the case of Ubuntu, one option is the default (no `python`) and the other is available by admin choice (by installing the python-is-python3 package). The lack of `python` can be trivially worked around with `python3 waf` if the user knows to do so. (We should update the INSTALL docs with a note on that once the bigger problem is resolved.) The bigger problem is that the installed scripts have a hardcoded shebang of `/usr/bin/env python` so none of them work. That can be addressed by subst'ing the shebangs as in !1166: https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1166 -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
On 9/4/20 1:37 AM, Hal Murray via devel wrote: > Another question... How many systems are we interested in that have Python2, > don't have Python3, and have a version of OpenSSL that is too old for NTS? The OpenSSL requirement* (>= 1.1.1b) requires a lot newer distro versions than the Python 3 requirement (>= 3.3). OpenSSL 1.1.1b was released on 2019-02-26: https://mta.openssl.org/pipermail/openssl-announce/2019-February/000147.html Python 3.3.0 was released on 2012-09-29: https://www.python.org/downloads/release/python-330/ On Debian, for example, Jessie / 8 / oldoldoldstable has Python 3.4, but you need Buster / 10 / stable to get OpenSSL 1.1.1. * It's not a firm requirement, since we can still build on old OpenSSL with --disable-nts AFAIK. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
[Reposting to list.] On 9/3/20 11:15 PM, Gary E. Miller via devel wrote: > The case you left out: > > # select 2.7 > spidey ~ # python3 --version > Python 3.8.5 > > Uh, oh. That is why we do not do that. No, that is exactly as intended. The context here is that we want to require Python 3. I understand you disagree on whether we should require Python 3, but if we do, then this shebang works fine. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
On 9/4/20 12:16 AM, Gary E. Miller via devel wrote: > On Thu, 3 Sep 2020 23:28:33 -0500 > Richard Laager via devel wrote: > >> NTPsec can require Python >> 3 as long as all distros that NTPsec supports can install Python 3. > > Yup. Let us know when that happens. Gonna be years from now. Per INSTALL.adoc, NTPsec (when using Python 3) requires Python 3.3. This was released Sept 29, 2012. Can you give some examples of distro versions (that NTPsec otherwise supports) that do not ship Python 3.3 or newer? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
On 9/3/20 12:39 PM, Gary E. Miller via devel wrote: >> There may be other reasons to keep Python 2 support, but as Richard >> says RHEL 6 will stop being one of them before our next point release >> after this one. > > And then how long for users to update? Two years? Three years? The point of published lifecycles is so people can plan appropriately. The end of security support should be the end of the migration, not the start of it. Now, I do understand that people get caught in bad situations for various reasons, and I have a couple of those. But that doesn't mean it would be reasonable for me to expect the latest software to still work in that environment. In such cases, you freeze things in time, mitigate security risks as best you can, and try to work you way out of the bad situation. > Gentoo thought that. But they do not any more. Just the Gentoo work so > far has been a massive headache for Gentoo, and the TODO list is still > very long. Too many things, like Kodi, that still need Python 2. Large > amounts of critical infrastructure are still ython 2 only. That is an argument about a different issue: whether distros/upstream Python should stop supporting Python 2. We are talking about whether NTPsec should continue to support Python 2. NTPsec can require Python 3 as long as all distros that NTPsec supports can install Python 3. For example, if someone is using RHEL 7 and needs Python 2 for mission critical code, that has no impact on NTPsec's decision. NTPsec can require Python 3 and such a user can still use the latest NTPsec on RHEL 7, because Python 2 and Python 3 are co-installable. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
On 9/3/20 1:12 PM, Gary E. Miller via devel wrote: > On Thu, 3 Sep 2020 02:30:43 -0500 > Richard Laager via devel wrote: > >> On 9/2/20 7:44 PM, Gary E. Miller via devel wrote: >>>> 1. Change waf's shebang: >>>> -#!/usr/bin/env python >>>> +#!/usr/bin/env python3 >>> >>> Uh, no. That breaks Gentoo eselect. >> >> How, specifically? > > Bentoo allows the user to select his current Python, at runtime. Trivially > select his current Python. This is great, sometimes I run 7 Python versions > and flip between them quickly for testing. Can you show me how that works? 1. Select (with eselect) Python 3.8 and run: python3 --version 2. Select Python 3.7 and run: python3 --version -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
On 9/2/20 7:44 PM, Gary E. Miller via devel wrote: >> 1. Change waf's shebang: >> -#!/usr/bin/env python >> +#!/usr/bin/env python3 > > Uh, no. That breaks Gentoo eselect. How, specifically? What do these give on your system? python3 --version ls -l /usr/bin/python3 For comparison, here is a second user's report that `python3` works in Gentoo: "python3 --version reports python 3.8.5 for me in gentoo. /usr/bin/python3 -> python-exec2c" > Many other distros prefer not either. "prefer" sounds like you're talking about distro policies. The question here is: does it work? Can you cite an example of a distro where installing Python 3 from the distro does not result in a python3 in the PATH? >> A. Change the Python shebangs to: >>#!@PYTHON@ > > You realize that the POSIX doc says a pace after "#!", but so many do it > wrong they accept that variant. In NTPsec, there are 122 the wrong way and 81 the right way. As you say, either works. I don't particularly care about the space personally, but we can use the space if you want to be pedantically correct. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
On 9/2/20 7:54 PM, Gary E. Miller via devel wrote: > A big one: RHEL. As I said earlier, any time Python 2 breaks in gpsd > it only takes a day or two for complaints. I have customers that will > be on RHEL for years to come. They need NTPsec. RHEL 6 support (measured in terms of security updates) ends in November of this year. So by the time a version of NTPsec releases without Python 2 support, we'd be looking at RHEL 7. I can't seem to access this, even with my free RedHat subscription: https://access.redhat.com/solutions/2353081 But my CentOS 7 system has: $ cat /etc/redhat-release ; python3 --version CentOS Linux release 7.8.2003 (Core) Python 3.6.8 So, RHEL seems fine. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
Let me start over now that I've reviewed the specifics of the NTPsec scripts and build system again: We are currently using "#!/usr/bin/env python" in all the scripts, and waf uses the same. The minimum to do to drop Python 2 is: 1. Change waf's shebang: -#!/usr/bin/env python +#!/usr/bin/env python3 That way, on systems where python is Python 2, waf will get Python 3. While there is a lot of baggage around whether "python" is Python 2, Python 3, or neither (i.e. doesn't exist), python3 existing is pretty universal. [Discussion 1] 2. Change the other scripts the same way. 3. Update the docs and CI accordingly. An additional improvement (which we could do separately from the Python 2 vs Python 3 discussion) would be to allow the user to customize the shebang with a build flag. It turns out we already have `./waf configure --python` which defaults to sys.executable. This is stock waf behavior. We are already running the Python scripts through subst. We just aren't doing the last piece of using @PYTHON@ as the shebang. So we could either: A. Change the Python shebangs to: #!@PYTHON@ I just tested that on one and it works as expected. B. Leave them as "/usr/bin/env python3" and write a custom subst function to replace that (and do the usual subst). Option A is trivial. I could have that patch done in 10 minutes. Option B is a little bit more work, but keeps the scripts directly executable from the source tree, which could be helpful for development. (The other substitutions aren't typically critical, as they are things like @NTPSEC_VERSION_EXTENDED@.) Is this something people care about? Discussion 1: Python 3 is "supposed" to be available via an executable or symlink named "python3". That's supported in black and white by PEP 394, which says: "We expect Unix-like software distributions...to install the python2 command into the default path whenever a version of the Python 2 interpreter is installed, and the same for python3 and the Python 3 interpreter." "When invoked, python2 should run some version of the Python 2 interpreter, and python3 should run some version of the Python 3 interpreter." What is "supposed" to be the case is mostly moot anyway, so I'm not going to argue about this further. What matters is the real world. Python 3 is, in practice, actually available via an executable or symlink named "python3". python3 exists on Debian and derivatives as well as RedHat and derivatives. Ubuntu 20.04 optionally allows python to point to python3, but always still has python3. I use Debian, Ubuntu, and RedHat, so I have personal knowledge here. Some examples: Debian 10 (current stable): $ ls -la `which python3` lrwxrwxrwx 1 root root 9 Mar 26 2019 /usr/bin/python3 -> python3.7 Debian unstable: $ ls -la `which python3` lrwxrwxrwx 1 root root 9 Apr 7 05:43 /usr/bin/python3 -> python3.8 Ubuntu 18.04 (previous LTS): $ ls -la `which python3` lrwxrwxrwx 1 root root 9 Oct 25 2018 /usr/bin/python3 -> python3.6 Ubuntu 20.04 (current release): $ ls -la `which python3` lrwxrwxrwx 1 root root 9 Mar 13 07:20 /usr/bin/python3 -> python3.8 CentOS 7: $ ls -la `which python3` lrwxrwxrwx. 1 root root 9 Sep 2 17:20 /usr/bin/python3 -> python3.6 Arch's python is python3, but also still has python3: https://www.archlinux.org/packages/extra/x86_64/python/ OpenSUSE uses python3. Here is some random guy showing it: https://youtu.be/T08_SO0YAjA?t=57 I checked with a Gentoo user I know and they confirmed that their system also has a "python3". Note carefully that I am not talking about what shebang distro policy says should be used for distro packages of NTPsec. Distro packages can, should, and are likely required to change the shebang from a general one like "/usr/bin/env python3" to something specific to the distro environment. Debian says to do this: https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-interpreter_loc Gentoo says to do this: https://dev.gentoo.org/~mgorny/python-guide/helper.html#fixing-shebangs-on-installed-scripts -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: I'm giving up on seccomp
On 9/2/20 2:30 PM, Hal Murray wrote:
>> I do ship an AppArmor profile.
>
> Thanks. That's the word I was fishing for.
>
> I've never worked with it. Is there a good introductory writeup?
There is various documentation, but I don't have anything off the top of
my head to direct you to.
> Are their similar facilities available on other OSes/distros?
AppArmor is a cross-distro thing. The "other option" would be SELinux.
Ubuntu uses AppArmor by default. I can't remember if Debian has it
enabled by default now or not; it's been a while since I checked / did a
fresh install. SUSE uses AppArmor too, from what I understand; they
started the ntpd profile (which Canonical modified for Ubuntu). RedHat
(RHEL and by extension CentOS, not sure about Fedora) uses SELinux.
I've attached the profile that I ship in the Debian package.
apparmor-profile => /etc/apparmor.d/usr.sbin.ntpd
apparmor-profile.tunable => /etc/apparmor.d/tunables/ntpd
(empty file) => /etc/apparmor.d/local/usr.sbin.ntpd
--
Richard
# vim:syntax=apparmor
# Updated for Ubuntu by: Jamie Strandboge
# --
#
#Copyright (C) 2002-2005 Novell/SUSE
#Copyright (C) 2009-2012 Canonical Ltd.
#
#This program is free software; you can redistribute it and/or
#modify it under the terms of version 2 of the GNU General Public
#License published by the Free Software Foundation.
#
# --
#include
#include
/usr/sbin/ntpd flags=(attach_disconnected) {
#include
#include
#include
capability ipc_lock,
capability net_admin,
capability net_bind_service,
capability setgid,
capability setuid,
capability sys_chroot,
capability sys_resource,
capability sys_time,
capability sys_nice,
# ntp uses AF_INET, AF_INET6 and AF_UNSPEC
network dgram,
network stream,
@{PROC}/net/if_inet6 r,
@{PROC}/*/net/if_inet6 r,
@{NTPD_DEVICE} rw,
# pps devices are almost exclusively used with NTP
/dev/pps[0-9]* rw,
/{,s}bin/ r,
/usr/{,s}bin/ r,
/usr/local/{,s}bin/ r,
/usr/sbin/ntpd rmix,
/etc/ntpsec/ntp.conf r,
/etc/ntpsec/ntp.d/ r,
/etc/ntpsec/ntp.d/*.conf r,
/run/ntpsec/ntp.conf.dhcp r,
/etc/ntp.keys r,
/var/lib/ntpsec/ntp.drift rw,
/var/lib/ntpsec/ntp.drift-tmp rw,
/usr/share/zoneinfo/leap-seconds.list rw,
/var/log/ntp w,
/var/log/ntp.log w,
/var/log/ntpd w,
/var/log/ntpsec/clockstats* rwl,
/var/log/ntpsec/loopstats* rwl,
/var/log/ntpsec/peerstats* rwl,
/var/log/ntpsec/protostats* rwl,
/var/log/ntpsec/rawstats* rwl,
/var/log/ntpsec/sysstats* rwl,
/{,var/}run/ntpd.pid w,
# to be able to check for running ntpdate
/run/lock/ntpsec-ntpdate wk,
# samba4 ntp signing socket
/{,var/}run/samba/ntp_signd/socket rw,
# samba4 winbindd pipe
/run/samba/winbindd/pipe rw,
# For use with clocks that report via shared memory (e.g. gpsd),
# you may need to give ntpd access to all of shared memory, though
# this can be considered dangerous. See https://launchpad.net/bugs/722815
# for details. To enable, add this to local/usr.sbin.ntpd:
# capability ipc_owner,
# Site-specific additions and overrides. See local/README for details.
#include
}
# vim:syntax=apparmor
# --
#
#Copyright (C) 2002-2005 Novell/SUSE
#Copyright (C) 2011 Canonical, Ltd.
#
#This program is free software; you can redistribute it and/or
#modify it under the terms of version 2 of the GNU General Public
#License published by the Free Software Foundation.
#
# --
#Add your ntpd devices here eg. if you have a DCF clock
# @{NTPD_DEVICE}="/dev/ttyS1"
@{NTPD_DEVICE}="/dev/null"
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Python support policy
On 9/2/20 12:47 PM, Gary E. Miller via devel wrote: > Yo Eric! > > On Wed, 2 Sep 2020 08:07:53 -0400 (EDT) > "Eric S. Raymond via devel" wrote: > >> Retaining support for Python 2 proliferates test paths and >> complicates the fix for at least one outstanding bug. > > Python 2 will be with us for years more. Any time gpsd changes > in a way that breaks Python 2 it is reported in a day. > >> Proposed: We should drop support for Python 2 and use a python3 >> shebang in all our scripts. Yes, please. > And which "python3 shebang" would you suggest? Last gpsd release > uncovered that still no distros agree on that. gpsd gave up and made the > python shebang a build option. I think it was "supposed" to be /usr/bin/python3. But things have changed a bit and /usr/bin/python may or may not be Python 3. (Then there's the usual shebang questions about the directory.) The most likely to work is probably this: #!/usr/bin/env python3 But yeah, I would make it a build option. waf presumably knows where Python is, since it is running in Python. I would use this for waf: #!/usr/bin/env python3 instead of its current: #!/usr/bin/env python That should give you the best chance of waf working out of the box. And if it doesn't, then the user only needs to special case the waf invocation(s), but the built NTPsec will have the right shebang for their distro. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: I'm giving up on seccomp
On 9/1/20 10:27 PM, Hal Murray via devel wrote: > What's the word for what Debian does? In the package: no seccomp. I really don't see the advantage in seccomp; it seems like a lot more trouble than it is worth. I do ship an AppArmor profile. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Locating NTS-KE and NTP servers
On 8/15/20 4:59 AM, Hal Murray via devel wrote: > Let's start with the simple case - no NTS. There are a few NTP servers with > names > that return multiple IP Addresses. I'd like to be able to test all of those > too. Fortunately, we can do that by specifying their individual numerical IP > Addresses. > > But a cleaner approach almost works. If foo has several addresses, it should > be reasonable to say > server foo > server foo I'm not 100% certain I follow what you are trying to do, but... could you just use "pool foo"? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: [secur...@ntpsec.org] Bug#964395: Does CVE-2020-13817 affect ntpsec?
On 8/13/20 5:48 AM, Hal Murray via devel wrote: >>> https://bugs.ntp.org/show_bug.cgi?id=3596 > > That bug talks about feeding bogus time to a system by guessing the transmit > time stamp. > > When ntpd gets a response, it drops responses where the time-stamp it sent > doesn't match the corresponding slot in the reply. The idea is that most of > the bits in that slot are predictable so an off path attacker has a good > chance of getting a bogus response through by guessing the value the server > is > expecting. > > There is a draft in the pipeline: > https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-04 > We implement that. There is also this (which you forwarded to this list) which might help: https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/ What's the status of that in NTPsec? I presume "not implemented", but is it planned? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntp in /etc/services
On 8/12/20 4:44 AM, Hal Murray via devel wrote: >> Is that a bug, or should I remove that chunk of text? > > That doesn't seem very clear. Let me try again. > > The documentation mentions /etc/services > The current code doesn't use it. It passes "123" rather than "ntp" to the > DNS > lookup routines. > > How should we fix that? > 1) fix documentation (easy, remove 2 lines) > 2) change code to use /etc/services #1 please. There's no need to use /etc/services and that's not a common thing for daemons these days to require. With my Debian packager hat on, getting a port in Debian's /etc/services is another level of complication that I don't want to have to deal with. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: [secur...@ntpsec.org] Bug#964395: Does CVE-2020-13817 affect ntpsec?
I don't think I ever got an answer on this one. On 7/6/20 11:28 PM, Richard Laager via security wrote: > Another NTP CVE (which is already public)... does this affect NTPsec? > > On 7/6/20 12:55 PM, Moritz Muehlenhoff wrote: >> This was assigned CVE-2020-13817 for ntp.org: >> http://support.ntp.org/bin/view/Main/NtpBug3596 >> https://bugs.ntp.org/show_bug.cgi?id=3596 >> http://bk.ntp.org/ntp-stable/?PAGE=patch&REV=5e312021VVVkyioYBR_aeIP1LqMCVg >> http://bk.ntp.org/ntp-stable/?PAGE=patch&REV=5e4a536dzxRWAzMw-KsKjm04l6joNA -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpd Certificate Loading
On 6/9/20 3:20 AM, Mike Simpson via devel wrote:
> As you only get a 90 day very from LE I now have a cron job after the
> “certbot renew” which copies the keys over and chown them. It feels clunky.
Use a deploy hook. I wrote the attached one for Debian. Note that Debian
uses user "ntpsec" and group "ntpsec". Change that to "ntp" and "ntp"
for other environments.
Install the script (marking it executable) as:
/etc/letsencrypt/renewal-hooks/deploy/ntpsec
Then set NTPSEC_CERTBOT_CERT_NAME="your.cert.hostname" in
/etc/default/ntpsec (or edit the script).
--
Richard
#!/bin/sh -eu
# vim: ai ts=4 sts=4 et sw=4
if [ -r /etc/default/ntpsec ]
then
. /etc/default/ntpsec
fi
if [ -z "${NTPSEC_CERTBOT_CERT_NAME-}" ]
then
exit 0
fi
# If the certificate being deployed is not the one for ntpd, exit.
found=0
for domain in "$RENEWED_DOMAINS"
do
if [ "$domain" = "$NTPSEC_CERTBOT_CERT_NAME" ]
then
found=1
fi
done
if [ "$found" = "0" ]
then
exit 0
fi
# Copy the certificate (including chain) and key to ntpd can read them
# after dropping privileges.
install -m 644 /etc/letsencrypt/live/"$NTPSEC_CERTBOT_CERT_NAME"/fullchain.pem \
/etc/ntpsec/cert-chain.pem
install -m 640 -g ntpsec \
/etc/letsencrypt/live/"$NTPSEC_CERTBOT_CERT_NAME"/privkey.pem \
/etc/ntpsec/key.pem
# Tell ntpd to reload the certificate and key.
killall -HUP ntpd 2>/dev/null || true
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Copyright years in source code
On 5/8/20 1:10 PM, Gary E. Miller via devel wrote: > I think the year of first publication still has some use as it disambiguates > which version of copyright law applies. The "year of first publication" applies per copyrightable thing, so if the file has multiple changes, you'd need multiple years. For example, imagine you had a book written in 1900 with changes made in 2000. If you say "Copyright 1900", it looks like it is now public domain, but it's not. This is more-or-less the reason for years in copyright statements. Essentially all computer code is in the modern era of copyright. The copyright terms are all so long now that you can basically assume that code is copyrighted for as long as it remains relevant to use. And for an actively maintained project, something is changing every year, so the project _as a whole_ would always be under the current copyright regime anyway even if the terms were shorter. So the years have essentially no practical value; you can just assume it is "copyright this year". If terms were shorter _and_ someone wanted to pick out portions of the code for reuse elsewhere once the term ended _and_ the copyright statements were perfectly maintained, they might in theory be able to do so. But even if the copyright statements were perfectly maintained, you'd still have the issue that routine refactoring, churn, and cleanup work would mean that most files would have a recent copyright (if not the current year), so you'd still have to hit the VCS to determine the history on the code you want to reuse (e.g. some core algorithm). So even in that scenario, the years don't seem to help. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Heads up: incompatible NTS change, Monday midnight, UTC
On 4/20/20 3:22 AM, Hal Murray via devel wrote: > > One of the last changes to the draft NTS RFC was to change the string > constant > used to make the keys that are used to encrypt and authenticate the NTP+NTS > traffic. > > There isn't any easy way to make a backwards compatible update. > > The symptoms of incompatible versions are that the NTS-KE step will appear to > work but the client and server will be using different keys so the NTP+NTS > traffic won't work. The client will use up all 8 cookies then start over > with > another NTS-KE step. > > Old cookies will continue to work until you restart the client and it gets > new > cookies. I expect to be able to restart the server with nothing worse than > dropping a packet or two. > > The Cloudflare servers were updated a while ago. (This is why they aren't > working if you are using NTS.) > > Miroslav Lichvar (chrony) and I are planning to ship updated code and restart > servers roughly Monday midnight, UTC. (Late afternoon, Pacific time.) I'll > send another message when I've pushed the button. By Monday, do you mean today (in which case midnight UTC has passed but maybe you mean what is technically Tuesday 00:00) or a week from now? Is the patch available now? If so, can you share it? Is there a particular reason that the code push (as opposed to operational deployment) needs to be super tightly coordinated? If not, can you just push it now? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
ntpd Certificate Loading
ntpd seems to load the TLS certificate and key before dropping privileges. Unfortunately, when it tries to *reload* the certificate later, it has dropped privileges and fails. This is a bit of a trap, as a sysadmin can think a setup is working when it isn't. (This bit me.) I think it would be better to do the initial load after dropping privileges so that it is consistent with reloading. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: CI broken - lots of stages with old OpenSSL
On 3/26/20 4:13 PM, Richard Laager via devel wrote: > On 3/26/20 3:35 PM, Hal Murray via devel wrote: >> Would somebody please fix and/or teach me how to do it. >> >> https://gitlab.com/NTPsec/ntpsec/pipelines/130148924 >> had 11 failed builds. > > You've raised the OpenSSL requirement to > 1.1.1a. Assuming OpenSSL is > mandatory to build NTPsec, then you've dropped support for Debian > oldstable, Ubuntu 18.04, and others as you noted. Also, this bit in INSTALL.adoc needs updating: We need OpenSSL >= 1.0.1 NTS needs TLS1.2 or newer. Since CentOS 6 does not have this, you've dropped support for that too, so the two CentOS 6 mentions in INSTALL.adoc can be removed. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: CI broken - lots of stages with old OpenSSL
On 3/26/20 3:35 PM, Hal Murray via devel wrote: > Would somebody please fix and/or teach me how to do it. > > https://gitlab.com/NTPsec/ntpsec/pipelines/130148924 > had 11 failed builds. You've raised the OpenSSL requirement to > 1.1.1a. Assuming OpenSSL is mandatory to build NTPsec, then you've dropped support for Debian oldstable, Ubuntu 18.04, and others as you noted. Edit .gitlab-ci.yml and remove the debian-oldstable-* jobs. For Ubuntu, you can either remove or comment out ubuntu-latest (in a few days, when 20.04 is released, "ubuntu:latest" should mean 20.04 instead of 18.04). Repeat for .gitlab-opttest-ci.yml. > Name: openSUSE-leap-refclocks > ... > Checking for OpenSSL > 1.1.1a : no > The configuration failed > > Name: openSUSE-leap-basic > ... > > Name: ubuntu-latest-refclocks > That must be an old Ubuntu. From the observed results, I believe latest means latest LTS. > Name: macos-refclocks > Name: macos-basic > ... I don't know what to do with this. > Name: freebsd-11-basic > Name: freebsd-11-refclocks > FreeBSD 11.3 has 1.0.2s > FreeBSD 12 works. Presumably, you would remove FreeBSD 11. > Name: cross-build > I have no idea what that is running. The logs say Ubuntu 16.04. It's not clear to me how that happens, as that job has no "image:" parameter. Maybe 16.04 is GitLab's default or something. I have no idea. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTS dropping TLS 1.2
On 3/23/20 5:43 AM, Eric S. Raymond via devel wrote: > Hal Murray : >> We can do several things: >> 1) clean out the ifdefs that make things work with older versions of >> OpenSSL. >> That is drop support for systems that haven't upgraded their OpenSSL to >> a >> supported version. >> 2) leave things alone, ignore the RFC. >> Or maybe add some nasty warning messages >> How long? >> 3) make a configure option to disable NTS so that NTPsec builds on older >> OSes but doesn't support NTS. >> >> I propose option 1. Simple and clean. I don't think we will drop many >> systems. > > I concur. +1. In the Debian package, I was recommending a minimum of TLS 1.3 anyway, since NTS was by definition greenfield (and CloudFlare was doing the same thing). The export string change is annoying, but that's a risk we all take when running a draft protocol. I guess we'll just eat that in a flag day. It would be nice if that would be the same flag day for switching to the IANA-allocated port (whenever that happens, assuming it isn't 123/tcp), but we probably won't be that lucky. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: seccomp tangle
On 2/23/20 4:59 AM, Hal Murray via devel wrote: > Should we drop secomp? It's a pain to maintain. I wouldn't cry. > How many people use it? Richard: do you turn it on for the Debian builds? I do not. It seems really fragile to me. A change in an underlying library can break a working binary, possibly only in some scenarios. That's scary. It'd be safer (but still not completely safe) to enable if I had good (or any) "as installed" tests using Debian's autopkgtest, but I do not. I'm open to enabling it, but it's also unclear how much benefit it provides. What is it protecting the user from? How much value does it add if I'm already using AppArmor? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: droproot, seccomp
On 2/24/20 11:02 PM, Hal Murray via devel wrote: > I'm looking at strace output. There are a few calls used only once or twice. > > It seems obvious that we should drop root as early as possible. But it's not > obvious that we should enable seccomp early. > > If we turn on seccomp early, then we have to allow all the syscalls used > during initialization so a bad guy could use them too. > > So what are we worried about? What is seccomp trying to protect against? > Bugs in our initialization code before we start exchanging packets, or bugs > in > the mainline code after initialization when the bad guys get to send us > packets? I'd say the latter. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Is there a clean way for waf to test for the distro?
On 2/22/20 6:15 PM, Hal Murray via devel wrote: > Context is the seccomp tangle. Issue #633 > > Should I just add a helper that looks in /etc/os-release? Are you really, absolutely, positively sure that you can't check for the feature itself directly. If you start going down the distro-checking path, things get very messy, very fast. For example, is "Linux Mint" like Ubuntu? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: ntpsec | Add dextral mode and srchost variable use options and better column autowidth. (!1033)
On 2/22/20 8:57 PM, James Browning via devel wrote:
>> Looks like the second test is backwards. It's printing the message on a
>> system where pipefail works.
>>
>> if (set -o pipefail) 2>/dev/null
>> then
>> echo "### Old sh - no pipefail"
>> echo "### We can't test for errors during build"
>> echo "### You will have to scan the log files."
>> PURGE="${PURGE} pipefail"
>> fi
> I am reasonably sure that is happening because I rewrote that test. It
> should probably replace the first line with.
>
> (set -o pipefail) 2>/dev/null
> if [[ $? -ne 0 ]]
>
> or something roughly equivalent to test the exit code not the contents
> from stdout.
It is checking the exit status. () is a subshell. $() captures stdout.
It just needs this, which I just did:
-if (set -o pipefail) 2>/dev/null
+if ! (set -o pipefail) 2>/dev/null
Sorry I missed this in the review.
--
Richard
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Copyright Statement Years
https://blog.ntpsec.org/2020/02/15/copyright-year.html "There is no need to include the year in a copyright declaration statement. And related, there is no need to update the year statement, add new year statements, manage year range statements, or any of that stuff. It is tedious, boring, adds no value, and prevents no risks. "Several large legally sophisticated companies, include Amazon, Google, Microsoft, and Facebook, are now publishing open source code with copyright statements without a year." Can you cite some examples of those large companies publishing open source code without a year? Do you have any legal analysis on this you can share, publicly or privately? I'm asking for three reasons: 1) My own curiosity 2) Wearing my Debian packager hat, in case this comes up with Debian when I bring in the next NTPsec release with all the years scrubbed and update debian/copyright to match. 3) Because I'd like to convince others of this point, so I can stop having to maintain copyright statements all over the place. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Possible cruft cleanup: clock_gettime vs getitimer
On 2/17/20 1:34 PM, Gary E. Miller via devel wrote: > But, when I tried to build with git head, I now get this error: > > Waf: Leaving directory `/usr/local/src/NTP/ntpsec/build/main' > Fatal Python error: PyThreadState_Get: no current thread > ../Do-config-ntpsec: line 11: 13733 Abort trap: 6 ./waf build That looks like a Python crash while running waf code, which is really weird. Googling that error message does show some results for macOS, but nothing particularly illuminating. Is that related to any changes in NTPsec? Can you build with the NTPsec_1_1_8 tag? If that works, can you bisect down where it broke? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: --enable-doc waf config option removed
We discussed this in #ntpsec. For context, I wasn't the original MR author, but I was very involved in review of the MR, approved it, and ultimately merged it. My understanding is that there are two objections here: 1) Changing the default was mixed in with other changes. 2) It is undesirable to require changes to existing build scripts (e.g. in distro packages). Specifically for this change, that would be those which: A) use --enable-doc, or B) don't have asciidoc and don't use --disable-manapage I'm confident that a solution is close at hand. Skip to the MR link below if you like. My thoughts on the first point: "I agree ... in general that things should be separated out. But in practice, these things were relatively interlinked. It's not that it couldn't be separated out, but it would have been more work. JamesB192 put a lot of work into this already, and it was barely getting the attention it needed. I certainly didn't want to force him to split it up given that nobody seemed to care about the policy change. "In the future, I can certainly put more weight on the side of splitting things up." On the second point: I didn't see this as a big problem, and *I* am a distro packager, but I certainly have no problem taking steps to address it. I initially suggested that we accept --enable-doc as a no-op for backwards compatibility. I also suggested an alternative of accepting both --enable-* and --disable-*. Eric seemed happy with either. After further investigation, I ultimately implemented the latter: https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1095 This gives us almost all of the advantages of both the before and after states. The only thing we miss out on is that if you don't have asciidoc(tor), you will not get the docs / man pages. This was the behavior before and is either a feature or a bug, depending on your point-of-view. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: --enable-doc waf config option removed
On 2/2/20 6:25 PM, James Browning via devel wrote: > On Sun, Feb 2, 2020, at 3:49 PM Gary E. Miller via devel > wrote: >> >> Yo Jason! >> >> On Sun, 02 Feb 2020 16:44:25 -0500 >> Jason Azze via devel wrote: >> >>> It looks like the --enable-doc waf configuration option was removed >>> in the commit "Add support for other asciidoc processors". Was there >>> any discussion about this change? >> >> Not that I saw. I'm for bringing it back. If "it" is the --enable-doc option, there is still an option. As discussed on the list (see "Building Docs by Default" starting December 30), only the default has changed. Docs are now built by default, which changes the name of the option. If you were using --enable-doc, you can just omit that when calling "waf configure". If you were NOT using --enable-doc, then add --disable-doc. If "it" refers to asciidoc, it is still supported and detected by "waf configure" as before: >> Asciidoctor pulls in >> ruby, and ruby mutates so quickly that I find it often broken. > > Unless someone changed it, Asciidoc still works. Rated as a second > fiddle though. As well as Asciidoc-py3 (second in line to replace > Asciidoc) and Asciidoc3 which has a seat at the foot of the table. All three work. I (of course) didn't change this when merging your MR. > It would appear that I do not have enough experience with ruby > to form a properly negative opinion yet. The Debian package of asciidoctor has been stable for me. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: --enable-doc waf config option removed
On 2/2/20 3:44 PM, Jason Azze via devel wrote: > It looks like the --enable-doc waf configuration option was removed in the > commit "Add support for other asciidoc processors". Was there any discussion > about this change? Yes. See the mailing list archive and MR !1037. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Building Docs by Default
MR !1037 [1], by James Browning, "significantly revises the document
build system. It adds the ability to use asciidoctor, asciidoc3, and
odd-numbered versions like asciidoc-py3 9.0.0rc1. It also changes the
build system to fail hard, unless there is a working AsciiDoc toolchain,
or both --disable-doc and --disable-man are specified when configuring."
In other words:
1) It builds docs by default, which matches the current behavior of
building man pages by default.
2) If you are missing an asciidoc processor, it fails hard instead of
silently not building (docs and) man pages.
Item #1 was inspired by Matt Selsky's comments, "we should get our story
straight on building docs vs man pages. Do we really need separate knobs
for that? And can we get the enable/disable by default to be consistent?
Perhaps even at the expense of having them not be consistent with the
previous release?"
Do the two changes above seem okay?
Should we also merge these into one flag (i.e. drop --disable-manpage
and keep --disable-doc)?
If we're building docs by default, should the (non-minimal) CI
("pipeline") builders build docs?
[1] https://gitlab.com/NTPsec/ntpsec/merge_requests/1037
--
Richard
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: [OT] Splitting PPS?
Upon further investigation, there is a concern about the GPS antenna placement. Does anyone have recommendations for GPS antenna RF-to-fiber converters or other ways to have the GPS antenna a long way (in a building) from the GPS receiver? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Website Broken Link
https://www.ntpsec.org/contributor.html links to hacking.txt (and mentions that inline), which is now hacking.adoc. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: [PATCH] ALPN validation fix
Hal, It looks like you broke building on macOS: https://gitlab.com/NTPsec/ntpsec/commit/22c134c8b20e9a897fc5521df871606167067b2e that links to the pipeline here: https://gitlab.com/NTPsec/ntpsec/pipelines/101491292 which links to these failed jobs: https://gitlab.com/NTPsec/ntpsec/-/jobs/372779264 https://gitlab.com/NTPsec/ntpsec/-/jobs/372779265 Also, if you submit changes as merge requests, the pipelines are run first. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: [PATCH] ALPN validation fix
On 12/9/19 2:56 AM, Hal Murray via devel wrote: > Is there any reason to support anything older than TLS 1.2? No. The NTS standard requires TLS 1.2 as a minimum (since NTS is a new protocol, there is no need for backwards compatibility with old TLS). -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: fuzz fix?
On 12/5/19 8:33 AM, Hal Murray via devel wrote:
> Last night Richard Laager sent me some IRC stuff indicating that the fuzz
> mess
> was due to NTS threads calling get_systime() which isn't thread safe. In
> hindsight, I should have seen that sooner.
>
> I just pushed a fix. Please test.
I first upgraded the system to 1.1.8. The problem still occurred on
1.1.8, as expected. Then I applied this patch (and the recent logging
changes too so that it would apply cleanly). The problem no longer occurs!
I've backported this fix into the Debian package. That should get
uploaded in a day or so.
> Thanks to all who helped track it down and thanks to Richard for pointing out
> the problem.
I just passed along the notes from IRC. The credit really goes to Achim.
> --
>
> I also pushed some other fixes that I worked on over the weekend.
>
> There is now a message that gets added to your log file if there were errors
> parsing ntp.conf.
> ntpd[5469]: INIT: saw 1 parsing errors
> That covers the problem where the parsing errors go to syslog but you are
> looking in ntpd.log. (Guess how much time I spent figuring out that I had
> typed "ntp" where I needed "nts".)
>
> The version and command line messages are now repeated after switching to a
> log file.
Are these messages repeated if I'm not using a log file? I want
everything to go to syslog; am I getting duplicated messages?
(Obviously, I haven't tested this.)
Should this perhaps be a define used in both places so they stay in sync?
+void announce_starting() {
+ char buf[1024]; /* Secret knowledge of msyslog buf length */
--
Richard
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fuzzing Messages
On 12/1/19 2:44 AM, Achim Gratz via devel wrote: > Richard Laager via devel writes: >> The issue persists when removing "nts" from "server" lines (i.e. >> disabling NTS client behavior). >> >> The problem goes away when disabling NTS server behavior. To clarify: If I run as an NTS client but not NTS server, then I get the "blocked for" errors on startup, but not past that (in short tests). > I don't serve NTS from the two test machines, so that would be an > additional code path to consider. So the NTS serving is probably why I get them on an ongoing basis and you don't. We both get them on startup from the DNS code. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fuzzing Messages
On 12/1/19 2:17 AM, Richard Laager via devel wrote: > On 11/30/19 6:17 AM, ASSI via devel wrote: >> ASSI via devel writes: >>> is… intriguing. If you follow the code through the function, ts_min in >>> the log should always be ts_prev+sys_fuzz; these two values can't be >>> identical or differ by any other value, ts_min must strictly be greater >>> than ts_prev by sys_fuzz. I notice that there is always a DNS operation >>> logged at the same time when I get these errors, so I am pretty sure >>> this is related to the DNS thread. > > That was the case for me _at startup_, but not after that. (See the > attached logs.) > >>> This would also explain why a server >>> that has many clients would see many more such errors. > > Why's that? What DNS lookups is ntpd doing for clients? > >> While I have not yet identified the code path that is involved (likely >> something in NTS, I think), you might want to try the following monkey >> patch: The issue persists when removing "nts" from "server" lines (i.e. disabling NTS client behavior). The problem goes away when disabling NTS server behavior. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Fuzzing Messages
On 11/30/19 6:17 AM, ASSI via devel wrote: > ASSI via devel writes: >> is… intriguing. If you follow the code through the function, ts_min in >> the log should always be ts_prev+sys_fuzz; these two values can't be >> identical or differ by any other value, ts_min must strictly be greater >> than ts_prev by sys_fuzz. I notice that there is always a DNS operation >> logged at the same time when I get these errors, so I am pretty sure >> this is related to the DNS thread. That was the case for me _at startup_, but not after that. (See the attached logs.) >> This would also explain why a server >> that has many clients would see many more such errors. Why's that? What DNS lookups is ntpd doing for clients? > While I have not yet identified the code path that is involved (likely > something in NTS, I think), you might want to try the following monkey > patch: > > Let me know if makes a difference on your system. The error crops up > too sparingly on mine to really tell if it helps or not. Attached is what I have right away, filtered for DNS|CLOCK. -- Richard 2019-12-01T02:04:28.211306-06:00 ntp2 ntpd[29868]: DNS: dns_probe: ntp1.wiktel.com, cast_flags:1, flags:21901 2019-12-01T02:04:28.211433-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.46718 s while waiting for another thread 2019-12-01T02:04:28.219010-06:00 ntp2 ntpd[29868]: DNS: dns_check: processing ntp1.wiktel.com, 1, 21901 2019-12-01T02:04:28.219046-06:00 ntp2 ntpd[29868]: DNS: Server taking: 2600:2600::99 2019-12-01T02:04:28.219078-06:00 ntp2 ntpd[29868]: DNS: Server poking hole in restrictions for: 2600:2600::99 2019-12-01T02:04:28.219110-06:00 ntp2 ntpd[29868]: DNS: dns_take_status: ntp1.wiktel.com=>good, 0 2019-12-01T02:04:29.211262-06:00 ntp2 ntpd[29868]: DNS: dns_probe: time.cloudflare.com:1234, cast_flags:1, flags:21901 2019-12-01T02:04:29.211404-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.27831 s while waiting for another thread 2019-12-01T02:04:29.211444-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.08658 s while waiting for another thread 2019-12-01T02:04:29.303891-06:00 ntp2 ntpd[29868]: DNS: dns_check: processing time.cloudflare.com:1234, 1, 21901 2019-12-01T02:04:29.303925-06:00 ntp2 ntpd[29868]: DNS: Server taking: 2606:4700:f1::123 2019-12-01T02:04:29.304008-06:00 ntp2 ntpd[29868]: DNS: Server poking hole in restrictions for: 2606:4700:f1::123 2019-12-01T02:04:29.304055-06:00 ntp2 ntpd[29868]: DNS: dns_take_status: time.cloudflare.com:1234=>good, 0 2019-12-01T02:04:49.271159-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.15647 s while waiting for another thread 2019-12-01T02:05:10.364817-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.08022 s while waiting for another thread 2019-12-01T02:05:37.990619-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.51095 s while waiting for another thread 2019-12-01T02:06:04.152914-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.00160 s while waiting for another thread 2019-12-01T02:06:04.152954-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.01035 s while waiting for another thread 2019-12-01T02:06:20.372082-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.03552 s while waiting for another thread 2019-12-01T02:06:47.079607-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.01632 s while waiting for another thread 2019-12-01T02:06:52.489707-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.24759 s while waiting for another thread 2019-12-01T02:09:59.817856-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.19769 s while waiting for another thread 2019-12-01T02:10:28.192124-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.07581 s while waiting for another thread 2019-12-01T02:10:28.192234-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.22856 s while waiting for another thread 2019-12-01T02:10:41.854610-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.28176 s while waiting for another thread 2019-12-01T02:10:45.901016-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.48026 s while waiting for another thread 2019-12-01T02:10:45.901134-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.03723 s while waiting for another thread 2019-12-01T02:11:22.081163-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.09447 s while waiting for another thread 2019-12-01T02:11:22.081203-06:00 ntp2 ntpd[29868]: CLOCK: we were blocked for 0.09033 s while waiting for another thread signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTP Performance
On 11/26/19 12:19 PM, Achim Gratz via devel wrote: > Richard Laager via devel writes: >> I only have the clock fuzzing errors on my NTP servers. I don't have an >> exact matching configuration that's not an NTP server, but: Similar >> hardware running Debian 10 and ntpsec 1.1.3 does not. Two eras of newer >> hardware running Ubuntu 18.04 and the same ntpsec do not. > > I'm not really sure it is an error yet. How many of these events do you > get? Do things eventually stabilize? On ntp1, on which ntpd was last restarted 25 days ago on the 2nd, I got 464 today (which has two hours to go). Not 464 lines (since there are multiple), 464 sets of lines: rlaager@ntp1:~$ grep "ntpd.*this fuzz" /var/log/daemon.log | wc -l 464 On ntp2, which I restarted a day or two ago: rlaager@ntp2:~$ grep "ntpd.*this fuzz" /var/log/daemon.log | wc -l 192 -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: NTP Performance
I have logs going back to 2019-10-26. These clock fuzz errors started on ntp1 on 2019-11-02 and ntp2 on 2019-11-21. On 2019-11-02, I upgraded to NTPsec 1.1.7 (from 1.1.3) and enabled NTS (as both a client and server). On 2019-11-08, I added the GPS to ntp2. Based on the dates, that seems unrelated. On 2019-11-21 on ntp2, I was performing debugging as discussed earlier in the thread. This involved a reboot. This is probably when it moved to Linux 4.15.0-70-generic (that's from the Ubuntu package), from likely 4.15.0-45-generic. That also seems unrelated, though, as ntp1 is still running 4.15.0-45-generic and has not been rebooted since 2019-09-28. Trying again with NTPsec 1.1.3 seems like a useful next step. If that is good, then I need to bisect the difference. On 11/25/19 11:46 AM, Achim Gratz via devel wrote: > Richard Laager via devel writes: >> These both have the following CPU (which is older): >> Intel(R) Xeon(R) CPU X5460 @ 3.16GHz > > These may not yet have consistent TSC between cores/sockets (or require > BIOS tweaks for that). /proc/cpu says constant_tsc, but that's it (besides "tsc", of course). That is, I do _not_ have nonstop_tsc, so therefore I presume I do not have the "invariant TSC" CPU feature. Any thoughts on what to look for in the BIOS? I poked around, but there didn't seem much related. There was a "Clock Spectrum Feature", which I assume is something about spread spectrum, which is disabled. The HPET is enabled. The Intel EIST setting is set to disabled, which the help text says disables C-states. Should I consider trying the HPET as the kernel clocksource? $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc I only have the clock fuzzing errors on my NTP servers. I don't have an exact matching configuration that's not an NTP server, but: Similar hardware running Debian 10 and ntpsec 1.1.3 does not. Two eras of newer hardware running Ubuntu 18.04 and the same ntpsec do not. I tried disabling the second CPU socket. I verified that I'm down from 8 cores to 4 cores. No change to the CLOCK_MONOTONIC_RAW performance: rlaager@ntp2:~$ ./a.out res avg min dups CLOCK 128 26CLOCK_REALTIME 400 8 3999658-1 CLOCK_REALTIME_COARSE 128 26CLOCK_MONOTONIC 1 374 362CLOCK_MONOTONIC_RAW 1 383 371CLOCK_BOOTTIME Histogram: CLOCK_REALTIME, 1 ns per bucket, 100 samples. ns hits 26 50500 27531901 28 49137 29 914 30367497 33 2 34 1 36 5 39 1 60 1 41 samples were bigger than 60. rlaager@ntp2:~$ ./a.out res avg min dups CLOCK 129 26CLOCK_REALTIME 400 8 3999852-3 CLOCK_REALTIME_COARSE 128 26CLOCK_MONOTONIC 1 375 362CLOCK_MONOTONIC_RAW 1 384 372CLOCK_BOOTTIME Histogram: CLOCK_REALTIME, 1 ns per bucket, 100 samples. ns hits 26 50139 27531774 28 49516 29 397 30367973 32 1 36 1 48 1 63 2 66 2 194 samples were bigger than 66. rlaager@ntp2:~$ ./a.out res avg min dups CLOCK 128 26CLOCK_REALTIME 400 8 3999859-3 CLOCK_REALTIME_COARSE 128 26CLOCK_MONOTONIC 1 374 366CLOCK_MONOTONIC_RAW 1 385 374CLOCK_BOOTTIME Histogram: CLOCK_REALTIME, 1 ns per bucket, 100 samples. ns hits 26 49328 27523261 28 48763 29 360 30378133 33 2 36 4 39 2 40 1 45 2 144 samples were bigger than 45. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
