NAK on 0001-ntpviz-Make-some-conditionals-Yoda-style.patch and the
similar part of the change in
0001-ntpviz-correct-usaage-for-no-os.errno-ever.patch. That style is not
common in Python, as it is unnecessary. Python does not allow "if x =
y", so you cannot make the mistake that style prohibits
On 2025-03-29 02:35, Hal Murray via devel wrote:
Anybody understand this area?
Reading state information... Done
Package python-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
Ho
On 2025-03-04 23:37, Hal Murray via devel wrote:
matthew.sel...@twosigma.com said:
I sounds like we would want a release out before we start mucking with
threads given that your review of the code shows a lot of potential
complexity.
It's not so much the complexity as the time. We've been ta
This is from: https://bugs.debian.org/1086000
Does anyone have insight on this? Is running at real-time priority
actually helpful to timekeeping accuracy?
If not, I'll remove this from the Debian package (and we should probably
remove the option upstream entirely?).
If it is helpful, is the
On 2025-02-11 20:08, Hal Murray via devel wrote:
--disable-Werror will turn it off. My expectation is that with a few
fixes like yours we won't have many problems. If that turns out to be
wrong, we can change the default.
I haven't been following this closely, so I'm not sure what you changed
On 2025-02-03 23:31, Hal Murray via devel wrote:
Did you see my comment about how dropping Python 2 before getting rid of
the polyXXX wrapers is dangerous, because removing the wrappers without
properly fixing the underlying code is more likely to break Python 3 than
Python 2?
I'm concerned t
On 2025-02-01 16:33, Fred Wright via devel wrote:
On Fri, 31 Jan 2025, Richard Laager via devel wrote:
Python 2 has been upstream EOL for 5 years. The burden here should be
on people who want to keep supporting it, not on people who want to
drop support for it.
The burden shouldn't
Python 2 has been upstream EOL for 5 years. The burden here should be on
people who want to keep supporting it, not on people who want to drop
support for it.
On 2025-01-30 18:19, Fred Wright via devel wrote:
On Wed, 29 Jan 2025, Hal Murray wrote:
That makes sense. But I'm missing the next s
On 2025-01-29 16:19, James Browning via devel wrote:
> Dropping 2.7 as well could allow for the removal of ntp.poly& stuff.
This, to me, is the major pro. How big that pro is is debatable. On the
other hand, as time passes, the usefulness of Python 2 gets less and less.
On 2025-01-29 17:53, Fr
While I understand you might be looking for buy-in before expending the
effort, one idea for moving this forward would be for you/Microsoft to
write a patch implementing this. Speaking in generalities and not to
this specific issue, it's a lot easier to accept something if there's a
clean patch
On 2025-01-24 18:30, Sarath _Msft_ via devel wrote:
I am a software engineer with Microsoft Corporation.
I'm not a crypto expert nor am I speaking on behalf of the NTPsec
project, so take this with an appropriately sized grain of salt. ;)
As I understand it, the current NTPSec implementatio
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.ntp
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@ntps
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 t
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
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
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
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 r
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
> Pyt
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 bra
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.
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
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/dev
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 (?)
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.
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,
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 use
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 ho
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-sp
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, straigh
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 no
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,
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? Ideal
+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 t
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
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 both
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
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 failu
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
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
___
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 bro
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
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.
--
Ri
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
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 r
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 v
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.
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
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
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 producti
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 the
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
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 t
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/n
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 exception
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 app
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
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
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 whe
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
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 followi
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
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 t
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.
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
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_
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 9a85
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 thi
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 e
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 r
[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
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. Go
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
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
>&g
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 compariso
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 update
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/b
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 t
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
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 di
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
>
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 corre
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
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
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 gr
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 year
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.
>
>
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 bette
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
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
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)
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, p
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
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
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"
>
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
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
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 t
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 comm
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
signatur
1 - 100 of 425 matches
Mail list logo