From esr at thyrsus.com  Tue Sep  1 17:30:20 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 1 Sep 2020 13:30:20 -0400
Subject: How about a release soon?
In-Reply-To: <20200831183606.AE6F140605C@ip-64-139-1-69.sjc.megapath.net>
References: <mark.atwood@ntpsec.org>
 <939f3644-d0ad-4c3c-9ff2-4979a5259245@www.fastmail.com>
 <20200831183606.AE6F140605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200901173020.GA776533@thyrsus.com>

Hal Murray via devel <devel at ntpsec.org>:
> > Has there been enough user visible improvement to warrent a release of 1.1.10?
> 
> I think so.
> 
> 1.1.9 doesn't know about the new port number for NTS-KE.
> 
> There is also a bug fix for a missing error message.  Without that message, 
> it's really tough to debug an obscure case of certificates not working.

I'll do a bug-triage pass.

Also, we need to decide if we want to switch to hosting the tarballs on
GitLab itself using Ian's igor tool this release.  If so, that will have a
few consequencea on th website.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From hmurray at megapathdsl.net  Tue Sep  1 22:36:14 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 01 Sep 2020 15:36:14 -0700
Subject: How about a release soon?
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Tue, 01 Sep 2020 13:30:20 EDT." <20200901173020.GA776533@thyrsus.com>
Message-ID: <20200901223614.59C9640605C@ip-64-139-1-69.sjc.megapath.net>

> I'll do a bug-triage pass.

I've seen a couple of changes go by.  Thanks.

Please let me/us know when you are finished so I can test things.


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Tue Sep  1 23:40:12 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 1 Sep 2020 19:40:12 -0400
Subject: How about a release soon?
In-Reply-To: <20200901223614.59C9640605C@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20200901173020.GA776533@thyrsus.com>
 <20200901223614.59C9640605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200901234012.GA817097@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> > I'll do a bug-triage pass.
> 
> I've seen a couple of changes go by.  Thanks.
> 
> Please let me/us know when you are finished so I can test things.

Will do.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From hmurray at megapathdsl.net  Wed Sep  2 03:27:25 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 01 Sep 2020 20:27:25 -0700
Subject: I'm giving up on seccomp
Message-ID: <20200902032725.6C63E40605C@ip-64-139-1-69.sjc.megapath.net>

[This has been in the works for a while, but I keep forgetting to type it in.]

Seccomp is a rathole.  I'm tired of it.  I think my time will be better spent 
on other things and/or our time could be better spent on other approaches - 
jails and such.  What's the word for what Debian does?

------------

This is a dump of what I know and/or have done recently.

You keep saying seccomp is important.  What does it buy us?  ntpd is a big 
complicated program.  It reads and writes files.  It opens network 
connections.  What else would a bad guy need to do?

If a serious bad guy finds a 0-day in ntpd, they can get the list of allowed 
syscalls from our source code and tweak their code to dance around anything we 
would trap.

Our current list of allowed syscalls is the collection of everything that any 
OS/distro/version has ever needed, rounded down if the compiler can figure out 
that a call doesn't exist.  That lets you check the we-support-seccomp box.  
Things are slightly complicated by early-droproot  -- it needs a few syscalls 
that are only used during initialization.  [Is early-droproot a bug?]

We use 2 large libraries that do lots of syscalls: libc and libssl.  Most of 
libc is a thin wrapper over the obvious.  Sometimes it is a little less thin 
when translating an old version into a newer syscall.

The complicated part of libc that we use is DNS lookups.  That's a pain to 
debug.  DNS disables most signals so you can't bail out without letting it 
cleanup.  So it crashes rather than letting our trap handler print an error 
message.

I have work-in-progress that lets you setup a list of syscalls actually used 
by your environment.  It does roughly the following:
  Splits the list of syscalls to be allowed out to a separate file that gets 
#includ-ed.
  A handful of scripts that process strace output to make lists of needed 
calls.
  It needs some waf work to specify the filename.  I'm just patching a link to 
point to the right file.

To collect the data, you have to run ntpd under strace.  While it is running, you have to tickle all the uncommon code paths.  Things like switching to a new ntpd.log after log rotate or reloading the cert file after it has been updated.  I have a list.  I don't know how complete it is.

One of the scripts includes a few syscalls that are hard to tickle.  That would need double checking.

Basically, making a file is enough of a pain that I don't think it's practical.  You have to be a semi-wizard in order to run the recipe.  A new libc or libssl may break things.

If somebody else wants to pick up this work I'll be glad to hand over what I have.  Otherwise, I'll drop it.  (It's not hard to recreate from scratch if you understand the above description.)

Part of the idea was that we could ship of bunch of files known to work for various distros/versions/hardware/...  The list gets pretty large.  Tracking changes in libc and libssl would be a pain.

------------

We use seccomp with a simple list of allowed syscalls.  I think there is an option to filter on arguments.  That might be interesting, for example, to restrict where we can open files for writing.

------------

If you are paranoid, you could setup a server without DNS or NTS.  That doesn't seem very interesting for public servers but might be interesting in a restricted environment.  You could get authentication using shared keys.

It might be possible to split out the NTS-KE server to another process so the server side of ntpd could handle NTP+NTS packets without libssl.  With a bit more work, the NTS-KE server could be on another system.


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Wed Sep  2 09:52:54 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 2 Sep 2020 05:52:54 -0400
Subject: I'm giving up on seccomp
In-Reply-To: <20200902032725.6C63E40605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200902032725.6C63E40605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200902095254.GA846090@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> You keep saying seccomp is important.  What does it buy us?  ntpd is a big 
> complicated program.  It reads and writes files.  It opens network 
> connections.  What else would a bad guy need to do?

I think you misunderstand.  I don't believe seccomp is objectively
very important in itself, and never have.  My problem with dropping it
is that if we do that, we could be seen to have abandoned part of a
security defense in depth because it's too much work.  That's not a
good look for a project with our mission statememt.

On the other hand, I can't blame you a bit for being tired of this
rathole, because it is indeed a huge pain in the ass for marginal
gain. I don't think any of your analysis is even a little wrong about
that.

The solution is simple and obvious, if really annoying for me.  You
should assign seccomp-related bugs to me and I will deal with them.
Think of this as incentive for me to get serious about moving the
daemon to Go :-).

(In Go, the equivalent of seccomp is neither possible nor necessary.
What makes it unnecessary is that while you can crash a Go program
with a bad reference, you can't weird-machine it. (Actually
technically you can, but it takes a specific evasion of the language's
safety rules thriugn the unsafe module)).

> [Is early-droproot a bug?]

At the current state of my knowledge I don't think so.  But you just
put auditing the stretch of code between the two droproots high on my
priority list.  It's an open question whether early droproot is worth
its complexity cost. This is not a case like seccomp where the set of
exploits closed off is effectively unbounded - in this case the
security cost of proliferating code and test paths may not be worth
the earlier privilege drop.

> We use 2 large libraries that do lots of syscalls: libc and libssl.  Most of 
> libc is a thin wrapper over the obvious.  Sometimes it is a little less thin 
> when translating an old version into a newer syscall.
> 
> The complicated part of libc that we use is DNS lookups.  That's a pain to 
> debug.  DNS disables most signals so you can't bail out without letting it 
> cleanup.  So it crashes rather than letting our trap handler print an error 
> message.
> 
> I have work-in-progress that lets you setup a list of syscalls actually used 
> by your environment.  It does roughly the following:
>   Splits the list of syscalls to be allowed out to a separate file that gets 
> #includ-ed.
>   A handful of scripts that process strace output to make lists of needed 
> calls.
>   It needs some waf work to specify the filename.  I'm just patching a link to 
> point to the right file.
> 
> To collect the data, you have to run ntpd under strace.  While it is running, you have to tickle all the uncommon code paths.  Things like switching to a new ntpd.log after log rotate or reloading the cert file after it has been updated.  I have a list.  I don't know how complete it is.
> 
> One of the scripts includes a few syscalls that are hard to tickle.  That would need double checking.
> 
> Basically, making a file is enough of a pain that I don't think it's practical.  You have to be a semi-wizard in order to run the recipe.  A new libc or libssl may break things.
> 
> If somebody else wants to pick up this work I'll be glad to hand over what I have.  Otherwise, I'll drop it.  (It's not hard to recreate from scratch if you understand the above description.)

I'm going to say drop it, and here's why.

We've already seen the frequency of seccomp bugs drop over time, and that's
to be expected. There should be fewer in the fture than there have been
in the past, lowering the value of building those specualized tools. Me,
I'd rarher you spent your effort on devoising better test protocols
as you have been doing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Wed Sep  2 10:47:39 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed,  2 Sep 2020 06:47:39 -0400 (EDT)
Subject: Pre-release cleanup
Message-ID: <20200902104739.25243F80474@snark.thyrsus.com>

I've resolved all the Coverity warbings except a new one, "risky
function" related to random(3)/  The supression cookie for that one
is not suppressing; I've sent a requesr to Synopsis about tis.

I've close two stale issues.  I think there are a few more that can
be retired. I'm continuing tio work on this.

As usual, I don't see anything really serious on the issue list.
Good work, everyone!
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

If a thousand men were not to pay their tax-bills this year, that would
... [be] the definition of a peaceable revolution, if any such is possible.
	-- Henry David Thoreau

From folkert at vanheusden.com  Wed Sep  2 11:59:24 2020
From: folkert at vanheusden.com (folkert)
Date: Wed, 2 Sep 2020 13:59:24 +0200
Subject: Pre-release cleanup
In-Reply-To: <20200902104739.25243F80474@snark.thyrsus.com>
References: <20200902104739.25243F80474@snark.thyrsus.com>
Message-ID: <20200902115924.GJ13457@belle.intranet.vanheusden.com>

> I've resolved all the Coverity warbings except a new one, "risky
> function" related to random(3)/  The supression cookie for that one
> is not suppressing; I've sent a requesr to Synopsis about tis.

Is ntpsec also checked by 'lgtm.com'? They also do all kinds of
verifications on source-code.


Folkert van Heusden

-- 
Ever wonder what is out there? Any alien races? Then please support
the seti at home project: setiathome.ssl.berkeley.edu
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

From esr at thyrsus.com  Wed Sep  2 12:07:53 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed,  2 Sep 2020 08:07:53 -0400 (EDT)
Subject: Python support policy
Message-ID: <20200902120753.3D440F80474@snark.thyrsus.com>

Python 2 was end-of-lifed at the beginning of January this year.
All our primary target platforms fully support Python 3.

Retaining support for Python 2 proliferates test paths and
complicates the fix for at least one outstanding bug.

Philosophically, I'm a fan of dropping legacy support
when it advances our security mission by decreasing
attack surface and improving auditability/maintainability.

Proposed: We should drop support for Python 2 and use a python3
shebang in all our scripts.

Discuss.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Say what you like about my bloody murderous government," I says,
"but don't insult me poor bleedin' country."	-- Edward Abbey

From esr at thyrsus.com  Wed Sep  2 12:25:43 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 2 Sep 2020 08:25:43 -0400
Subject: Pre-release cleanup
In-Reply-To: <20200902115924.GJ13457@belle.intranet.vanheusden.com>
References: <20200902104739.25243F80474@snark.thyrsus.com>
 <20200902115924.GJ13457@belle.intranet.vanheusden.com>
Message-ID: <20200902122543.GA853547@thyrsus.com>

folkert <folkert at vanheusden.com>:
> > I've resolved all the Coverity warbings except a new one, "risky
> > function" related to random(3)/  The supression cookie for that one
> > is not suppressing; I've sent a requesr to Synopsis about tis.
> 
> Is ntpsec also checked by 'lgtm.com'? They also do all kinds of
> verifications on source-code.

First I've heaerd of it. Can you point me at a tutorial on how to use it? 
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From folkert at vanheusden.com  Wed Sep  2 12:30:58 2020
From: folkert at vanheusden.com (folkert)
Date: Wed, 2 Sep 2020 14:30:58 +0200
Subject: Pre-release cleanup
In-Reply-To: <20200902122543.GA853547@thyrsus.com>
References: <20200902104739.25243F80474@snark.thyrsus.com>
 <20200902115924.GJ13457@belle.intranet.vanheusden.com>
 <20200902122543.GA853547@thyrsus.com>
Message-ID: <20200902123058.GK13457@belle.intranet.vanheusden.com>

> > > I've resolved all the Coverity warbings except a new one, "risky
> > > function" related to random(3)/  The supression cookie for that one
> > > is not suppressing; I've sent a requesr to Synopsis about tis.
> > 
> > Is ntpsec also checked by 'lgtm.com'? They also do all kinds of
> > verifications on source-code.
> 
> First I've heaerd of it. Can you point me at a tutorial on how to use it? 

I only found it recently as well :-)

They interface with github and bitbucket.

https://lgtm.com/help/lgtm/getting-started

From esr at thyrsus.com  Wed Sep  2 12:36:17 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 2 Sep 2020 08:36:17 -0400
Subject: Pre-release cleanup
In-Reply-To: <20200902123058.GK13457@belle.intranet.vanheusden.com>
References: <20200902104739.25243F80474@snark.thyrsus.com>
 <20200902115924.GJ13457@belle.intranet.vanheusden.com>
 <20200902122543.GA853547@thyrsus.com>
 <20200902123058.GK13457@belle.intranet.vanheusden.com>
Message-ID: <20200902123617.GA854772@thyrsus.com>

folkert <folkert at vanheusden.com>:
> > > > I've resolved all the Coverity warbings except a new one, "risky
> > > > function" related to random(3)/  The supression cookie for that one
> > > > is not suppressing; I've sent a requesr to Synopsis about tis.
> > > 
> > > Is ntpsec also checked by 'lgtm.com'? They also do all kinds of
> > > verifications on source-code.
> > 
> > First I've heaerd of it. Can you point me at a tutorial on how to use it? 
> 
> I only found it recently as well :-)
> 
> They interface with github and bitbucket.
> 
> https://lgtm.com/help/lgtm/getting-started

Unfortunately, thast's a blocker.  We're on gitlab.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From ghane0 at gmail.com  Wed Sep  2 12:45:22 2020
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 2 Sep 2020 20:45:22 +0800
Subject: Pre-release cleanup
In-Reply-To: <20200902123617.GA854772@thyrsus.com>
References: <20200902104739.25243F80474@snark.thyrsus.com>
 <20200902115924.GJ13457@belle.intranet.vanheusden.com>
 <20200902122543.GA853547@thyrsus.com>
 <20200902123058.GK13457@belle.intranet.vanheusden.com>
 <20200902123617.GA854772@thyrsus.com>
Message-ID: <CAHZk5WfbeWN0b2JHRj0FJUG6vAXzA8v9qNYoLw6eRGqnHTy=fg@mail.gmail.com>

They support *any* git repository.

Please see: https://lgtm.com/projects/g/ntpsec/ntpsec/?mode=list

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/70f8ab42/attachment.htm>

From esr at thyrsus.com  Wed Sep  2 12:53:41 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 2 Sep 2020 08:53:41 -0400
Subject: Pre-release cleanup
In-Reply-To: <CAHZk5WfbeWN0b2JHRj0FJUG6vAXzA8v9qNYoLw6eRGqnHTy=fg@mail.gmail.com>
References: <20200902104739.25243F80474@snark.thyrsus.com>
 <20200902115924.GJ13457@belle.intranet.vanheusden.com>
 <20200902122543.GA853547@thyrsus.com>
 <20200902123058.GK13457@belle.intranet.vanheusden.com>
 <20200902123617.GA854772@thyrsus.com>
 <CAHZk5WfbeWN0b2JHRj0FJUG6vAXzA8v9qNYoLw6eRGqnHTy=fg@mail.gmail.com>
Message-ID: <20200902125341.GB855198@thyrsus.com>

Sanjeev Gupta <ghane0 at gmail.com>:
> They support *any* git repository.

Huh.  Their docs are out of date, then.

> Please see: https://lgtm.com/projects/g/ntpsec/ntpsec/?mode=list

That's excellent.  I'll chew through some of these today.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From ghane0 at gmail.com  Wed Sep  2 13:45:20 2020
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 2 Sep 2020 21:45:20 +0800
Subject: No subject
Message-ID: <CAHZk5WeXcqF4o9oB-1-wFf3iux7bdnraGn1ZN7j71CQXqda7oQ@mail.gmail.com>

Ian, please see this, in ntpsnmpd.py


        if source == ntp.control.CTL_SST_TS_UNSPEC:
            mode = 2  # Not yet synced
        elif False:
            mode = 3  # No reference configured
        elif source == ntp.control.CTL_SST_TS_LOCAL:
            mode = 4  # Distributing local clock (low accuracy)
        elif source in (ntp.control.CTL_SST_TS_ATOM,
                        ntp.control.CTL_SST_TS_LF,
                        ntp.control.CTL_SST_TS_HF,
                        ntp.control.CTL_SST_TS_UHF):
            # I am not sure if I should be including the radios in this
            mode = 5  # Synced to local refclock
        elif source == ntp.control.CTL_SST_TS_NTP:
            # Should this include "other"? That covers things like chrony...
            mode = 6  # Sync to remote NTP
        else:
            mode = 99  # Unknown
        return mode

lgtm claims that mode = 3 line is unreachable.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/64900bf1/attachment.htm>

From hmurray at megapathdsl.net  Wed Sep  2 16:28:44 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 02 Sep 2020 09:28:44 -0700
Subject: Python support policy
In-Reply-To: Message from "Eric S. Raymond via devel" <devel@ntpsec.org>
 of "Wed,
 02 Sep 2020 08:07:53 EDT." <20200902120753.3D440F80474@snark.thyrsus.com>
Message-ID: <20200902162844.B9B4C40605C@ip-64-139-1-69.sjc.megapath.net>


Eric said:
> Proposed: We should drop support for Python 2 and use a python3 shebang in
> all our scripts. 

Works for me.

Do we want to do that now or after the hopefully soon release?
Now would debug things before a 1.2 release.

-- 
These are my opinions.  I hate spam.




From gem at rellim.com  Wed Sep  2 17:20:38 2020
From: gem at rellim.com (Gary E. Miller)
Date: Wed, 2 Sep 2020 10:20:38 -0700
Subject: I'm giving up on seccomp
In-Reply-To: <20200902095254.GA846090@thyrsus.com>
References: <20200902032725.6C63E40605C@ip-64-139-1-69.sjc.megapath.net>
 <20200902095254.GA846090@thyrsus.com>
Message-ID: <20200902102038.5ea58160@rellim.com>

Yo Eric!

On Wed, 2 Sep 2020 05:52:54 -0400
"Eric S. Raymond via devel" <devel at ntpsec.org> wrote:

> Hal Murray <hmurray at megapathdsl.net>:
> > You keep saying seccomp is important.  What does it buy us?  ntpd
> > is a big complicated program.  It reads and writes files.  It opens
> > network connections.  What else would a bad guy need to do?  
> 
> I think you misunderstand.  I don't believe seccomp is objectively
> very important in itself, and never have.  My problem with dropping it
> is that if we do that, we could be seen to have abandoned part of a
> security defense in depth because it's too much work.  That's not a
> good look for a project with our mission statememt.

Sadly, I agree with both of you.

I agree with Hal that seccomp is mere security theater.  One that
requires a lot of effort to sustain, for no actual value.

I agree with Eric that the perception that seccomp makes systems
safer is also strong.  That (mis)perception has value for NTPsec.

So, as Eric said:

"You should assign seccomp-related bugs to me and I will deal with them."

He wants to carry the load, let him.

"Think of this as incentive for me to get serious about moving the
daemon to Go"

Lost me.  seccomp applies to Go as much as it applies to C.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/fdaf9dd7/attachment-0001.bin>

From gem at rellim.com  Wed Sep  2 17:47:38 2020
From: gem at rellim.com (Gary E. Miller)
Date: Wed, 2 Sep 2020 10:47:38 -0700
Subject: Python support policy
In-Reply-To: <20200902120753.3D440F80474@snark.thyrsus.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
Message-ID: <20200902104738.52ba52bc@rellim.com>

Yo Eric!

On Wed,  2 Sep 2020 08:07:53 -0400 (EDT)
"Eric S. Raymond via devel" <devel at ntpsec.org> 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.

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.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/a68aac3a/attachment.bin>

From esr at thyrsus.com  Wed Sep  2 18:33:10 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 2 Sep 2020 14:33:10 -0400
Subject: I'm giving up on seccomp
In-Reply-To: <20200902102038.5ea58160@rellim.com>
References: <20200902032725.6C63E40605C@ip-64-139-1-69.sjc.megapath.net>
 <20200902095254.GA846090@thyrsus.com>
 <20200902102038.5ea58160@rellim.com>
Message-ID: <20200902183310.GA865678@thyrsus.com>

Gary E. Miller via devel <devel at ntpsec.org>:
> Lost me.  seccomp applies to Go as much as it applies to C.

Why do you think so?  My understanding is that the reason you want to
block unexpected system calls is becase C buffer overruns can be used
to make weird machines.

You can't do that in Go, because there's no pointer arithmetic and
array accesses are all bounds-checked. Thus the utility of blocking
unexpected system calls pretty much vanishes.

Is there something wrong with this reasoning?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/ed592241/attachment.bin>

From gem at rellim.com  Wed Sep  2 19:04:27 2020
From: gem at rellim.com (Gary E. Miller)
Date: Wed, 2 Sep 2020 12:04:27 -0700
Subject: I'm giving up on seccomp
In-Reply-To: <20200902183310.GA865678@thyrsus.com>
References: <20200902032725.6C63E40605C@ip-64-139-1-69.sjc.megapath.net>
 <20200902095254.GA846090@thyrsus.com>
 <20200902102038.5ea58160@rellim.com>
 <20200902183310.GA865678@thyrsus.com>
Message-ID: <20200902120427.1521668c@rellim.com>

Yo Eric!

On Wed, 2 Sep 2020 14:33:10 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller via devel <devel at ntpsec.org>:
> > Lost me.  seccomp applies to Go as much as it applies to C.  
> 
> Why do you think so?  My understanding is that the reason you want to
> block unexpected system calls is becase C buffer overruns can be used
> to make weird machines.

Buffer overruns are just one way a program might make unexpected system
calls.  Even if you can guarantee that a Go program could never be
maliciously corrupted externally, you can never guarantee that the
Go program can not be trojaned.

So Go will still need seccomp, and will have be the same PITA it is
with C.

> Is there something wrong with this reasoning?

Yup.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/631837fe/attachment.bin>

From rlaager at wiktel.com  Wed Sep  2 19:09:30 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Wed, 2 Sep 2020 14:09:30 -0500
Subject: I'm giving up on seccomp
In-Reply-To: <20200902032725.6C63E40605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200902032725.6C63E40605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <6172b6d9-aef8-32ae-e28f-7ac5fb38ef46@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/e2b9ec6a/attachment.bin>

From rlaager at wiktel.com  Wed Sep  2 19:14:43 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Wed, 2 Sep 2020 14:14:43 -0500
Subject: Python support policy
In-Reply-To: <20200902104738.52ba52bc@rellim.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
Message-ID: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>

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" <devel at ntpsec.org> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/18a66c86/attachment-0001.bin>

From gem at rellim.com  Wed Sep  2 19:24:55 2020
From: gem at rellim.com (Gary E. Miller)
Date: Wed, 2 Sep 2020 12:24:55 -0700
Subject: Python support policy
In-Reply-To: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
Message-ID: <20200902122455.4210dce9@rellim.com>

Yo Richard!

On Wed, 2 Sep 2020 14:14:43 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> >> Proposed: We should drop support for Python 2 and use a python3
> >> shebang in all our scripts.  
> 
> Yes, please.

We will have to agree to disagree.  Unless you want to support all the
resulting support comlaints?

> > 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.

Never been that way on Gentoo, never will be.  So, for the love of
the Goddess, NO.  Also not valid on most distos.

I suggest you spend some time with PEP 394:

https://www.python.org/dev/peps/pep-0394/#recommendation

Then look at how often it changes.

> The most likely to work is probably this:
> #!/usr/bin/env python3

Not on Gentoo!

> But yeah, I would make it a build option. waf presumably knows where
> Python is, since it is running in Python.

On  many distors, like Gentoo, the building Python is not always the target
python.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/bc615d13/attachment.bin>

From hmurray at megapathdsl.net  Wed Sep  2 19:30:04 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 02 Sep 2020 12:30:04 -0700
Subject: I'm giving up on seccomp
Message-ID: <20200902193004.75EB740605C@ip-64-139-1-69.sjc.megapath.net>

> 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?

Are their similar facilities available on other OSes/distros?


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Wed Sep  2 21:50:14 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 02 Sep 2020 14:50:14 -0700
Subject: I'm giving up on seccomp
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Wed, 02 Sep 2020 05:52:54 EDT." <20200902095254.GA846090@thyrsus.com>
Message-ID: <20200902215014.8166340605C@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
> I think you misunderstand.  I don't believe seccomp is objectively very
> important in itself, and never have.  My problem with dropping it is that if
> we do that, we could be seen to have abandoned part of a security defense in
> depth because it's too much work.  That's not a good look for a project with
> our mission statememt. 

"too much work" in an interesting phrase.  How does that compare with "not an 
efficient use of our resources"?

I didn't mean to suggest that we should drop it totally, just that I was 
giving up on tightening things down such that we only allowed the syscalls 
needed by a particular distro/version/hardware/???

> The solution is simple and obvious, if really annoying for me.  You should
> assign seccomp-related bugs to me and I will deal with them. Think of this as
> incentive for me to get serious about moving the daemon to Go :-). 

I think you have jumped to an unreasonable conclusion by assuming that Go 
makes seccomp unintestering.  Are you going to rewrite OpenSSL in Go?  Even 
without that, are you sure there are no bugs in Go?

Maybe we should think harder about splitting NTS-KE out from ntpd.  (Without 
NTS-KE, ntpd doesn't need libssl.  It would still need libcrypto.)

--------

My comment about early-droproot wasn't clear.  There will be a few more 
syscalls needed by the code between early and normal droproot.  Since we 
aren't processing packets during initialization there is low risk of bad guys 
getting in.  But if they do get in post-initialization, they have a few more 
syscalls they can use.


-- 
These are my opinions.  I hate spam.




From rlaager at wiktel.com  Wed Sep  2 22:07:47 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Wed, 2 Sep 2020 17:07:47 -0500
Subject: I'm giving up on seccomp
In-Reply-To: <20200902193004.75EB740605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200902193004.75EB740605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <3124a4bf-d42d-0065-4a03-f46693254d7c@wiktel.com>

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
-------------- next part --------------
# vim:syntax=apparmor
# Updated for Ubuntu by: Jamie Strandboge <jamie at canonical.com>
# ------------------------------------------------------------------
#
#    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 <tunables/global>
#include <tunables/ntpd>
/usr/sbin/ntpd flags=(attach_disconnected) {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/user-tmp>

  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 <local/usr.sbin.ntpd>
}
-------------- next part --------------
# 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"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/f13e9deb/attachment.bin>

From esr at thyrsus.com  Wed Sep  2 23:39:05 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 2 Sep 2020 19:39:05 -0400
Subject: I'm giving up on seccomp
In-Reply-To: <20200902215014.8166340605C@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20200902095254.GA846090@thyrsus.com>
 <20200902215014.8166340605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200902233905.GA16627@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > I think you misunderstand.  I don't believe seccomp is objectively very
> > important in itself, and never have.  My problem with dropping it is that if
> > we do that, we could be seen to have abandoned part of a security defense in
> > depth because it's too much work.  That's not a good look for a project with
> > our mission statememt. 
> 
> "too much work" in an interesting phrase.  How does that compare with "not an 
> efficient use of our resources"?

Sometimes you have make efforts in the direction of being seen to do the right
thing that can't be considered strictly efficient.  Support for the BSD Unixes
is in this category, too.

> I didn't mean to suggest that we should drop it totally, just that I was 
> giving up on tightening things down such that we only allowed the syscalls 
> needed by a particular distro/version/hardware/???

Oh.  I'm fine with that path.  I thought you wanted to heave seccomp
overboard in its entirety.

> I think you have jumped to an unreasonable conclusion by assuming that Go 
> makes seccomp unintestering.  Are you going to rewrite OpenSSL in Go?

No.  There's an opennsl binding: https://godoc.org/github.com/spacemonkeygo/openssl

> Even without that, are you sure there are no bugs in Go?

No, I'm not.  But neither do I think seccomp is actually *possible* in Go
at this point, which tends to relieve us of having to support it.

> Maybe we should think harder about splitting NTS-KE out from ntpd.

I lean against that - it seems like that split would make deploytment
and configuration more complicated.  But I could be persuaded.

> My comment about early-droproot wasn't clear.  There will be a few more 
> syscalls needed by the code between early and normal droproot.  Since we 
> aren't processing packets during initialization there is low risk of bad guys 
> getting in.  But if they do get in post-initialization, they have a few more 
> syscalls they can use.

Got it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From fw at fwright.net  Wed Sep  2 23:42:17 2020
From: fw at fwright.net (Fred Wright)
Date: Wed, 2 Sep 2020 16:42:17 -0700 (PDT)
Subject: cpp hacking: bump FOO by 1
In-Reply-To: <20200830171203.5294540605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200830171203.5294540605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <alpine.OSX.2.23.453.2009021601460.74434@macpro.local>


On Sun, 30 Aug 2020, Hal Murray via devel wrote:

> Is there any way to do something like
> #define FOO $FOO+1
>
> I want to keep track of the number of times a macro has been called.  That
> seems like something that would happen often enough that there would be a
> standard recipe but I haven't seen it.  (Or didn't recognize it.)
>
> ----------
>
> The context is the code in ntp_control that is responding to ntpq requests to
> read a variable.  It needs to translate a string (name of variable to read) to
> a subroutine to print that variable.  Current code looks like:
>
> #define CS_REFID                6
>        { CS_REFID,             RO|DEF, "refid" },
> #define CS_REFTIME              7
>        { CS_REFTIME,           RO|DEF, "reftime" },
> #define CS_POLL                 8
>        { CS_POLL,              RO|DEF, "tc" },
> #define CS_PEERID               9
>        { CS_PEERID,            RO|DEF, "peer" },
>
> That sets up the table to search.  The table is big (~100 slots) so it's a
> real pain to insert a new slot.
>
> Later on, there is a giant select that uses those CS_xxx tags:
>
>        case CS_ROOTDELAY:
>                ctl_putdbl(sys_var[CS_ROOTDELAY].text,
>                           sys_vars.sys_rootdelay * MS_PER_S);
>                break;
>
>        case CS_ROOTDISPERSION:
>                ctl_putdbl(sys_var[CS_ROOTDISPERSION].text,
>                           sys_vars.sys_rootdisp * MS_PER_S);
>                break;
>
> ---------

The usual way to do this sort of thing with the lame macro processor known 
as cpp is as follows:

First define a "master macro" whose body is a series of invocations of an 
entry macro, with all the necessary properties being provided as 
arguments.  Then, for each table or other use:

1) Define the entry macro to generate the appropriate content from the 
appropriate arguments.

2) Invoke the master macro.

3) Undefine the entry macro (so it's ready for next time).

I can't make a precise example since you chose different entries for the 
two parts of your example above, but for the first part one could have 
something like this:

#define CS_ENTRIES \
 	CS_ENTRY(REFID, RO|DEF, "refid") \
 	CS_ENTRY(POLL, RO|DEF, "tc") \
 	CS_ENTRY(PEERID, RO|DEF, "peer") \

Then, to define the numeric codes:

#define CS_ENTRY(sym, flags, name) CS_##sym,
enum cs_index {
 	CS_ENTRIES
 	CS_MAXVAL	// Maximum value +1
};
#undef CS_ENTRY

For a table of names:

#define CS_ENTRY(sym, flags, name) name,
static const char * const cs_names[] = {
 	CS_ENTRIES
};
#undef CS_ENTRY

> One approach would be to have an external program do the equivalent of the cpp
> processing that we would like to do.  That would take some waf hacking, but
> shouldn't be a big deal.

An unnecessary complication.

Fred Wright

From gem at rellim.com  Wed Sep  2 23:47:14 2020
From: gem at rellim.com (Gary E. Miller)
Date: Wed, 2 Sep 2020 16:47:14 -0700
Subject: I'm giving up on seccomp
In-Reply-To: <20200902233905.GA16627@thyrsus.com>
References: <esr@thyrsus.com> <20200902095254.GA846090@thyrsus.com>
 <20200902215014.8166340605C@ip-64-139-1-69.sjc.megapath.net>
 <20200902233905.GA16627@thyrsus.com>
Message-ID: <20200902164714.3f94c8ca@rellim.com>

Yo Eric!

On Wed, 2 Sep 2020 19:39:05 -0400
"Eric S. Raymond via devel" <devel at ntpsec.org> wrote:

> > > Even without that, are you sure there are no bugs in Go?  
> 
> No, I'm not.  But neither do I think seccomp is actually *possible*
> in Go at this point, which tends to relieve us of having to support
> it.

Already done:

https://github.com/seccomp/libseccomp-golang

Never underestimate the tenacity of people sticking to their brand of
security theater.


> > Maybe we should think harder about splitting NTS-KE out from ntpd.  
> 
> I lean against that - it seems like that split would make deploytment
> and configuration more complicated.  But I could be persuaded.

Many people have asked for it.  They want to be able to deploy the KE
part on on host and have the NTP part on other hosts.


RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/4aa81d76/attachment.bin>

From rlaager at wiktel.com  Thu Sep  3 00:29:15 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Wed, 2 Sep 2020 19:29:15 -0500
Subject: Python support policy
In-Reply-To: <20200902122455.4210dce9@rellim.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
Message-ID: <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>

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 at .) 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/62f951a4/attachment.bin>

From esr at thyrsus.com  Thu Sep  3 00:35:38 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 2 Sep 2020 20:35:38 -0400
Subject: I'm giving up on seccomp
In-Reply-To: <20200902120427.1521668c@rellim.com>
References: <20200902032725.6C63E40605C@ip-64-139-1-69.sjc.megapath.net>
 <20200902095254.GA846090@thyrsus.com>
 <20200902102038.5ea58160@rellim.com>
 <20200902183310.GA865678@thyrsus.com>
 <20200902120427.1521668c@rellim.com>
Message-ID: <20200903003538.GB16627@thyrsus.com>

Gary E. Miller via devel <devel at ntpsec.org>:
> Buffer overruns are just one way a program might make unexpected system
> calls.  Even if you can guarantee that a Go program could never be
> maliciously corrupted externally, you can never guarantee that the
> Go program can not be trojaned.

Everything is cost gradients.

Yes, a Go program could be Trojaned, but (a) that is far less likely
than a buffer overrun is in C, and (b) there are reasonably efficient
auditing methods to detect Trojanning, good enough that even static
analyzers lilke Coverity and LGTM can usually catch them by looking
for shellouts.  Syscall blocking is not really the best-fit tool for
defense against this kind of attack.

Daniel knows more about this sort of thing than I do and might correct
me, but it's my impression that syscall blocking is *specifically* a
best-fit defence against object-code weird machines prpoduced by
buffer-overrun and stack-corruption attacks, and its utility drops off
sharply for other kinds of attacks that are better foiked in different
ways.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/0f82f435/attachment-0001.bin>

From gem at rellim.com  Thu Sep  3 00:37:04 2020
From: gem at rellim.com (Gary E. Miller)
Date: Wed, 2 Sep 2020 17:37:04 -0700
Subject: I'm giving up on seccomp
In-Reply-To: <20200903003538.GB16627@thyrsus.com>
References: <20200902032725.6C63E40605C@ip-64-139-1-69.sjc.megapath.net>
 <20200902095254.GA846090@thyrsus.com>
 <20200902102038.5ea58160@rellim.com>
 <20200902183310.GA865678@thyrsus.com>
 <20200902120427.1521668c@rellim.com>
 <20200903003538.GB16627@thyrsus.com>
Message-ID: <20200902173704.3c27b3d1@rellim.com>

Yo Eric!

On Wed, 2 Sep 2020 20:35:38 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller via devel <devel at ntpsec.org>:
> > Buffer overruns are just one way a program might make unexpected
> > system calls.  Even if you can guarantee that a Go program could
> > never be maliciously corrupted externally, you can never guarantee
> > that the Go program can not be trojaned.  
> 
> Everything is cost gradients.
> 
> Yes, a Go program could be Trojaned, but (a) that is far less likely
> than a buffer overrun is in C, and (b) there are reasonably efficient
> auditing methods to detect Trojanning, good enough that even static
> analyzers lilke Coverity and LGTM can usually catch them by looking
> for shellouts.  Syscall blocking is not really the best-fit tool for
> defense against this kind of attack.

No one said the love of seccomp made any sense.  But you don't take a
security blanket away from an infant.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/b96dc2d6/attachment.bin>

From gem at rellim.com  Thu Sep  3 00:44:27 2020
From: gem at rellim.com (Gary E. Miller)
Date: Wed, 2 Sep 2020 17:44:27 -0700
Subject: Python support policy
In-Reply-To: <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
Message-ID: <20200902174427.00ed325a@rellim.com>

Yo Richard!

On Wed, 2 Sep 2020 19:29:15 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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,

Which is what the PEP preferred, until the Python people gave up
fighting a certain unnamed distro's people.

> 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

Uh, no.  That breaks Gentoo eselect.  Many other distros prefer not
either.  You can't just look at the problem through the lens of your
distro.

> 2. Change the other scripts the same way.
> 
> 3. Update the docs and CI accordingly.

The last gpsd release made it a replaceable variable because every
distro wanted it different.

>   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.

> Option A is trivial. I could have that patch done in 10 minutes.

Which would mirror gpsd, and make many packagers happy.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/2e69af2c/attachment.bin>

From esr at thyrsus.com  Thu Sep  3 00:51:45 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 2 Sep 2020 20:51:45 -0400
Subject: Python support policy
In-Reply-To: <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
Message-ID: <20200903005145.GC16627@thyrsus.com>

Richard Laager via devel <devel at ntpsec.org>:
> 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.

I'm in favor of this simple, brute-force approach.

If nobody comes up with a good argument for retaining Python 2
support, I will ask Mark to include in the release notes that this
is our *last* release with Python 2 support.  Then we'll rip out the
Python 2 code paths before the next one.

> 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 at .) Is this something people care about?

I don't want to go down this road.  I have ugly memories associated
with a smiliar hack in gpsd, long ago.

>    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.

Yes.  To the best of my knowledge every current Unix-like thing
does right with python3 in the shebang line.  That makes hacking those
shebangs as unnecessary as it would be hazardous.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/501cfa8d/attachment.bin>

From gem at rellim.com  Thu Sep  3 00:54:37 2020
From: gem at rellim.com (Gary E. Miller)
Date: Wed, 2 Sep 2020 17:54:37 -0700
Subject: Python support policy
In-Reply-To: <20200903005145.GC16627@thyrsus.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
Message-ID: <20200902175437.403a57eb@rellim.com>

Yo Eric!

On Wed, 2 Sep 2020 20:51:45 -0400
"Eric S. Raymond via devel" <devel at ntpsec.org> wrote:

> Richard Laager via devel <devel at ntpsec.org>:
> > 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.  
> 
> I'm in favor of this simple, brute-force approach.
> 
> If nobody comes up with a good argument for retaining Python 2

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.

> > 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 at .) Is this something
> > people care about?  
> 
> I don't want to go down this road.  I have ugly memories associated
> with a smiliar hack in gpsd, long ago.

But what about how it works now?  All the maintainers like it.

> >    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.  
> 
> Yes.  To the best of my knowledge every current Unix-like thing
> does right with python3 in the shebang line.  That makes hacking those
> shebangs as unnecessary as it would be hazardous.

All proposals so far break Gentoo, and its derivatives.  Plus Windows,
should that port ever work again.   Except for the shebang substitution.

That is also hazxardous.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/7ca9d628/attachment.bin>

From hmurray at megapathdsl.net  Thu Sep  3 01:20:13 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 02 Sep 2020 18:20:13 -0700
Subject: I'm giving up on seccomp
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Wed, 02 Sep 2020 19:39:05 EDT." <20200902233905.GA16627@thyrsus.com>
Message-ID: <20200903012013.135DB40605C@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
>> I think you have jumped to an unreasonable conclusion by assuming that Go 
>> makes seccomp unintestering.  Are you going to rewrite OpenSSL in Go?
> No.  There's an opennsl binding: ...

That's the whole point of my comment.  OpenSSL is written in c.  If there is a 
typical buffer overrun bug in OpenSSL, seccomp would be as helpful for a Go 
version of ntpd as it is for the current version.

If you want to claim your Go program has no buffer overruns, you can't call 
out to big complicated libraries written in c.  You would have to rewrite them 
in Go.

--------

Re early-droproot

We should split enable-seccomp from drop root.  Early drop root is good.  Late 
enable-seccomp is good.



-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Thu Sep  3 01:25:51 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 02 Sep 2020 18:25:51 -0700
Subject: Splitting NTS-KE out from ntpd
Message-ID: <20200903012551.0DAE640605C@ip-64-139-1-69.sjc.megapath.net>


Gary said:
> Many people have asked for it.  They want to be able to deploy the KE part on
> on host and have the NTP part on other hosts. 

Where is that happening?  I've missed it.  Maybe I just skimmed to fast, but I 
don't remember any use case where running NTS-KE on a separate host was 
important.

-- 
These are my opinions.  I hate spam.




From gem at rellim.com  Thu Sep  3 01:30:09 2020
From: gem at rellim.com (Gary E. Miller)
Date: Wed, 2 Sep 2020 18:30:09 -0700
Subject: Splitting NTS-KE out from ntpd
In-Reply-To: <20200903012551.0DAE640605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200903012551.0DAE640605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200902183009.5b2a186c@rellim.com>

Yo Hal!

On Wed, 02 Sep 2020 18:25:51 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

> Gary said:
> > Many people have asked for it.  They want to be able to deploy the
> > KE part on on host and have the NTP part on other hosts.   
> 
> Where is that happening?  I've missed it.

It is not happening, just a request.  It seems to raise its
hand every few weeks.

> Maybe I just skimmed to
> fast, but I don't remember any use case where running NTS-KE on a
> separate host was important.

The idea is that you want NTP on a bunch of servers, but only want your
private keys on a very secure server.  Otherwise you have to manage TPM
on every server, which is a PITA.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/fd5dd20f/attachment-0001.bin>

From Matthew.Selsky at twosigma.com  Thu Sep  3 01:37:40 2020
From: Matthew.Selsky at twosigma.com (Matthew Selsky)
Date: Thu, 3 Sep 2020 01:37:40 +0000
Subject: Pre-release cleanup
In-Reply-To: <20200902125341.GB855198@thyrsus.com>
References: <20200902104739.25243F80474@snark.thyrsus.com>
 <20200902115924.GJ13457@belle.intranet.vanheusden.com>
 <20200902122543.GA853547@thyrsus.com>
 <20200902123058.GK13457@belle.intranet.vanheusden.com>
 <20200902123617.GA854772@thyrsus.com>
 <CAHZk5WfbeWN0b2JHRj0FJUG6vAXzA8v9qNYoLw6eRGqnHTy=fg@mail.gmail.com>
 <20200902125341.GB855198@thyrsus.com>
Message-ID: <20200903013740.GT1733557@twosigma.com>

On Wed, Sep 02, 2020 at 08:53:41AM -0400, Eric S. Raymond via devel wrote:
> Sanjeev Gupta <ghane0 at gmail.com>:
> > They support *any* git repository.
> 
> Huh.  Their docs are out of date, then.

I tried adding our GitLab repo today and I get an error message that new GitLab repos have been disabled by the site administrator.

I previously added our GitHub mirror and it's visible via https://lgtm.com/projects/g/ntpsec/ntpsec/?mode=list But without the direct GitLab support, we don't get the benefit of recommendations during merge requests.

Thanks,
-Matt

From hmurray at megapathdsl.net  Thu Sep  3 01:38:55 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 02 Sep 2020 18:38:55 -0700
Subject: Python support policy
Message-ID: <20200903013855.5A8DA40605C@ip-64-139-1-69.sjc.megapath.net>


Richard said:
> 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 at .) Is this something people care about? 

My 2 cents...

I'm not interested in running python code out of the source tree.  I want to 
use the new libraries which are over in the build tree.

Some programs in ntpclients/ might work out of the source tree but I won't 
want to be bothered figuring out which ones do/don't or more likely keeping 
track of which ones will work with the installed libraries.





-- 
These are my opinions.  I hate spam.




From Matthew.Selsky at twosigma.com  Thu Sep  3 02:08:28 2020
From: Matthew.Selsky at twosigma.com (Matthew Selsky)
Date: Thu, 3 Sep 2020 02:08:28 +0000
Subject: Pre-release cleanup
In-Reply-To: <20200903013740.GT1733557@twosigma.com>
References: <20200902104739.25243F80474@snark.thyrsus.com>
 <20200902115924.GJ13457@belle.intranet.vanheusden.com>
 <20200902122543.GA853547@thyrsus.com>
 <20200902123058.GK13457@belle.intranet.vanheusden.com>
 <20200902123617.GA854772@thyrsus.com>
 <CAHZk5WfbeWN0b2JHRj0FJUG6vAXzA8v9qNYoLw6eRGqnHTy=fg@mail.gmail.com>
 <20200902125341.GB855198@thyrsus.com> <20200903013740.GT1733557@twosigma.com>
Message-ID: <20200903020828.GU1733557@twosigma.com>

I also previously setup Codacy in order to see what other SAST systems could do. See https://app.codacy.com/gl/NTPsec/ntpsec/dashboard

Let me know what you think.  If either are useful, I'll integrate them more tightly in our workflows.

Thanks,
-Matt

From hmurray at megapathdsl.net  Thu Sep  3 06:46:16 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 02 Sep 2020 23:46:16 -0700
Subject: ntpsec | The --disable-nts option is partially ineffective (#666)
In-Reply-To: Message from Fred Wright <gitlab@mg.gitlab.com>
 of "Thu, 03 Sep 2020 01:12:20 -0000." <issue_70659942@gitlab.com>
Message-ID: <20200903064616.86C3B40605C@ip-64-139-1-69.sjc.megapath.net>


For those who haven't been following the details, the problem is not 
--disable-nts, but a version of Phthon that is old enough that it doesn't have 
hmac.compare_digest()


> As of 1.1.9, NTPsec doesn't build "normally" on Debian 7...

Debian 7 is pretty old.  Support ended May 2018

Do we want to support versions of distros that the vendor doesn't support any 
more?  My vote would be no.

Do we know of any other potentially interesting distro/versions that have this 
particular problem?

How good is our CI coverage?  Most distros support 2 versions: a current and 
an older but still supported so people have plenty of time to update.  Do we 
test both?  ,,,


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Thu Sep  3 07:14:52 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 03 Sep 2020 00:14:52 -0700
Subject: Splitting NTS-KE out from ntpd
Message-ID: <20200903071452.2663D40605C@ip-64-139-1-69.sjc.megapath.net>


Thanks.

Gary said:
> It is not happening, just a request.  It seems to raise its hand every few
> weeks. 

I was trying to ask how/where/what you were hearing/seeing such requests?  
Mailing list?  usenet?  at the local pub?

If it's a place where I don't hang out, I would really appreciate it if you 
(and others) would relay that sort of market research to @devel where I will 
see, it will get archived, and we can discuss it and fold it into the 
priorities.


> The idea is that you want NTP on a bunch of servers, but only want your
> private keys on a very secure server.  Otherwise you have to manage TPM on
> every server, which is a PITA.

Seems like a reasonable request.  If you have a bunch of NTP servers, do you 
want to add a single point of failure?

Is anybody seriously interested, or is this just discussing corner cases?

I haven't worked with TPM.  How well does it work with OpenSSL?  Would our 
code have to change or do they magically cooperate without any help from our 
code?


-- 
These are my opinions.  I hate spam.




From rlaager at wiktel.com  Thu Sep  3 07:30:43 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Thu, 3 Sep 2020 02:30:43 -0500
Subject: Python support policy
In-Reply-To: <20200902174427.00ed325a@rellim.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
Message-ID: <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/57f64dce/attachment-0001.bin>

From rlaager at wiktel.com  Thu Sep  3 07:30:48 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Thu, 3 Sep 2020 02:30:48 -0500
Subject: Python support policy
In-Reply-To: <20200902175437.403a57eb@rellim.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com> <20200902175437.403a57eb@rellim.com>
Message-ID: <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/c0a345dc/attachment.bin>

From hmurray at megapathdsl.net  Thu Sep  3 08:06:42 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 03 Sep 2020 01:06:42 -0700
Subject: cpp hacking: bump FOO by 1
In-Reply-To: Message from Fred Wright via devel <devel@ntpsec.org> of "Wed,
 02 Sep 2020 16:42:17 PDT."
 <alpine.OSX.2.23.453.2009021601460.74434@macpro.local>
Message-ID: <20200903080642.DEFE240605C@ip-64-139-1-69.sjc.megapath.net>

Thanks.

I don't see how to use your master/entry macros to solve my problem.

The current code has only one table but it needs a symbol for the offset of 
each slot in the table.  Those symbols are used in a giant select.

I think I can rearrange the current code to avoid that select.  The idea is 
that the table gets a tag and union slot where we can put a procedure that 
does what was the code at that branch of the select.  Most of them would be 
handled by a handful procedures.  A few would need special routines.

-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Thu Sep  3 09:39:43 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Sep 2020 05:39:43 -0400
Subject: I'm giving up on seccomp
In-Reply-To: <20200903012013.135DB40605C@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20200902233905.GA16627@thyrsus.com>
 <20200903012013.135DB40605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200903093943.GA29509@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> >> I think you have jumped to an unreasonable conclusion by assuming that Go 
> >> makes seccomp unintestering.  Are you going to rewrite OpenSSL in Go?
> > No.  There's an opennsl binding: ...
> 
> That's the whole point of my comment.  OpenSSL is written in c.  If there is a 
> typical buffer overrun bug in OpenSSL, seccomp would be as helpful for a Go 
> version of ntpd as it is for the current version.
> 
> If you want to claim your Go program has no buffer overruns, you can't call 
> out to big complicated libraries written in c.  You would have to rewrite them 
> in Go.

Fair point. That changes my to-do list.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Thu Sep  3 09:44:11 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Sep 2020 05:44:11 -0400
Subject: Pre-release cleanup
In-Reply-To: <20200903020828.GU1733557@twosigma.com>
References: <20200902104739.25243F80474@snark.thyrsus.com>
 <20200902115924.GJ13457@belle.intranet.vanheusden.com>
 <20200902122543.GA853547@thyrsus.com>
 <20200902123058.GK13457@belle.intranet.vanheusden.com>
 <20200902123617.GA854772@thyrsus.com>
 <CAHZk5WfbeWN0b2JHRj0FJUG6vAXzA8v9qNYoLw6eRGqnHTy=fg@mail.gmail.com>
 <20200902125341.GB855198@thyrsus.com>
 <20200903013740.GT1733557@twosigma.com>
 <20200903020828.GU1733557@twosigma.com>
Message-ID: <20200903094411.GB29509@thyrsus.com>

Matthew Selsky <Matthew.Selsky at twosigma.com>:
> I also previously setup Codacy in order to see what other SAST systems could do. See https://app.codacy.com/gl/NTPsec/ntpsec/dashboard
> 
> Let me know what you think.  If either are useful, I'll integrate them more tightly in our workflows.

I'm already a fan of LGTM - it picks up Python issues none of the rest of our validators do
and seems at near parity on the C stuff.

I'll take a look at Codasy.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Thu Sep  3 10:14:13 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Sep 2020 06:14:13 -0400
Subject: Python support policy
In-Reply-To: <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
Message-ID: <20200903101413.GC29509@thyrsus.com>

Richard Laager via devel <devel at ntpsec.org>:
> 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.

On top of that, it has been Red Hat's official position for some time
that RHEL 6 shout *not* block transition to Python 3 only.

There is some easy, officially endorsed workaround that I don't
remember. Unfortunaly I can't find RH's statement about this; I'd
recognize it if I saw it but web searches aren't turning it up.

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.

This is not a judgment I am making casually.  Peter Donis and I wrote this:
http://www.catb.org/esr/faqs/practical-python-porting/  It's still the best guide
on how to write Python that runs under both 2 and 3.  Peter and I have been tracking
the transition very closely and one of the questions I'm keeping in my mind
is when I amend that document to say "there is no longer any point in this 
for new code".  

That moment is nearly upon us, and I'm pretty certain it will arrive before
2020 ends.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/55e825d1/attachment.bin>

From esr at thyrsus.com  Thu Sep  3 10:28:33 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Sep 2020 06:28:33 -0400
Subject: Python support policy
In-Reply-To: <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
Message-ID: <20200903102833.GD29509@thyrsus.com>

Richard Laager via devel <devel at ntpsec.org>:
> > 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.

I just fixed all of those.

This will probably never matter, but part of our project style is supposed
to be standards conformance so tight it squeaks.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/8098da33/attachment-0001.bin>

From esr at thyrsus.com  Thu Sep  3 10:37:07 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Sep 2020 06:37:07 -0400
Subject: Python support policy
In-Reply-To: <20200902175437.403a57eb@rellim.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
Message-ID: <20200903103707.GE29509@thyrsus.com>

Gary E. Miller via devel <devel at ntpsec.org>:
> > I don't want to go down this road.  I have ugly memories associated
> > with a smiliar hack in gpsd, long ago.
> 
> But what about how it works now?  All the maintainers like it.

Oh dear Goddess. We are *still* mutating shebangs in GPSD?  I must have
blotted that from my memory.

One reason to stop doing this kind of thing is library-path confusion.
Yes, I know we have a lash-up that barely works around that in GPSD
but our Debian package maintainer damn near has an aneurism any time
he thinks about it and I can't blame him a bit.

It will come time to end Python 2 support in GPSD soon.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/8c36433c/attachment.bin>

From gem at rellim.com  Thu Sep  3 17:33:20 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 10:33:20 -0700
Subject: Python support policy
In-Reply-To: <20200903103707.GE29509@thyrsus.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <20200903103707.GE29509@thyrsus.com>
Message-ID: <20200903103320.3424d9b9@rellim.com>

Yo Eric!

On Thu, 3 Sep 2020 06:37:07 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller via devel <devel at ntpsec.org>:
> > > I don't want to go down this road.  I have ugly memories
> > > associated with a smiliar hack in gpsd, long ago.  
> > 
> > But what about how it works now?  All the maintainers like it.  
> 
> Oh dear Goddess. We are *still* mutating shebangs in GPSD?  I must
> have blotted that from my memory.

No, we are *finally* mutating python shebangs in GPS.

> One reason to stop doing this kind of thing is library-path confusion.

Say what?  This has zero to do with libraries.

> Yes, I know we have a lash-up that barely works around that in GPSD
> but our Debian package maintainer damn near has an aneurism any time
> he thinks about it and I can't blame him a bit.

Which is why what you are talking about got removed, with something the
maintainers like.

> It will come time to end Python 2 support in GPSD soon.

For some definition of "soon".  The last Python 2 release is barely 2
months old.  I can't get distros to use newer then 3 year old gpsd.  They
seem to think that software mellows sitting on the disk.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/2dabaf18/attachment.bin>

From gem at rellim.com  Thu Sep  3 17:39:50 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 10:39:50 -0700
Subject: Python support policy
In-Reply-To: <20200903101413.GC29509@thyrsus.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
 <20200903101413.GC29509@thyrsus.com>
Message-ID: <20200903103950.208d7b5a@rellim.com>

Yo Eric!

On Thu, 3 Sep 2020 06:14:13 -0400
"Eric S. Raymond via devel" <devel at ntpsec.org> wrote:

> Richard Laager via devel <devel at ntpsec.org>:
> > 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.  
> 
> On top of that, it has been Red Hat's official position for some time
> that RHEL 6 shout *not* block transition to Python 3 only.

Now you just need to convince the RHEL, and related, users.

> 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?

> This is not a judgment I am making casually.  Peter Donis and I wrote
> this: http://www.catb.org/esr/faqs/practical-python-porting/  It's
> still the best guide on how to write Python that runs under both 2
> and 3.

Yes, and since you made it so simple, why stop support Python 2 now?

> Peter and I have been tracking the transition very closely
> and one of the questions I'm keeping in my mind is when I amend that
> document to say "there is no longer any point in this for new code".  

As many of us are.

> That moment is nearly upon us, and I'm pretty certain it will arrive
> before 2020 ends.

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.

I suggest you wait until AFTER the major distros pull the plug on Python 2.

Or, just like seccomp, you volunteer to take all the complaints.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/d9a7ef64/attachment.bin>

From gem at rellim.com  Thu Sep  3 18:07:15 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 11:07:15 -0700
Subject: Python support policy
In-Reply-To: <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
Message-ID: <20200903110715.42f7f599@rellim.com>

Yo Richard!

On Thu, 3 Sep 2020 02:30:48 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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.

And how long until all RHEL 6 folks move to RHEL 7?  What about all the
downstream distros of RHEL 6?

Gentoo also had a plan to be rid of Python 2 by this spring, then this
fall.  They had to push t back until 2021 due to all the Python that
does not yet support Python 3 that users consider essential.  I bet it
gets pushed back again.

Let us just wait until the distros, and most of their users, have moved
on to Python 3.  Until then, ntpsec works fine with Python 2, so no
damage.

We gain nothing but headaches by getting in front of the distros on this
one.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/f94bddce/attachment.bin>

From esr at thyrsus.com  Thu Sep  3 18:13:05 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Sep 2020 14:13:05 -0400
Subject: Python support policy
In-Reply-To: <20200903103320.3424d9b9@rellim.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <20200903103707.GE29509@thyrsus.com>
 <20200903103320.3424d9b9@rellim.com>
Message-ID: <20200903181305.GC41641@thyrsus.com>

Gary E. Miller via devel <devel at ntpsec.org>:
> Say what?  This has zero to do with libraries.

Sure it dies.  Use different versions of Python, require different
library paths.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/f594b019/attachment.bin>

From gem at rellim.com  Thu Sep  3 18:12:14 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 11:12:14 -0700
Subject: Python support policy
In-Reply-To: <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
Message-ID: <20200903111214.04485fed@rellim.com>

Yo Richard!

On Thu, 3 Sep 2020 02:30:43 -0500
Richard Laager via devel <devel at ntpsec.org> 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.

Hard coding the python version breaks this.  If you want to know, read
up on "select python".  Not a simple subject for the programmer, but
wonderful for the user.  Your questions show you are looking at a tree,
not the forest.

This got done wrong for years with gpsd.  Now the distros are happy
with gpsd.  Why not just copy what works to EVERYONE'S satisfaction.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/14925a92/attachment.bin>

From gem at rellim.com  Thu Sep  3 18:19:23 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 11:19:23 -0700
Subject: Splitting NTS-KE out from ntpd
In-Reply-To: <20200903071452.2663D40605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200903071452.2663D40605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200903111923.326b9a10@rellim.com>

Yo Hal!

On Thu, 03 Sep 2020 00:14:52 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

> Thanks.
> 
> Gary said:
> > It is not happening, just a request.  It seems to raise its hand
> > every few weeks.   
> 
> I was trying to ask how/where/what you were hearing/seeing such
> requests? Mailing list?  usenet?  at the local pub?

This mailing list,  the IETF NTP WG,   And #ntpsec.

> > The idea is that you want NTP on a bunch of servers, but only want
> > your private keys on a very secure server.  Otherwise you have to
> > manage TPM on every server, which is a PITA.  
> 
> Seems like a reasonable request.  If you have a bunch of NTP servers,
> do you want to add a single point of failure?

Uh?  Nothing in the request says that.

> Is anybody seriously interested, or is this just discussing corner
> cases?

They seemed like serious requests, but I'll not take the time to be their
proxy.

> I haven't worked with TPM.  How well does it work with OpenSSL?

Pretty seamless.  It is just another place to store keys and run
crypto algos.  I thought my new Ryzen motherboard would do TPM, but
it is known buggy woth Linux.

The Asus TPM modules is $12, so when it works, the masses can use TPM.

> Would our code have to change or do they magically cooperate without
> any help from our code?

My guess is no.  When openssl asks the kernel to handle keys, randomness,
and crypto algos, the kernel decides to use TPM, emulate TPM, or just
do the traditional.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/f774fb65/attachment.bin>

From gem at rellim.com  Thu Sep  3 18:21:54 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 11:21:54 -0700
Subject: Python support policy
In-Reply-To: <20200903181305.GC41641@thyrsus.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <20200903103707.GE29509@thyrsus.com>
 <20200903103320.3424d9b9@rellim.com>
 <20200903181305.GC41641@thyrsus.com>
Message-ID: <20200903112154.256c309f@rellim.com>

Yo Eric!

On Thu, 3 Sep 2020 14:13:05 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller via devel <devel at ntpsec.org>:
> > Say what?  This has zero to do with libraries.  
> 
> Sure it dies.  Use different versions of Python, require different
> library paths.

No more than any other versioned programs use their versioned backend
libraries.  But that is all a long solved problem.  I never, ever
heard of anyone having problems with Python internal libs, except
cross-compiling.

Or do you mean PYTHONPATHS?  Which is a differnt thing.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/bf14a0ff/attachment-0001.bin>

From watsonbladd at gmail.com  Thu Sep  3 20:02:32 2020
From: watsonbladd at gmail.com (Watson Ladd)
Date: Thu, 3 Sep 2020 16:02:32 -0400
Subject: time.cloudflare.com is now on port 4460
Message-ID: <CACsn0cn8PHQhH-JwXicemxbn=MDWmdVU+jZnfhDJgurT0C9OqA@mail.gmail.com>

Hello,

We're now listening on the official port. Let me know if there are any
issues.

Sincerely,
Watson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/206373ec/attachment.htm>

From fw at fwright.net  Thu Sep  3 21:18:29 2020
From: fw at fwright.net (Fred Wright)
Date: Thu, 3 Sep 2020 14:18:29 -0700 (PDT)
Subject: cpp hacking: bump FOO by 1
In-Reply-To: <20200903080642.DEFE240605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200903080642.DEFE240605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <alpine.OSX.2.23.453.2009031357590.81642@macpro.local>


On Thu, 3 Sep 2020, Hal Murray wrote:

> I don't see how to use your master/entry macros to solve my problem.

I didn't mean for those to be usable as is, but just as an illustration of 
the concept.  YMMV.

> The current code has only one table but it needs a symbol for the offset of
> each slot in the table.  Those symbols are used in a giant select.

In my example, the symbols are defined as enums, which handles the "bump 
FOO by 1" issue straightforwardly.  In general, enums are better than 
macros for compile-time constants anyway, for a number of reasons, but 
people tend to continue to use macros because "it's traditional", partly 
from the days before enums.

The CS_MAXVAL item I included is to get the range for a possible range 
check in the code.  Unfortunately, C doesn't have a built-in way to obtain 
that (sizeof(enum foo) isn't what you want).  Defining a value in this way 
makes it appear to be an additional legal value (which it isn't), which 
can then provoke compiler warnings if a switch statement doesn't include a 
case for it (or a default).  So you sometimes need to add an unreachable 
default case just to silence the warning.  Though in some cases, it can be 
arranged for the default entry to act as the range check (in which case 
you might not even need the explicit MAXVAL).

> I think I can rearrange the current code to avoid that select.  The idea is
> that the table gets a tag and union slot where we can put a procedure that
> does what was the code at that branch of the select.  Most of them would be
> handled by a handful procedures.  A few would need special routines.

Whether it's a table or a switch statement, the content can be constructed 
with this technique.  You just have to include enough arguments in the 
entry macros to cover everything needed.  If there are cases which are 
sufficiently different to make this difficult, there could be more than 
one master macro to cover different categories of cases, perhaps not even 
using a master macro for some significantly oddball cases in the switch 
(but still using it elsewhere).

Fred Wright

From fw at fwright.net  Thu Sep  3 21:33:17 2020
From: fw at fwright.net (Fred Wright)
Date: Thu, 3 Sep 2020 14:33:17 -0700 (PDT)
Subject: ntpsec | The --disable-nts option is partially ineffective (#666)
In-Reply-To: <20200903064616.86C3B40605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200903064616.86C3B40605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <alpine.OSX.2.23.453.2009031422500.81642@macpro.local>


On Wed, 2 Sep 2020, Hal Murray via devel wrote:

>> As of 1.1.9, NTPsec doesn't build "normally" on Debian 7...
>
> Debian 7 is pretty old.  Support ended May 2018
>
> Do we want to support versions of distros that the vendor doesn't support any
> more?  My vote would be no.

There are sometimes significant obstacles to upgrading.  And if A requires 
a fairly recent B, and B requires a fairly recent C, and C requires a 
fairly recent D, and D can't be upgraded for some reason, then the entire 
chain is held back.  Breaking the chain requires applying the Internet 
Robustness Principle (at least the relevant half) to version requirements 
as much as possible.

Now of course what's actually tested is a somewhat different issue.  Some 
products have the concept of "support tiers" for OS versions or other 
similar dependencies.  E.g.:

Tier 1) We test this, and will definitely fix any bugs.

Tier 2) We don't test this, but try not to break it, and will consider 
fixing bugs, especially if actual fixes are supplied.

Tier 3) We don't test this, and don't make any effort to keep it working. 
We *may* consider incorporating fixes.

Tier 99) Impractical to support, for good technical reasons.

Fred Wright

From esr at thyrsus.com  Thu Sep  3 22:21:37 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 3 Sep 2020 18:21:37 -0400
Subject: Python support policy
In-Reply-To: <20200903112154.256c309f@rellim.com>
References: <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <20200903103707.GE29509@thyrsus.com>
 <20200903103320.3424d9b9@rellim.com>
 <20200903181305.GC41641@thyrsus.com>
 <20200903112154.256c309f@rellim.com>
Message-ID: <20200903222137.GA117082@thyrsus.com>

Gary E. Miller via devel <devel at ntpsec.org>:
> Yo Eric!
> 
> On Thu, 3 Sep 2020 14:13:05 -0400
> "Eric S. Raymond" <esr at thyrsus.com> wrote:
> 
> > Gary E. Miller via devel <devel at ntpsec.org>:
> > > Say what?  This has zero to do with libraries.  
> > 
> > Sure it dies.  Use different versions of Python, require different
> > library paths.
> 
> No more than any other versioned programs use their versioned backend
> libraries.  But that is all a long solved problem.  I never, ever
> heard of anyone having problems with Python internal libs, except
> cross-compiling.
> 
> Or do you mean PYTHONPATHS?  Which is a differnt thing.

That's what I meant, yes.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/df0381ea/attachment.bin>

From gem at rellim.com  Thu Sep  3 23:32:23 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 16:32:23 -0700
Subject: Python support policy
In-Reply-To: <20200903222137.GA117082@thyrsus.com>
References: <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <20200903103707.GE29509@thyrsus.com>
 <20200903103320.3424d9b9@rellim.com>
 <20200903181305.GC41641@thyrsus.com>
 <20200903112154.256c309f@rellim.com>
 <20200903222137.GA117082@thyrsus.com>
Message-ID: <20200903163223.626a00f5@rellim.com>

Yo Eric!

On Thu, 3 Sep 2020 18:21:37 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> > Or do you mean PYTHONPATHS?  Which is a differnt thing.  
> 
> That's what I meant, yes.

Now that gpsd is Pure Python this is much less a deal.

You can install the gpsd python modules in one place and use the
only module for all your python versions.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/3fff505e/attachment.bin>

From hmurray at megapathdsl.net  Fri Sep  4 02:41:44 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 03 Sep 2020 19:41:44 -0700
Subject: cpp hacking: bump FOO by 1
In-Reply-To: Message from Fred Wright via devel <devel@ntpsec.org> of "Thu,
 03 Sep 2020 14:18:29 PDT."
 <alpine.OSX.2.23.453.2009031357590.81642@macpro.local>
Message-ID: <20200904024144.7557C40605C@ip-64-139-1-69.sjc.megapath.net>


devel at ntpsec.org said:
> In my example, the symbols are defined as enums, which handles the "bump  FOO
> by 1" issue straightforwardly.  In general, enums are better ...

Thanks.  That's the step I missed.
  



-- 
These are my opinions.  I hate spam.




From rlaager at wiktel.com  Fri Sep  4 04:05:52 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Thu, 3 Sep 2020 23:05:52 -0500
Subject: Python support policy
In-Reply-To: <20200903111214.04485fed@rellim.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
Message-ID: <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>

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 <devel at ntpsec.org> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/e8c2f286/attachment-0001.bin>

From gem at rellim.com  Fri Sep  4 04:15:54 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 21:15:54 -0700
Subject: Python support policy
In-Reply-To: <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
Message-ID: <20200903211554.66581afe@spidey.rellim.com>

Yo Richard!

On Thu, 3 Sep 2020 23:05:52 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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 <devel at ntpsec.org> 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

# select 3.7:
spidey ~ #      python3 --version
Python 3.7.8
# select 3.8:
spidey ~ #      python3 --version
Python 3.8.5

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.

Similar for other non-python python flavors.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/7502668e/attachment.bin>

From rlaager at wiktel.com  Fri Sep  4 04:28:33 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Thu, 3 Sep 2020 23:28:33 -0500
Subject: Python support policy
In-Reply-To: <20200903103950.208d7b5a@rellim.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com> <20200902175437.403a57eb@rellim.com>
 <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
 <20200903101413.GC29509@thyrsus.com> <20200903103950.208d7b5a@rellim.com>
Message-ID: <148d8c2f-9c95-d750-d492-f31eaa77f549@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/503769a1/attachment.bin>

From gem at rellim.com  Fri Sep  4 05:16:13 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 22:16:13 -0700
Subject: Python support policy
In-Reply-To: <148d8c2f-9c95-d750-d492-f31eaa77f549@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
 <20200903101413.GC29509@thyrsus.com>
 <20200903103950.208d7b5a@rellim.com>
 <148d8c2f-9c95-d750-d492-f31eaa77f549@wiktel.com>
Message-ID: <20200903221613.74749b30@spidey.rellim.com>

Yo Richard!

On Thu, 3 Sep 2020 23:28:33 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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.

Yup.  Let us know when that happens.  Gonna be years from now.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/61a83ffe/attachment.bin>

From rlaager at wiktel.com  Fri Sep  4 05:37:11 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Fri, 4 Sep 2020 00:37:11 -0500
Subject: Python support policy
In-Reply-To: <20200903221613.74749b30@spidey.rellim.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com> <20200902175437.403a57eb@rellim.com>
 <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
 <20200903101413.GC29509@thyrsus.com> <20200903103950.208d7b5a@rellim.com>
 <148d8c2f-9c95-d750-d492-f31eaa77f549@wiktel.com>
 <20200903221613.74749b30@spidey.rellim.com>
Message-ID: <e9ee8703-e155-3353-8abf-d70a4a07a33f@wiktel.com>

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 <devel at ntpsec.org> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200904/94f5f3a7/attachment-0001.bin>

From rlaager at wiktel.com  Fri Sep  4 06:00:34 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Fri, 4 Sep 2020 01:00:34 -0500
Subject: Python support policy
In-Reply-To: <20200903211554.66581afe@spidey.rellim.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
Message-ID: <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>

[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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200904/749bbedb/attachment.bin>

From gem at rellim.com  Fri Sep  4 06:04:11 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 23:04:11 -0700
Subject: Python support policy
In-Reply-To: <e9ee8703-e155-3353-8abf-d70a4a07a33f@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
 <20200903101413.GC29509@thyrsus.com>
 <20200903103950.208d7b5a@rellim.com>
 <148d8c2f-9c95-d750-d492-f31eaa77f549@wiktel.com>
 <20200903221613.74749b30@spidey.rellim.com>
 <e9ee8703-e155-3353-8abf-d70a4a07a33f@wiktel.com>
Message-ID: <20200903230411.3ba33dc3@spidey.rellim.com>

Yo Richard!

On Fri, 4 Sep 2020 00:37:11 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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 <devel at ntpsec.org> 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?

As previously mentioned here: RHEL 6.

Plus all the old installs that have not been updated.

The gpsd complaints show there are a lot of them.

Supporting Python 2 is trivial.  Why the hate?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/9c849f14/attachment.bin>

From gem at rellim.com  Fri Sep  4 06:06:48 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 3 Sep 2020 23:06:48 -0700
Subject: Python support policy
In-Reply-To: <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
References: <20200902120753.3D440F80474@snark.thyrsus.com>
 <20200902104738.52ba52bc@rellim.com>
 <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
 <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
Message-ID: <20200903230648.373c3b83@spidey.rellim.com>

Yo Richard!

On Fri, 4 Sep 2020 01:00:34 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> [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.

Once again: what you mean "we" white man?

> I understand you disagree on whether we should
> require Python 3, but if we do, then this shebang works fine.

And since I do not, it doe not.  Why do we keep going in the same circle?
Why the hate for Python 2?  Supporting it is trivial.  Let the distros
stop supporting Python 2 before we do.  When distros support Python 2, we
need to support Python 2.

This converstation taking more time than Python 2 support takes.  Please
stop wasting bytes.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200903/1dde87a5/attachment.bin>

From hmurray at megapathdsl.net  Fri Sep  4 06:15:35 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 03 Sep 2020 23:15:35 -0700
Subject: Running NTS with old versions of OpenSSL
Message-ID: <20200904061535.5C5A040605C@ip-64-139-1-69.sjc.megapath.net>


While we are discussing old versions of Python...

If your distro/version ships with an old version of OpenSSL and you want to 
use NTS,  there is a recipe in HOWTO-OpenSSL for building and installing newer 
versions of OpenSSL.

It's likely to work with reasonably old setups.  No promises.


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Fri Sep  4 06:37:55 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 03 Sep 2020 23:37:55 -0700
Subject: Python support policy
Message-ID: <20200904063755.6457E40605C@ip-64-139-1-69.sjc.megapath.net>


Gary said:
> When distros support Python 2, we need to support Python 2.

Not quite.  When distros support Python2 and Python3 is not available, then it 
would be nice if we supported Python2.

There is still the question of how big that market is and how much effort it 
takes to support it.

I agree that the effort to support Python2 is small.  But every now and then 
Eric gets a bee in his bonnet to get rid of stuff like that.

----------

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?

How much effort do we want to put in supporting systems without NTS?


-- 
These are my opinions.  I hate spam.




From rlaager at wiktel.com  Fri Sep  4 07:14:13 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Fri, 4 Sep 2020 02:14:13 -0500
Subject: Python support policy
In-Reply-To: <20200904063755.6457E40605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200904063755.6457E40605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <83041e37-2615-0d78-641d-aad0f4429ae4@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200904/fe103e27/attachment-0001.bin>

From stse+ntpsec at rootsland.net  Fri Sep  4 07:37:47 2020
From: stse+ntpsec at rootsland.net (Stephan Seitz)
Date: Fri, 4 Sep 2020 09:37:47 +0200
Subject: Python support policy
In-Reply-To: <20200903230648.373c3b83@spidey.rellim.com>
References: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
 <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
 <20200903230648.373c3b83@spidey.rellim.com>
Message-ID: <20200904T093118.blubb.9ee54.stse@fsing.rootsland.net>

On Do, Sep 03, 2020 at 23:06:48 -0700, Gary E. Miller via devel wrote:
>Why the hate for Python 2?  Supporting it is trivial.  Let the distros
>stop supporting Python 2 before we do.  When distros support Python 2, we

I think this is the wrong way.
Distros can stop supporting python 2 when every upstream has stopped 
using python 2.

I don?t know how much work it is to support python 2, but python 2 is 
dead and I wouldn?t waste my time supporting it.

Shade and sweet water!

	Stephan

-- 
|    If your life was a horse, you'd have to shoot it.    |

From hmurray at megapathdsl.net  Fri Sep  4 10:34:53 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 04 Sep 2020 03:34:53 -0700
Subject: seccomp tangle - Alpine Linux
Message-ID: <20200904103453.61E7940605C@ip-64-139-1-69.sjc.megapath.net>


I don't know what changed to trigger this.

I assume you can't easily test on Alpine, so I poked around a bit.

It's working after the edit below.  I don't know if this will break on some 
other system.  Probably not.  These look like vanilla system calls.  Some 
syscalls don't exist on some systems so you will see an #ifdef so skip them.

This is mostly a heads up that just adding things from reports may break some 
other systems.

 /* Arch Linux */
+       SCMP_SYS(getgid),
+       SCMP_SYS(getuid),
        SCMP_SYS(getpid),
        SCMP_SYS(gettid),
+       SCMP_SYS(getegid),
        SCMP_SYS(geteuid),

It's happening during initializatioin, right after:
 3 Sep 21:41:39 ntpd[4714]: NTSc: Using system default root certificates.   
 3 Sep 21:41:39 ntpd[4714]: ERR: SIGSYS: got a trap.                    
 3 Sep 21:41:39 ntpd[4714]: ERR: SIGSYS/seccomp bad syscall 102/0xc000003e     

 3 Sep 21:41:39 ntpd[4714]: ERR: Stack trace:                                  

 3 Sep 21:41:39 ntpd[4714]: ERR: #1 0x791780a11304 in ?? 

gdb doesn't give me a stack trace, so I don't know where the calls are coming 
from.

The normal next line is:
 3 Sep 21:56:03 ntpd[6180]: NTSs: loaded certificate (chain) from 
/etc/ntp/alp....
So it's probably in libssl.

But gdb does print out the syscall name, so knowing which syscall to add is 
simple.


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Fri Sep  4 12:23:05 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 4 Sep 2020 08:23:05 -0400
Subject: Python support policy
In-Reply-To: <20200903230411.3ba33dc3@spidey.rellim.com>
References: <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
 <20200903101413.GC29509@thyrsus.com>
 <20200903103950.208d7b5a@rellim.com>
 <148d8c2f-9c95-d750-d492-f31eaa77f549@wiktel.com>
 <20200903221613.74749b30@spidey.rellim.com>
 <e9ee8703-e155-3353-8abf-d70a4a07a33f@wiktel.com>
 <20200903230411.3ba33dc3@spidey.rellim.com>
Message-ID: <20200904122305.GB137149@thyrsus.com>

Gary E. Miller via devel <devel at ntpsec.org>:
> As previously mentioned here: RHEL 6.

Which is about to EOL.

> Supporting Python 2 is trivial.  Why the hate?

Because it's not in fact trivial. It's *doable*; Peter Donis and I are
the expers on how to do it.  But it's not trivial.  It proliferates
code and test paths, and therefore increases attack surface.

Therefore we should drop Python 2 support as soon as the benefit of
keeping it drops below the cost.  I think that happens the moment
python3 becomes a reliable thing to put in shebangs on all our
primary platforms.

There's a strong case this has already occurred, and that case will
be closed when RHEL 6 goes EOL.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200904/776d040d/attachment.bin>

From gem at rellim.com  Fri Sep  4 16:29:20 2020
From: gem at rellim.com (Gary E. Miller)
Date: Fri, 4 Sep 2020 09:29:20 -0700
Subject: Python support policy
In-Reply-To: <20200904122305.GB137149@thyrsus.com>
References: <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200903005145.GC16627@thyrsus.com>
 <20200902175437.403a57eb@rellim.com>
 <3ddc26f0-5305-0760-5c1a-079a31401180@wiktel.com>
 <20200903101413.GC29509@thyrsus.com>
 <20200903103950.208d7b5a@rellim.com>
 <148d8c2f-9c95-d750-d492-f31eaa77f549@wiktel.com>
 <20200903221613.74749b30@spidey.rellim.com>
 <e9ee8703-e155-3353-8abf-d70a4a07a33f@wiktel.com>
 <20200903230411.3ba33dc3@spidey.rellim.com>
 <20200904122305.GB137149@thyrsus.com>
Message-ID: <20200904092920.1f541f59@spidey.rellim.com>

Yo Eric!

On Fri, 4 Sep 2020 08:23:05 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller via devel <devel at ntpsec.org>:
> > As previously mentioned here: RHEL 6.  
> 
> Which is about to EOL.

Then let us table the discussion until all the major distros have
EOLed Python 2.

> 
> > Supporting Python 2 is trivial.  Why the hate?  
> 
> Because it's not in fact trivial. It's *doable*; Peter Donis and I are
> the expers on how to do it.

If you think it is hard, then you are not experts.  Check out how
gpsd does it to learn from Eric how easy it is.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200904/6dc97f19/attachment.bin>

From gem at rellim.com  Fri Sep  4 16:48:54 2020
From: gem at rellim.com (Gary E. Miller)
Date: Fri, 4 Sep 2020 09:48:54 -0700
Subject: Python support policy
In-Reply-To: <20200904T093118.blubb.9ee54.stse@fsing.rootsland.net>
References: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
 <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
 <20200903230648.373c3b83@spidey.rellim.com>
 <20200904T093118.blubb.9ee54.stse@fsing.rootsland.net>
Message-ID: <20200904094854.6207aee9@spidey.rellim.com>

Yo Stephan!

On Fri, 4 Sep 2020 09:37:47 +0200
Stephan Seitz via devel <devel at ntpsec.org> wrote:

> I don?t know how much work it is to support python 2, but python 2 is 
> dead and

Just because you do not use something does not make it dead.

When distros no longer support Python 2, then it will be dead.

> I wouldn?t waste my time supporting it.

Good.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200904/3fcbd3f4/attachment.bin>

From gem at rellim.com  Fri Sep  4 16:51:29 2020
From: gem at rellim.com (Gary E. Miller)
Date: Fri, 4 Sep 2020 09:51:29 -0700
Subject: Python support policy
In-Reply-To: <83041e37-2615-0d78-641d-aad0f4429ae4@wiktel.com>
References: <20200904063755.6457E40605C@ip-64-139-1-69.sjc.megapath.net>
 <83041e37-2615-0d78-641d-aad0f4429ae4@wiktel.com>
Message-ID: <20200904095129.25de6a9e@spidey.rellim.com>

Yo Richard!

On Fri, 4 Sep 2020 02:14:13 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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).

And as we continue to see, a lot of distros do not have any openssl 1.1.1
yet.

So, non-sequitor.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200904/d58ba03d/attachment.bin>

From hmurray at megapathdsl.net  Fri Sep  4 20:31:37 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 04 Sep 2020 13:31:37 -0700
Subject: NEWS for release
Message-ID: <20200904203137.5B94240605C@ip-64-139-1-69.sjc.megapath.net>


Are any of the recent changes interesting enough to mention in NEWS?



-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Fri Sep  4 20:49:22 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 4 Sep 2020 16:49:22 -0400
Subject: NEWS for release
In-Reply-To: <20200904203137.5B94240605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200904203137.5B94240605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200904204922.GA149098@thyrsus.com>

Hal Murray via devel <devel at ntpsec.org>:
> Are any of the recent changes interesting enough to mention in NEWS?

Looking at the changelog, the only one that jumps out at me is James's new
UI options for ntpq.

Otherwise the recent stuff is bug triage and validator cleanups (LGTM
looks like a big win).  I wouldn't want to try doing anything deeper
this close to a release. None of it's user-visible.

After we ship I''ll get off my butt about the recvbuff cleanup.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From jamesb.fe80 at gmail.com  Fri Sep  4 20:48:38 2020
From: jamesb.fe80 at gmail.com (James Browning)
Date: Fri, 4 Sep 2020 13:48:38 -0700
Subject: NEWS for release
In-Reply-To: <20200904203137.5B94240605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200904203137.5B94240605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAFTY+dCj_X5-fUf6AF7SQok1P_DjCdRdVWuZBAxJ5dZ8FCG4Hg@mail.gmail.com>

On Fri, Sep 4, 2020 at 1:31 PM Hal Murray via devel <devel at ntpsec.org> wrote:
>
>
> Are any of the recent changes interesting enough to mention in NEWS?

Probably not so I'm just gonna empty the bucket. j/k
* duplicate server error message
* documentation updates/fixes
* shebang updates
* ntpkeygen can use secrets
* ntpq returns provided server names if asked
* ntpviz searches prefix for liberation font
* ntpdig json fix
* openssl 3 support?

From hmurray at megapathdsl.net  Fri Sep  4 22:58:54 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 04 Sep 2020 15:58:54 -0700
Subject: Runtime testing, What's the CI environment like?
Message-ID: <20200904225854.38F3E40605C@ip-64-139-1-69.sjc.megapath.net>


Can we run ntpd long enough to test the initialization and much of the other code?

I'm thinking of something like start ntpd, wait a while, then kill it.  While it is running, we can also test ntpq.  The idea is to take advantage of the handful of environments that are readily available.

Is our code running as root?  Is ntpd (or whatever) running?  If so, can we turn it off?

-------

I got a message from gitlab today about limiting/charging for CI time.  Is that CPU seconds or wall-clock seconds?

----------

Should we make a list of OS/distro/version known to work?
And another for refclocks?


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Fri Sep  4 23:14:14 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 04 Sep 2020 16:14:14 -0700
Subject: I'm giving up on seccomp
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Thu, 03 Sep 2020 05:39:43 EDT." <20200903093943.GA29509@thyrsus.com>
Message-ID: <20200904231414.30C0140605C@ip-64-139-1-69.sjc.megapath.net>


>> If you want to claim your Go program has no buffer overruns,
>> you can't call out to big complicated libraries written in c.  You
>> would have to rewrite them in Go.

> Fair point. That changes my to-do list. 

Could you please say more?  What did you add or drop?


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Fri Sep  4 23:30:13 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 04 Sep 2020 16:30:13 -0700
Subject: NEWS for release
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Fri, 04 Sep 2020 16:49:22 EDT." <20200904204922.GA149098@thyrsus.com>
Message-ID: <20200904233013.12B8540605C@ip-64-139-1-69.sjc.megapath.net>


> Looking at the changelog, the only one that jumps out at me is James's new UI
> options for ntpq. 

Should we have a policy of mentioning all UI changes?  I don't want a lot of 
clutter, a quick mention should be enough to get people to check the 
documentation.

How about config file changes?

--------

> After we ship I''ll get off my butt about the recvbuff cleanup.

What do you have in mind?

I think I have fixed all the get/free stupidities that used to be in the main 
line server code so it isn't wasting CPU cycles.  There is still a free list.  
I forget how it is used.  I think some/most refclocks use it, maybe only the 
ones that read serial data.  It would be good to totally nuke the free list.

---------

We should make a pass through devel/TODO.adoc and devel/TODO-NTS


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Fri Sep  4 23:34:36 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 4 Sep 2020 19:34:36 -0400
Subject: I'm giving up on seccomp
In-Reply-To: <20200904231414.30C0140605C@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20200903093943.GA29509@thyrsus.com>
 <20200904231414.30C0140605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200904233436.GB174016@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> 
> >> If you want to claim your Go program has no buffer overruns,
> >> you can't call out to big complicated libraries written in c.  You
> >> would have to rewrite them in Go.
> 
> > Fair point. That changes my to-do list. 
> 
> Could you please say more?  What did you add or drop?

Means seccomp in Go has to be on it.  Though not at high priority.

The current blocker on the port is that Flex and Bison can't yet emit
Go code.  I'm probably going to have to fix that myself.  There are roughly
equivalent tools such as goyacc that are fine for new projects, but
guaranteeing that you get the same accept grmmar from specifications in
two different generators is so difficult that I'd rather retarget
Flex and Bison than deal with that problem.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From hmurray at megapathdsl.net  Fri Sep  4 23:47:41 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 04 Sep 2020 16:47:41 -0700
Subject: I'm giving up on seccomp
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Fri, 04 Sep 2020 19:34:36 EDT." <20200904233436.GB174016@thyrsus.com>
Message-ID: <20200904234741.B4C7640605C@ip-64-139-1-69.sjc.megapath.net>


> The current blocker on the port is that Flex and Bison can't yet emit Go
> code.  I'm probably going to have to fix that myself.  There are roughly
> equivalent tools such as goyacc that are fine for new projects, but
> guaranteeing that you get the same accept grmmar from specifications in two
> different generators is so difficult that I'd rather retarget Flex and Bison
> than deal with that problem. 

Is this an opportunity to clean up that area?

Probably not, but may be worth considering.

You don't need much of a parser to get off the ground.  Do we need anything 
more than "server foo"?



-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Sat Sep  5 00:44:57 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 4 Sep 2020 20:44:57 -0400
Subject: I'm giving up on seccomp
In-Reply-To: <20200904234741.B4C7640605C@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20200904233436.GB174016@thyrsus.com>
 <20200904234741.B4C7640605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200905004457.GA175889@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> Is this an opportunity to clean up that area?

I don't think so. It's pretty clean now, functionally speaking - I put
a lot of work into rationalizing the configurator structures and the
way they talk to the protocol machine.

I suppose it might be if we were willing to make
cimparibility-breaking changes to the configuration grammar, but I
have not been presented with any good reason to do that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Sat Sep  5 00:50:09 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 4 Sep 2020 20:50:09 -0400
Subject: NEWS for release
In-Reply-To: <20200904233013.12B8540605C@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20200904204922.GA149098@thyrsus.com>
 <20200904233013.12B8540605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200905005009.GB175889@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> 
> > Looking at the changelog, the only one that jumps out at me is James's new UI
> > options for ntpq. 
> 
> Should we have a policy of mentioning all UI changes?

I think so.  I've been trying to do that whenever I write NEWS entries.

> How about config file changes?

Well, sure. Not that I'm expecting any in the foreseeable future

> > After we ship I''ll get off my butt about the recvbuff cleanup.
> 
> What do you have in mind?
> 
> I think I have fixed all the get/free stupidities that used to be in the main 
> line server code so it isn't wasting CPU cycles.  There is still a free list.  
> I forget how it is used.  I think some/most refclocks use it, maybe only the 
> ones that read serial data.  It would be good to totally nuke the free list.

Totally nuking the free list was what I haf in mind.
 
> We should make a pass through devel/TODO.adoc and devel/TODO-NTS

Agreed,
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From Stromeko at Nexgo.DE  Sat Sep  5 09:16:43 2020
From: Stromeko at Nexgo.DE (Achim Gratz)
Date: Sat, 5 Sep 2020 11:16:43 +0200
Subject: Python support policy
In-Reply-To: <20200904094854.6207aee9@spidey.rellim.com>
References: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
 <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
 <20200903230648.373c3b83@spidey.rellim.com>
 <20200904T093118.blubb.9ee54.stse@fsing.rootsland.net>
 <20200904094854.6207aee9@spidey.rellim.com>
Message-ID: <rivl1q$7ig$1@ciao.gmane.io>

Am 04.09.2020 um 18:48 schrieb Gary E. Miller via devel:
> Just because you do not use something does not make it dead.

This is what upstream says about it:

https://www.python.org/doc/sunset-python-2/

> When distros no longer support Python 2, then it will be dead.

It is already officially dead since January (five years past the 
original deadline), see above.


-- 
Achim.

(on the road :-)


From gem at rellim.com  Sat Sep  5 19:19:54 2020
From: gem at rellim.com (Gary E. Miller)
Date: Sat, 5 Sep 2020 12:19:54 -0700
Subject: Python support policy
In-Reply-To: <rivl1q$7ig$1@ciao.gmane.io>
References: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
 <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
 <20200903230648.373c3b83@spidey.rellim.com>
 <20200904T093118.blubb.9ee54.stse@fsing.rootsland.net>
 <20200904094854.6207aee9@spidey.rellim.com>
 <rivl1q$7ig$1@ciao.gmane.io>
Message-ID: <20200905121954.2e480feb@spidey.rellim.com>

Yo Achim!

On Sat, 5 Sep 2020 11:16:43 +0200
Achim Gratz via devel <devel at ntpsec.org> wrote:

> Am 04.09.2020 um 18:48 schrieb Gary E. Miller via devel:
> > Just because you do not use something does not make it dead.  
> 
> This is what upstream says about it:
> 
> https://www.python.org/doc/sunset-python-2/

Yup, nothing new there.

> > When distros no longer support Python 2, then it will be dead.  
> 
> It is already officially dead since January (five years past the 
> original deadline), see above.


And yet, Gentoo, and others still ship 2.7.  And end users still use it.

I'd much rather argue with you than all the users that complain quickly
every time gpsd or ntpsec breaks 2.7 support.

We have spent 100x more time arguing about it than the cost of keeping
2.7 support.  You need to recheck your time management.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200905/fa6d24ee/attachment.bin>

From gem at rellim.com  Sat Sep  5 19:27:07 2020
From: gem at rellim.com (Gary E. Miller)
Date: Sat, 5 Sep 2020 12:27:07 -0700
Subject: Python support policy
In-Reply-To: <rivl1q$7ig$1@ciao.gmane.io>
References: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
 <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
 <20200903230648.373c3b83@spidey.rellim.com>
 <20200904T093118.blubb.9ee54.stse@fsing.rootsland.net>
 <20200904094854.6207aee9@spidey.rellim.com>
 <rivl1q$7ig$1@ciao.gmane.io>
Message-ID: <20200905122707.763af746@spidey.rellim.com>

Yo Achim!

On Sat, 5 Sep 2020 11:16:43 +0200
Achim Gratz via devel <devel at ntpsec.org> wrote:

> It is already officially dead since January (five years past the 
> original deadline), see above.

Uh, no.  Last Python 2.7,18 was released 20 April 2020.

So restart the five year clock.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200905/f047a1ff/attachment.bin>

From rlaager at wiktel.com  Sat Sep  5 22:02:57 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Sat, 5 Sep 2020 17:02:57 -0500
Subject: Python support policy
In-Reply-To: <20200905121954.2e480feb@spidey.rellim.com>
References: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
 <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
 <20200903230648.373c3b83@spidey.rellim.com>
 <20200904T093118.blubb.9ee54.stse@fsing.rootsland.net>
 <20200904094854.6207aee9@spidey.rellim.com> <rivl1q$7ig$1@ciao.gmane.io>
 <20200905121954.2e480feb@spidey.rellim.com>
Message-ID: <fce1ee63-275c-cc98-686e-c6f6952b01ff@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200905/5b0a1f9b/attachment.bin>

From gem at rellim.com  Sat Sep  5 22:39:13 2020
From: gem at rellim.com (Gary E. Miller)
Date: Sat, 5 Sep 2020 15:39:13 -0700
Subject: Python support policy
In-Reply-To: <fce1ee63-275c-cc98-686e-c6f6952b01ff@wiktel.com>
References: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
 <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
 <20200903230648.373c3b83@spidey.rellim.com>
 <20200904T093118.blubb.9ee54.stse@fsing.rootsland.net>
 <20200904094854.6207aee9@spidey.rellim.com>
 <rivl1q$7ig$1@ciao.gmane.io>
 <20200905121954.2e480feb@spidey.rellim.com>
 <fce1ee63-275c-cc98-686e-c6f6952b01ff@wiktel.com>
Message-ID: <20200905153913.4aa07ff4@spidey.rellim.com>

Yo Richard!

On Sat, 5 Sep 2020 17:02:57 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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.

And yet, the straw man lives, and you keep bringing it.

It would be nice if you answered my objections instead of simply
restating yours.

> NTPsec currently supports: Python 2 >= 2.6 or Python 3 >= 3.3

Yup.  And let us keep it that way.

>   The bigger problem is that the installed scripts have a hardcoded
>   shebang of `/usr/bin/env python` so none of them work.

And you have a pending WIP MR to fix that.  Please continue working on
it because it is broken.  As I documented in the MR.

> That can be
>   addressed by subst'ing the shebangs as in !1166:
>   https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1166

Except that breaks Gentoo and a lot of other systems.  Please fix.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200905/3cb60921/attachment-0001.bin>

From rlaager at wiktel.com  Sat Sep  5 23:22:50 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Sat, 5 Sep 2020 18:22:50 -0500
Subject: Python support policy
In-Reply-To: <20200905153913.4aa07ff4@spidey.rellim.com>
References: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
 <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
 <20200903230648.373c3b83@spidey.rellim.com>
 <20200904T093118.blubb.9ee54.stse@fsing.rootsland.net>
 <20200904094854.6207aee9@spidey.rellim.com> <rivl1q$7ig$1@ciao.gmane.io>
 <20200905121954.2e480feb@spidey.rellim.com>
 <fce1ee63-275c-cc98-686e-c6f6952b01ff@wiktel.com>
 <20200905153913.4aa07ff4@spidey.rellim.com>
Message-ID: <a8db5488-cff5-461c-215a-27c19b40908b@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200905/004eaff3/attachment.bin>

From gem at rellim.com  Sat Sep  5 23:31:58 2020
From: gem at rellim.com (Gary E. Miller)
Date: Sat, 5 Sep 2020 16:31:58 -0700
Subject: Python support policy
In-Reply-To: <a8db5488-cff5-461c-215a-27c19b40908b@wiktel.com>
References: <019186e5-e0b0-f35e-7c86-22e105a80b03@wiktel.com>
 <20200902122455.4210dce9@rellim.com>
 <6d0a39a9-f103-0c51-f373-6713ab3d48c1@wiktel.com>
 <20200902174427.00ed325a@rellim.com>
 <0d59ec97-3edc-24b0-03e9-be7a5b592a5d@wiktel.com>
 <20200903111214.04485fed@rellim.com>
 <cd30ca2a-8278-6429-f4a8-81ebfec8a60a@wiktel.com>
 <20200903211554.66581afe@spidey.rellim.com>
 <e7ab3636-40e6-8c05-f84a-7e8197f4a261@wiktel.com>
 <20200903230648.373c3b83@spidey.rellim.com>
 <20200904T093118.blubb.9ee54.stse@fsing.rootsland.net>
 <20200904094854.6207aee9@spidey.rellim.com>
 <rivl1q$7ig$1@ciao.gmane.io>
 <20200905121954.2e480feb@spidey.rellim.com>
 <fce1ee63-275c-cc98-686e-c6f6952b01ff@wiktel.com>
 <20200905153913.4aa07ff4@spidey.rellim.com>
 <a8db5488-cff5-461c-215a-27c19b40908b@wiktel.com>
Message-ID: <20200905163158.67306809@spidey.rellim.com>

Yo Richard!

On Sat, 5 Sep 2020 18:22:50 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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?

Nope.  When I tell users their system is wrong I always get pushback.
When we shipd software, it should "just work"(tm).

How about your fix your MR instead.  I told you what was wrong, yet you
do not reply to that.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200905/7c673375/attachment.bin>

From hmurray at megapathdsl.net  Sun Sep  6 05:41:05 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sat, 05 Sep 2020 22:41:05 -0700
Subject: Unity warnings
Message-ID: <20200906054105.E852140605C@ip-64-139-1-69.sjc.megapath.net>


I assume a  fix for this should be pushed upstream.

../../tests/unity/unity.c: In function ???UnityFail???:
../../tests/unity/unity.c:1757:6: warning: function might be candidate for 
attribute ???noreturn??? [-Wsuggest-attribute=noreturn]
 1757 | void UnityFail(const char* msg, const UNITY_LINE_TYPE line)
      |      ^~~~~~~~~
../../tests/unity/unity.c: In function ???UnityIgnore???:
../../tests/unity/unity.c:1794:6: warning: function might be candidate for 
attribute ???noreturn??? [-Wsuggest-attribute=noreturn]
 1794 | void UnityIgnore(const char* msg, const UNITY_LINE_TYPE line)
      |      ^~~~~~~~~~~


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Sun Sep  6 07:58:11 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sun, 6 Sep 2020 03:58:11 -0400
Subject: Unity warnings
In-Reply-To: <20200906054105.E852140605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200906054105.E852140605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200906075811.GA457813@thyrsus.com>

Hal Murray via devel <devel at ntpsec.org>:
> 
> I assume a  fix for this should be pushed upstream.
> 
> ../../tests/unity/unity.c: In function ???UnityFail???:
> ../../tests/unity/unity.c:1757:6: warning: function might be candidate for 
> attribute ???noreturn??? [-Wsuggest-attribute=noreturn]
>  1757 | void UnityFail(const char* msg, const UNITY_LINE_TYPE line)
>       |      ^~~~~~~~~
> ../../tests/unity/unity.c: In function ???UnityIgnore???:
> ../../tests/unity/unity.c:1794:6: warning: function might be candidate for 
> attribute ???noreturn??? [-Wsuggest-attribute=noreturn]
>  1794 | void UnityIgnore(const char* msg, const UNITY_LINE_TYPE line)
>       |      ^~~~~~~~~~~
> 

Yes.  I'll do it if yiu have not alreadsy idebtified upsrream.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From hmurray at megapathdsl.net  Sun Sep  6 09:12:46 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sun, 06 Sep 2020 02:12:46 -0700
Subject: Unity warnings
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Sun, 06 Sep 2020 03:58:11 EDT." <20200906075811.GA457813@thyrsus.com>
Message-ID: <20200906091246.C7C8840605C@ip-64-139-1-69.sjc.megapath.net>

> Yes.  I'll do it if yiu have not alreadsy idebtified upsrream.

Please do and/or please fix our local copy.  I'm focused on the 
restrict/unrestrict tangle.


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Sun Sep  6 12:23:33 2020
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sun, 6 Sep 2020 08:23:33 -0400
Subject: Unity warnings
In-Reply-To: <20200906091246.C7C8840605C@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20200906075811.GA457813@thyrsus.com>
 <20200906091246.C7C8840605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20200906122333.GA490128@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> Please do and/or please fix our local copy.  I'm focused on the 
> restrict/unrestrict tangle.

Bug fixed, but I cant finf any way to subnutt uissues on ther
bugracker.  Yes, I have a validayed account ob the site.
Sill looking.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From jamesb.fe80 at gmail.com  Sun Sep  6 12:33:20 2020
From: jamesb.fe80 at gmail.com (James Browning)
Date: Sun, 6 Sep 2020 05:33:20 -0700
Subject: Unity warnings
In-Reply-To: <20200906122333.GA490128@thyrsus.com>
References: <esr@thyrsus.com> <20200906075811.GA457813@thyrsus.com>
 <20200906091246.C7C8840605C@ip-64-139-1-69.sjc.megapath.net>
 <20200906122333.GA490128@thyrsus.com>
Message-ID: <CAFTY+dD4S6TYg8+tbkF7+gtCK+5qD+weVFPVGC6o2fHqaB+wTg@mail.gmail.com>

On Sun, Sep 6, 2020 at 5:21 AM Eric S. Raymond via devel
<devel at ntpsec.org> wrote:
>
> Hal Murray <hmurray at megapathdsl.net>:
> > Please do and/or please fix our local copy.  I'm focused on the
> > restrict/unrestrict tangle.
>
> Bug fixed, but I cant finf any way to subnutt uissues on ther
> bugracker.  Yes, I have a validayed account ob the site.
> Sill looking.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

It sems they have an active list of issues and pull requests over at GitHub.
One pull request (merged) claims to add noreturn attributed to those
functions.[2]

[2] https://github.com/ThrowTheSwitch/Unity/pull/503

From jamesb.fe80 at gmail.com  Sun Sep  6 15:12:48 2020
From: jamesb.fe80 at gmail.com (James Browning)
Date: Sun, 6 Sep 2020 08:12:48 -0700
Subject: Runtime testing, What's the CI environment like?
In-Reply-To: <20200904225854.38F3E40605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200904225854.38F3E40605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAFTY+dDr=DT2w=bw2MRxeRcLGG=BmozvhDzrHox3iM45KLAMxQ@mail.gmail.com>

On Fri, Sep 4, 2020 at 3:59 PM Hal Murray via devel <devel at ntpsec.org> wrote:
> Can we run ntpd long enough to test the initialization and much of the other code?

Possibly, but to test some of the code paths (NTS) would take about a
day. Who wants to donate machine time for the runner?

> I'm thinking of something like start ntpd, wait a while, then kill it.  While it is running, we can also test ntpq.  The idea is to take advantage of the handful of environments that are readily available.

Might I also suggest running something like gpsd, ntplog* and ntpviz as well?

> Is our code running as root?  Is ntpd (or whatever) running?  If so, can we turn it off?

I think it runs as root. By default I seem to recall reading that is
is a Google compute instance so maybe? No, I don't think we could turn
it off if it is.

> I got a message from gitlab today about limiting/charging for CI time.  Is that CPU seconds or wall-clock seconds?

Hence the sugestion for people to provide compute time. I do not know
which, I _assume_ wall clock time.

> Should we make a list of OS/distro/version known to work?

Linux distros work, macOS some versions work, FreeBSD yes, NetBSD
sorta, MS no, and everyone else can check.

> And another for refclocks?

All refclocks are beleived to work.

From ghane0 at gmail.com  Sun Sep  6 20:14:46 2020
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Mon, 7 Sep 2020 04:14:46 +0800
Subject: Runtime testing, What's the CI environment like?
In-Reply-To: <CAFTY+dDr=DT2w=bw2MRxeRcLGG=BmozvhDzrHox3iM45KLAMxQ@mail.gmail.com>
References: <20200904225854.38F3E40605C@ip-64-139-1-69.sjc.megapath.net>
 <CAFTY+dDr=DT2w=bw2MRxeRcLGG=BmozvhDzrHox3iM45KLAMxQ@mail.gmail.com>
Message-ID: <CAHZk5WfsdcBDAN4c8jLRqoOvmXHUTUixutgiosDvCmBOZ41z9A@mail.gmail.com>

On Sun, Sep 6, 2020 at 11:13 PM James Browning via devel <devel at ntpsec.org>
wrote:

> On Fri, Sep 4, 2020 at 3:59 PM Hal Murray via devel <devel at ntpsec.org>
> wrote:
> > Can we run ntpd long enough to test the initialization and much of the
> other code?
>
> Possibly, but to test some of the code paths (NTS) would take about a
> day. Who wants to donate machine time for the runner?
>


I could set up a VM farm, a dozen low-power machines with a mix of Linux
and BSDs.  Basically a large VMWare, and we can cut machines at need.  I
can commit to IPv4/IPv6, a nearby GPSd, etc.

And when I say "I can setup", I mean I can provide the infrastructure,
someone else will have to setup or talk me through the setup :-)

--
Sanjeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200907/5ff2822b/attachment.htm>

From hmurray at megapathdsl.net  Sun Sep  6 22:43:28 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sun, 06 Sep 2020 15:43:28 -0700
Subject: Runtime testing, What's the CI environment like?
In-Reply-To: Message from James Browning via devel <devel@ntpsec.org> of "Sun,
 06 Sep 2020 08:12:48 PDT."
 <CAFTY+dDr=DT2w=bw2MRxeRcLGG=BmozvhDzrHox3iM45KLAMxQ@mail.gmail.com>
Message-ID: <20200906224328.9ACD240605C@ip-64-139-1-69.sjc.megapath.net>


> Possibly, but to test some of the code paths (NTS) would take about a day.
> Who wants to donate machine time for the runner? 

We can test most of the NTS code paths in a few seconds.

What did you have in mind for "about a day"?  The NTS cookie key gets updated 
every 24 hours.  The last-update-time is stored in the file.  We could test 
the update path without waiting a long time by setting up a file that will 
expire in a few seconds.

> Linux distros work, macOS some versions work, FreeBSD yes, NetBSD sorta, MS
> no, and everyone else can check. 

What's the "sorta" for NetBSD?

What do you mean by "can check"?  The idea of this sort of data base is to 
save time on checking and/or to point out holes in our known coverage in hopes 
that somebody will test and report.

I was thinking of a file or web page with a list of known tested cases.  Maybe 
a line per case with OS/distro, version, CPU type, version/date of ntpsec, and 
date of test.

There is a slight chicken/egg problem.  You can't test a released version 
until it is released.

> All refclocks are beleived to work.

Again, some of the gear is pretty old.  I'm sure Eric would be happy to nuke a 
few more drivers.  I'd like to see somebody raise their hand and say "working 
for me" so we could add a version/date line in a file.

Anybody using the modem driver?

I don't think we need a full OS/version/driver matrix.  There are probably 
enough quirks for some drivers that some notes would be useful.  For example, 
the hpgps works with several GPSDOs.  A list of known-working would be nice.

I'm only interested in the current version of ntpsec.  Maybe latest release 
and git head.  I expect some of the reports in the collection would not get 
updated with every release.


-- 
These are my opinions.  I hate spam.




From rlaager at wiktel.com  Sun Sep  6 23:18:40 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Sun, 6 Sep 2020 18:18:40 -0500
Subject: Runtime testing, What's the CI environment like?
In-Reply-To: <20200906224328.9ACD240605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200906224328.9ACD240605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <b1be5617-0eff-b726-7f1d-db316b6b1e5f@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200906/05f00639/attachment-0001.bin>

From Stromeko at Nexgo.DE  Mon Sep  7 05:48:40 2020
From: Stromeko at Nexgo.DE (Achim Gratz)
Date: Mon, 7 Sep 2020 07:48:40 +0200
Subject: Runtime testing, What's the CI environment like?
In-Reply-To: <20200906224328.9ACD240605C@ip-64-139-1-69.sjc.megapath.net>
References: <devel@ntpsec.org>
 <20200906224328.9ACD240605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <rj4hjn$jn3$2@ciao.gmane.io>

> There is a slight chicken/egg problem.  You can't test a released version
> until it is released.

Yes you can.  The push of the commit and the tagging/pushing of the 
release tag can easily be separate events.


-- 
Achim.

(on the road :-)


From jamesb.fe80 at gmail.com  Mon Sep  7 16:03:48 2020
From: jamesb.fe80 at gmail.com (James Browning)
Date: Mon, 7 Sep 2020 09:03:48 -0700
Subject: FFI module architecture decision was 'Python support policy'
Message-ID: <CAFTY+dAucDhAANhYeD4xODtYUs8y8_y++VWh+0+2fCF-=YrLLw@mail.gmail.com>

I (re)developed a Python wrapper around a C FFI stub[1]. It is largely
based around my merge request !1010 [2].

Time to compile should be reduced because instead of compiling the
entire source N times or compiling the Python extension N times (for
an unimplemented concept), the source only compiled once.

The FFI stub would allow for simplified development of non-Python libraries.

What does everyone think about this? Can anyone make it break?

[1] https://gitlab.com/NTPsec/ntpsec/-/commits/ntpc
[2] https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1010

From gem at rellim.com  Mon Sep  7 17:23:18 2020
From: gem at rellim.com (Gary E. Miller)
Date: Mon, 7 Sep 2020 10:23:18 -0700
Subject: FFI module architecture decision was 'Python support policy'
In-Reply-To: <CAFTY+dAucDhAANhYeD4xODtYUs8y8_y++VWh+0+2fCF-=YrLLw@mail.gmail.com>
References: <CAFTY+dAucDhAANhYeD4xODtYUs8y8_y++VWh+0+2fCF-=YrLLw@mail.gmail.com>
Message-ID: <20200907102318.78b4b28d@spidey.rellim.com>

Yo James!

You did the same for gpsd, working nicely there.

Right before Hal wants a release may not be the best tie for it.

On Mon, 7 Sep 2020 09:03:48 -0700
James Browning via devel <devel at ntpsec.org> wrote:

> I (re)developed a Python wrapper around a C FFI stub[1]. It is largely
> based around my merge request !1010 [2].
> 
> Time to compile should be reduced because instead of compiling the
> entire source N times or compiling the Python extension N times (for
> an unimplemented concept), the source only compiled once.
> 
> The FFI stub would allow for simplified development of non-Python
> libraries.
> 
> What does everyone think about this? Can anyone make it break?
> 
> [1] https://gitlab.com/NTPsec/ntpsec/-/commits/ntpc
> [2] https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1010
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel




RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200907/eaaf5bc8/attachment.bin>

From hmurray at megapathdsl.net  Mon Sep  7 23:25:11 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Mon, 07 Sep 2020 16:25:11 -0700
Subject: Final restriction cleanup (I hope)
Message-ID: <20200907232511.EFA5240605C@ip-64-139-1-69.sjc.megapath.net>


Does anybody use any fancy restrictions?
Anybody ever used "restrict source xxx"?

I just pushed what I expect is the final cleanup to the restriction code area.
Time to go work on the documentation.

The most likely visible change will be the removal of boxus "poking hole" 
messages.

The basic problem is what to do if " server xxx" comes up with an IP Address 
that won't work because some restriction rule will block the responses.

There is code that will poke a hole in the restriction rules by adding a rule 
to let this specific IP Address through.  But only if the rule that would do 
the blocking is not blocking a single IP Address.  If you have that specific a 
rule, remove it.

That code only works if you have setup the new restriction flags you want to 
use with "restrict source xxx".  (xxx can be empty)



-- 
These are my opinions.  I hate spam.




From rlaager at wiktel.com  Tue Sep  8 00:23:40 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Mon, 7 Sep 2020 19:23:40 -0500
Subject: FFI module architecture decision was 'Python support policy'
In-Reply-To: <CAFTY+dAucDhAANhYeD4xODtYUs8y8_y++VWh+0+2fCF-=YrLLw@mail.gmail.com>
References: <CAFTY+dAucDhAANhYeD4xODtYUs8y8_y++VWh+0+2fCF-=YrLLw@mail.gmail.com>
Message-ID: <9cc6cb17-ea88-1d53-35da-e2fdf1f343ae@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200907/f4bcf678/attachment.bin>

From jamesb.fe80 at gmail.com  Tue Sep  8 00:42:10 2020
From: jamesb.fe80 at gmail.com (James Browning)
Date: Mon, 7 Sep 2020 17:42:10 -0700
Subject: FFI module architecture decision was 'Python support policy'
In-Reply-To: <9cc6cb17-ea88-1d53-35da-e2fdf1f343ae@wiktel.com>
References: <CAFTY+dAucDhAANhYeD4xODtYUs8y8_y++VWh+0+2fCF-=YrLLw@mail.gmail.com>
 <9cc6cb17-ea88-1d53-35da-e2fdf1f343ae@wiktel.com>
Message-ID: <CAFTY+dA=Gz38m=VF2cpM48+bTDu+ZkWB4xnhpwHj-_P8wUcOmA@mail.gmail.com>

On Mon, Sep 7, 2020, at 5:24 PM Richard Laager via devel
<devel at ntpsec.org> wrote:
>
> 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.

I think if thas its advantages.

> 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?

Probably not. I haven't pushed the Ruby wrapper for gpsd either.

> 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.

Yes.

> Can you re-open !1010 or open a new MR with this?

I could but I should probably wait until after the pending release.
The code is in the ntpc branch of the main repository. pushing it
there revealed a now fixed segfault when using a clang built library.

From hmurray at megapathdsl.net  Tue Sep  8 01:01:55 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Mon, 07 Sep 2020 18:01:55 -0700
Subject: FFI module architecture decision was 'Python support policy'
In-Reply-To: Message from James Browning via devel <devel@ntpsec.org> of "Mon,
 07 Sep 2020 17:42:10 PDT."
 <CAFTY+dA=Gz38m=VF2cpM48+bTDu+ZkWB4xnhpwHj-_P8wUcOmA@mail.gmail.com>
Message-ID: <20200908010155.2F45B40605C@ip-64-139-1-69.sjc.megapath.net>

> I could but I should probably wait until after the pending release.

Or get it in now to get more testers so 1.2 is more likely to be solid when we 
get there.

Mark hasn't said anything about when (or even if) he plans the next release.


-- 
These are my opinions.  I hate spam.




From gem at rellim.com  Tue Sep  8 17:35:06 2020
From: gem at rellim.com (Gary E. Miller)
Date: Tue, 8 Sep 2020 10:35:06 -0700
Subject: FFI module architecture decision was 'Python support policy'
In-Reply-To: <9cc6cb17-ea88-1d53-35da-e2fdf1f343ae@wiktel.com>
References: <CAFTY+dAucDhAANhYeD4xODtYUs8y8_y++VWh+0+2fCF-=YrLLw@mail.gmail.com>
 <9cc6cb17-ea88-1d53-35da-e2fdf1f343ae@wiktel.com>
Message-ID: <20200908103506.609789b7@spidey.rellim.com>

Yo Richard!

On Mon, 7 Sep 2020 19:23:40 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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?

Yup.  With FFI, the python module becomes "Pure Pythpn".  That is all
Python, and no binaries.  The same code runs on all arches, and with
a bit of care, on all Python versions.

Since it works on all python versions, no need to build NTPsec for every
target arch/version.  That means just one pip package supports the
world.  It also means you can install the ntpd pylib in one place, add
that to your PYTHONPATH, and all version of Python will work with it.

In my use it is a coin flip.  But a lot of the world wants to just use
pip and this makes pip much easier.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200908/e84b706f/attachment.bin>

From wis1 at comcast.net  Sun Sep 13 22:47:19 2020
From: wis1 at comcast.net (wis1 at comcast.net)
Date: Sun, 13 Sep 2020 15:47:19 -0700
Subject: static IP setup in stratum-1 HOWTO
Message-ID: <072801d68a1f$d6783630$8368a290$@comcast.net>

For setting a static IP, the "Stratum-1-Microserver HOWTO" punts to the
reference "[EAT-STATIC] Tutorial - How to give your Raspberry Pi a Static IP
Address"
(http://www.modmypi.com/blog/tutorial-how-to-give-your-raspberry-pi-a-static
-ip-address). This page describes modifying the file
"/etc/network/interfaces".

 

this file contains, for the stock, current Raspberry PI OS (uname -a: "Linux
raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l
GNU/Linux"):

 

$ cat /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)

 

# Please note that this file is written to be used with dhcpcd

# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

 

# Include files from /etc/network/interfaces.d:

source-directory /etc/network/interfaces.d

$

 

It is clearly involved with 'dhcpdc', but how? The implication (unstated) is
that If the static IP data is manually put in this file and 'dhcpdc'
disabled, 'ifup' and 'ifdown' will use this file and function properly. Am I
understanding correctly?

 

Thanks,

 

-wis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200913/b6d2898c/attachment.htm>

From gem at rellim.com  Mon Sep 14 00:12:06 2020
From: gem at rellim.com (Gary E. Miller)
Date: Sun, 13 Sep 2020 17:12:06 -0700
Subject: static IP setup in stratum-1 HOWTO
In-Reply-To: <072801d68a1f$d6783630$8368a290$@comcast.net>
References: <072801d68a1f$d6783630$8368a290$@comcast.net>
Message-ID: <20200913171206.3b694910@spidey.rellim.com>

Yo Wis!

On Sun, 13 Sep 2020 15:47:19 -0700
Wis Macomson via devel <devel at ntpsec.org> wrote:

> For setting a static IP, the "Stratum-1-Microserver HOWTO" punts to
> the reference "[EAT-STATIC] Tutorial - How to give your Raspberry Pi
> a Static IP Address"

It all depends on what OS you are using.  I use Gentoo on Raspberry Pi.
Gentoo uses /etc/conf/net

> this file contains, for the stock, current Raspberry PI OS (uname -a:
> "Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020
> armv7l GNU/Linux"):

Sorry, I don't use that distro.  Maybe a Debian person cal help.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200913/131f295e/attachment.bin>

From jamesb.fe80 at gmail.com  Mon Sep 14 00:43:37 2020
From: jamesb.fe80 at gmail.com (James Browning)
Date: Sun, 13 Sep 2020 17:43:37 -0700
Subject: static IP setup in stratum-1 HOWTO
In-Reply-To: <20200913171206.3b694910@spidey.rellim.com>
References: <072801d68a1f$d6783630$8368a290$@comcast.net>
 <20200913171206.3b694910@spidey.rellim.com>
Message-ID: <CAFTY+dDk+RyiR+rMso=9WC3PQksN6F2NeUw3NS2WaCDjM9KLug@mail.gmail.com>

On Sun, Sep 13, 2020, at 5:12 PM Gary E. Miller via devel
<devel at ntpsec.org> wrote:
>
> Yo Wis!
>
> On Sun, 13 Sep 2020 15:47:19 -0700
> Wis Macomson via devel <devel at ntpsec.org> wrote:
>
> > For setting a static IP, the "Stratum-1-Microserver HOWTO" punts to
> > the reference "[EAT-STATIC] Tutorial - How to give your Raspberry Pi
> > a Static IP Address"
>
> It all depends on what OS you are using.  I use Gentoo on Raspberry Pi.
> Gentoo uses /etc/conf/net

Give that that blog post was 'updated' in 2014 I think both bit rotted.[1]
The updated Debian handbook is at [2].

> > this file contains, for the stock, current Raspberry PI OS (uname -a:
> > "Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020
> > armv7l GNU/Linux"):
>
> Sorry, I don't use that distro.  Maybe a Debian person cal help.

I am not a Debian person, but I imagine most of them would start
suggesting you revert the changes and following the handbook.

[1] https://thepihut.com/blogs/raspberry-pi-tutorials/how-to-give-your-raspberry-pi-a-static-ip-address-update
[2] https://www.debian.org/doc/manuals/debian-handbook/sect.network-config

From paul at anastrophe.com  Mon Sep 14 01:10:34 2020
From: paul at anastrophe.com (Paul Theodoropoulos)
Date: Sun, 13 Sep 2020 18:10:34 -0700
Subject: static IP setup in stratum-1 HOWTO
In-Reply-To: <CAFTY+dDk+RyiR+rMso=9WC3PQksN6F2NeUw3NS2WaCDjM9KLug@mail.gmail.com>
References: <072801d68a1f$d6783630$8368a290$@comcast.net>
 <20200913171206.3b694910@spidey.rellim.com>
 <CAFTY+dDk+RyiR+rMso=9WC3PQksN6F2NeUw3NS2WaCDjM9KLug@mail.gmail.com>
Message-ID: <3040e0ee-9c35-73cb-0100-3f40f3f675e8@anastrophe.com>

The /etc/network/interfaces file, _in its default state upon 
installation_, is written for use with dhcpcd. You can modify it however 
you like though. I don't use dhcpcd, so:

root@ A-ntpVIZ: ~ # systemctl stop dhcpcd && systemctl disable dhcpcd
root@ A-ntpVIZ: ~ # cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

#auto wlan0
#iface wlan0 inet static
#????? address 192.168.1.44
#????? netmask 255.255.255.0
#????? gateway 192.168.1.253
#????? wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#????? wireless-power off
#????? dns-nameservers 192.168.1.44 192.168.1.13

auto eth0
iface eth0 inet static
 ????? address 192.168.1.44
 ????? netmask 255.255.255.0
 ????? gateway 192.168.1.253
 ????? dns-nameservers 192.168.1.44 192.168.1.13

That's really all you need.

On 9/13/2020 17:43 PM, James Browning via devel wrote:
> On Sun, Sep 13, 2020, at 5:12 PM Gary E. Miller via devel
> <devel at ntpsec.org> wrote:
>> Yo Wis!
>>
>> On Sun, 13 Sep 2020 15:47:19 -0700
>> Wis Macomson via devel <devel at ntpsec.org> wrote:
>>
>>> For setting a static IP, the "Stratum-1-Microserver HOWTO" punts to
>>> the reference "[EAT-STATIC] Tutorial - How to give your Raspberry Pi
>>> a Static IP Address"
>> It all depends on what OS you are using.  I use Gentoo on Raspberry Pi.
>> Gentoo uses /etc/conf/net
> Give that that blog post was 'updated' in 2014 I think both bit rotted.[1]
> The updated Debian handbook is at [2].
>
>>> this file contains, for the stock, current Raspberry PI OS (uname -a:
>>> "Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020
>>> armv7l GNU/Linux"):
>> Sorry, I don't use that distro.  Maybe a Debian person cal help.
> I am not a Debian person, but I imagine most of them would start
> suggesting you revert the changes and following the handbook.
>
> [1] https://thepihut.com/blogs/raspberry-pi-tutorials/how-to-give-your-raspberry-pi-a-static-ip-address-update
> [2] https://www.debian.org/doc/manuals/debian-handbook/sect.network-config
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel

-- 
Paul Theodoropoulos
www.anastrophe.com


From wis1 at comcast.net  Mon Sep 14 14:55:31 2020
From: wis1 at comcast.net (wis1 at comcast.net)
Date: Mon, 14 Sep 2020 07:55:31 -0700
Subject: static IP setup in stratum-1 HOWTO
In-Reply-To: <3040e0ee-9c35-73cb-0100-3f40f3f675e8@anastrophe.com>
References: <072801d68a1f$d6783630$8368a290$@comcast.net>
 <20200913171206.3b694910@spidey.rellim.com>
 <CAFTY+dDk+RyiR+rMso=9WC3PQksN6F2NeUw3NS2WaCDjM9KLug@mail.gmail.com>
 <3040e0ee-9c35-73cb-0100-3f40f3f675e8@anastrophe.com>
Message-ID: <07ea01d68aa7$1829c350$487d49f0$@comcast.net>

>From: Paul Theodoropoulos <paul at anastrophe.com>
>Sent: Sunday, September 13, 2020 6:11 PM
>To: devel <devel at ntpsec.org>
>Subject: Re: static IP setup in stratum-1 HOWTO
>
>The /etc/network/interfaces file, _in its default state upon installation_, is
>written for use with dhcpcd. You can modify it however you like though. I
>don't use dhcpcd, so:
>
>root@ A-ntpVIZ: ~ # systemctl stop dhcpcd && systemctl disable dhcpcd
>root@ A-ntpVIZ: ~ # cat /etc/network/interfaces # interfaces(5) file used by
>ifup(8) and ifdown(8)
>
># Please note that this file is written to be used with dhcpcd # For static IP,
>consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
>
># Include files from /etc/network/interfaces.d:
>source-directory /etc/network/interfaces.d
>
>#auto wlan0
>#iface wlan0 inet static
>#      address 192.168.1.44
>#      netmask 255.255.255.0
>#      gateway 192.168.1.253
>#      wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
>#      wireless-power off
>#      dns-nameservers 192.168.1.44 192.168.1.13
>
>auto eth0
>iface eth0 inet static
>       address 192.168.1.44
>       netmask 255.255.255.0
>       gateway 192.168.1.253
>       dns-nameservers 192.168.1.44 192.168.1.13
>
>That's really all you need.

Yah, that's the conclusion I came to, as well. I'll be using DNS server IP's rather than the server.

Thanks to all for the clarifications.

-wis

>
>On 9/13/2020 17:43 PM, James Browning via devel wrote:
>> On Sun, Sep 13, 2020, at 5:12 PM Gary E. Miller via devel
>> <devel at ntpsec.org> wrote:
>>> Yo Wis!
>>>
>>> On Sun, 13 Sep 2020 15:47:19 -0700
>>> Wis Macomson via devel <devel at ntpsec.org> wrote:
>>>
>>>> For setting a static IP, the "Stratum-1-Microserver HOWTO" punts to
>>>> the reference "[EAT-STATIC] Tutorial - How to give your Raspberry Pi
>>>> a Static IP Address"
>>> It all depends on what OS you are using.  I use Gentoo on Raspberry Pi.
>>> Gentoo uses /etc/conf/net
>> Give that that blog post was 'updated' in 2014 I think both bit
>> rotted.[1] The updated Debian handbook is at [2].
>>
>>>> this file contains, for the stock, current Raspberry PI OS (uname -a:
>>>> "Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST
>>>> 2020 armv7l GNU/Linux"):
>>> Sorry, I don't use that distro.  Maybe a Debian person cal help.
>> I am not a Debian person, but I imagine most of them would start
>> suggesting you revert the changes and following the handbook.
>>
>> [1]
>> https://thepihut.com/blogs/raspberry-pi-tutorials/how-to-give-your-ras
>> pberry-pi-a-static-ip-address-update
>> [2]
>> https://www.debian.org/doc/manuals/debian-handbook/sect.network-
>config
>> _______________________________________________
>> devel mailing list
>> devel at ntpsec.org
>> http://lists.ntpsec.org/mailman/listinfo/devel
>
>--
>Paul Theodoropoulos
>www.anastrophe.com
>



From hmurray at megapathdsl.net  Thu Sep 17 06:40:05 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 16 Sep 2020 23:40:05 -0700
Subject: What's the status of the work on shebangs and/or ctype?
Message-ID: <20200917064005.DF8C5406061@ip-64-139-1-69.sjc.megapath.net>

Is there something I should be testing?


I think we should setup a separate header file to collect the API slots that 
we use from python.  But that can wait.

-- 
These are my opinions.  I hate spam.




From rlaager at wiktel.com  Thu Sep 17 07:46:23 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Thu, 17 Sep 2020 02:46:23 -0500
Subject: What's the status of the work on shebangs and/or ctype?
In-Reply-To: <20200917064005.DF8C5406061@ip-64-139-1-69.sjc.megapath.net>
References: <20200917064005.DF8C5406061@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <671ad6d5-679e-2781-72b6-8a9252a034a8@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200917/643909e3/attachment.bin>

From jamesb.fe80 at gmail.com  Thu Sep 17 15:52:30 2020
From: jamesb.fe80 at gmail.com (James Browning)
Date: Thu, 17 Sep 2020 08:52:30 -0700
Subject: What's the status of the work on shebangs and/or ctype?
In-Reply-To: <20200917064005.DF8C5406061@ip-64-139-1-69.sjc.megapath.net>
References: <20200917064005.DF8C5406061@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAFTY+dCzDpxqsZ1CxeeMgyPtLoU=SN8KudcysXPHxH7fdMfjXg@mail.gmail.com>

I think they have been ready for a while. it would appear not everyone agrees.

On Wed, Sep 16, 2020, at 11:40 PM Hal Murray via devel <devel at ntpsec.org> wrote:
>
> Is there something I should be testing?

compilers that are not clang or gcc.
platforms that are not Linux, macOS, or FreeBSD.
It would be nice to have more runners outside GNU/Linux.

> I think we should setup a separate header file to collect the API slots that
> we use from python.  But that can wait.

"include/libntp_shared.h", I kinda like the sound of that.
maybe a few minors down the road we could move libntp to a single shared library

From gem at rellim.com  Thu Sep 17 16:54:57 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 17 Sep 2020 09:54:57 -0700
Subject: What's the status of the work on shebangs and/or ctype?
In-Reply-To: <671ad6d5-679e-2781-72b6-8a9252a034a8@wiktel.com>
References: <20200917064005.DF8C5406061@ip-64-139-1-69.sjc.megapath.net>
 <671ad6d5-679e-2781-72b6-8a9252a034a8@wiktel.com>
Message-ID: <20200917095457.7bba9a1a@spidey.rellim.com>

Yo Richard!

I agree with the first of 4 goals of the MR.

Goal 2 is munging explicit user input in ways that disallow
PEP conformance and generality.

Goal 3 breaks Gentoo and violates the PEP.

The fallback, goal 4, is "/usr/bin/env python".  Does anyone
object to making that "/usr/bin/env python3"?

Rather than go around and around, how about a simple MR that only
implements goals 1 and 4?

The proble

On Thu, 17 Sep 2020 02:46:23 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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
> 




RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200917/1be9ab50/attachment.bin>

From hmurray at megapathdsl.net  Thu Sep 17 20:51:45 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 17 Sep 2020 13:51:45 -0700
Subject: RFC getting closer
Message-ID: <20200917205145.7D944406061@ip-64-139-1-69.sjc.megapath.net>


------- Forwarded Message

From: "Karen O'Donoghue" <odonoghue at isoc.org>
To: Watson Ladd <watson at cloudflare.com>,
        Miroslav Lichvar
	<mlichvar at redhat.com>,
        Dieter Sibold <dsibold.ietf at gmail.com>,
        "Langer,
 Martin" <mart.langer at ostfalia.de>,
        Marcus Dansarie <marcus at dansarie.se>,
        =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <paf at netnod.se>,
        Daniel Franke
	<dfoxfranke at gmail.com>,
        "kristof.teichel at ptb.de" <kristof.teichel at ptb.de>,
        Ragnar Sundblad <ragge at netnod.se>,
        Hal Murray <hmurray at megapathdsl.net>
CC: Susannah Gray <gray at isoc.org>, Phil Roberts <roberts at dkey.org>
Subject: Coordinating some blog posts celebrating the publication of NTS

Folks,

As some of you know, the NTS document has entered AUTH48 state and should be 
published shortly. Some of us had talked earlier this year about doing a set 
of coordinated blog posts at the time of publication. I think this would be a 
good idea (I think it might have been Watson who mentioned it first). 
Depending on your role in NTS and what you want to make public, you could talk 
about the RFC and point to your open source implementations or your public NTS 
deployments (and for some of you, your previous blog posts). I'm copying 
Susannah Gray, our Comms lead in this area, to do some basic coordination. I'm 
not sure how long it will take to get through AUTH48, but initial review of 
the comments by authors indicates there are no major show stoppers. I think 
have multiple organizations talking about it at once would be beneficial.

Regards, 
Karen



------- End of Forwarded Message



-- 
These are my opinions.  I hate spam.




From rlaager at wiktel.com  Thu Sep 17 22:54:29 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Thu, 17 Sep 2020 17:54:29 -0500
Subject: What's the status of the work on shebangs and/or ctype?
In-Reply-To: <20200917095457.7bba9a1a@spidey.rellim.com>
References: <20200917064005.DF8C5406061@ip-64-139-1-69.sjc.megapath.net>
 <671ad6d5-679e-2781-72b6-8a9252a034a8@wiktel.com>
 <20200917095457.7bba9a1a@spidey.rellim.com>
Message-ID: <8b127591-3265-30aa-2d53-75aaa68633f0@wiktel.com>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200917/a9f65c95/attachment-0001.bin>

From gem at rellim.com  Thu Sep 17 23:52:06 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 17 Sep 2020 16:52:06 -0700
Subject: What's the status of the work on shebangs and/or ctype?
In-Reply-To: <8b127591-3265-30aa-2d53-75aaa68633f0@wiktel.com>
References: <20200917064005.DF8C5406061@ip-64-139-1-69.sjc.megapath.net>
 <671ad6d5-679e-2781-72b6-8a9252a034a8@wiktel.com>
 <20200917095457.7bba9a1a@spidey.rellim.com>
 <8b127591-3265-30aa-2d53-75aaa68633f0@wiktel.com>
Message-ID: <20200917165206.5201e682@spidey.rellim.com>

Yo Richard!

On Thu, 17 Sep 2020 17:54:29 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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 just did.

> > 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.

We prolly need buy in from just the two of us.

> I would describe this change as "Make Python 3 the default". Should we
> do that now, or one release later? Any objections to now?

Either way works for me.  With --pyshebang now working I can easily
adjust to my taste.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200917/5f3ae45a/attachment.bin>

From gem at rellim.com  Fri Sep 18 00:07:02 2020
From: gem at rellim.com (Gary E. Miller)
Date: Thu, 17 Sep 2020 17:07:02 -0700
Subject: What's the status of the work on shebangs and/or ctype?
In-Reply-To: <20200917165206.5201e682@spidey.rellim.com>
References: <20200917064005.DF8C5406061@ip-64-139-1-69.sjc.megapath.net>
 <671ad6d5-679e-2781-72b6-8a9252a034a8@wiktel.com>
 <20200917095457.7bba9a1a@spidey.rellim.com>
 <8b127591-3265-30aa-2d53-75aaa68633f0@wiktel.com>
 <20200917165206.5201e682@spidey.rellim.com>
Message-ID: <20200917170702.0c08bef1@spidey.rellim.com>

Yo Gary!

On Thu, 17 Sep 2020 16:52:06 -0700
"Gary E. Miller via devel" <devel at ntpsec.org> 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.  
> 
> We prolly need buy in from just the two of us.

I meant MORE than just the two of us.  Some people get touchy when you
touch their shebang.


RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200917/a8019bbe/attachment.bin>

From rlaager at wiktel.com  Fri Sep 18 04:42:58 2020
From: rlaager at wiktel.com (Richard Laager)
Date: Thu, 17 Sep 2020 23:42:58 -0500
Subject: What's the status of the work on shebangs and/or ctype?
In-Reply-To: <20200917170702.0c08bef1@spidey.rellim.com>
References: <20200917064005.DF8C5406061@ip-64-139-1-69.sjc.megapath.net>
 <671ad6d5-679e-2781-72b6-8a9252a034a8@wiktel.com>
 <20200917095457.7bba9a1a@spidey.rellim.com>
 <8b127591-3265-30aa-2d53-75aaa68633f0@wiktel.com>
 <20200917165206.5201e682@spidey.rellim.com>
 <20200917170702.0c08bef1@spidey.rellim.com>
Message-ID: <747a5545-3a15-3453-34d8-b4d8ed2a39b3@wiktel.com>

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" <devel at ntpsec.org> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200917/d4cbe733/attachment.bin>

From hmurray at megapathdsl.net  Fri Sep 18 15:43:42 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 18 Sep 2020 08:43:42 -0700
Subject: Release gymnastics
Message-ID: <20200918154342.DD349406061@ip-64-139-1-69.sjc.megapath.net>


Maybe we should get 1.2 out now/soon so it will be ready when the RFC comes 
out rather than shortly after.



-- 
These are my opinions.  I hate spam.




From dfoxfranke at gmail.com  Fri Sep 18 20:33:41 2020
From: dfoxfranke at gmail.com (Daniel Franke)
Date: Fri, 18 Sep 2020 16:33:41 -0400
Subject: Release gymnastics
In-Reply-To: <20200918154342.DD349406061@ip-64-139-1-69.sjc.megapath.net>
References: <20200918154342.DD349406061@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAJm83bDCek=5ycAFtM2hxvLzrgvDDQv0eht9WfFQV53-6Kw6pw@mail.gmail.com>

The normative content of the RFC is not going to change. There's no
reason to hold back any release while waiting for publication.

On Fri, Sep 18, 2020 at 11:43 AM Hal Murray via devel <devel at ntpsec.org> wrote:
>
>
> Maybe we should get 1.2 out now/soon so it will be ready when the RFC comes
> out rather than shortly after.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel

From hmurray at megapathdsl.net  Sun Sep 20 09:57:40 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sun, 20 Sep 2020 02:57:40 -0700
Subject: NTS-KE no longer listens on port 123
Message-ID: <20200920095740.DDA8F40605C@ip-64-139-1-69.sjc.megapath.net>


That's my last important change for 1.2

There may be bumps in the road since the client in the current release defaults to 123.  Users running old code (released tarball) will have to add ":4460" to their server name if they want to contact a server running this new code.

The good news is that the logging crap from bad guys probing seems to have vanished.


-- 
These are my opinions.  I hate spam.




From mark.atwood at ntpsec.org  Mon Sep 21 15:50:00 2020
From: mark.atwood at ntpsec.org (Mark Atwood)
Date: Mon, 21 Sep 2020 08:50:00 -0700
Subject: get ready for 1.2.0 on Friday 2020-09-25
In-Reply-To: <CAJm83bDCek=5ycAFtM2hxvLzrgvDDQv0eht9WfFQV53-6Kw6pw@mail.gmail.com>
References: <20200918154342.DD349406061@ip-64-139-1-69.sjc.megapath.net>
 <CAJm83bDCek=5ycAFtM2hxvLzrgvDDQv0eht9WfFQV53-6Kw6pw@mail.gmail.com>
Message-ID: <879075f8-abe3-4d21-ac2e-c65a35e1359d@www.fastmail.com>

On Fri, Sep 18, 2020, at 13:33, Daniel Franke wrote:
> The normative content of the RFC is not going to change. There's no
> reason to hold back any release while waiting for publication.
> On Fri, Sep 18, 2020 at 11:43 AM Hal Murray via devel <devel at ntpsec.org> wrote:
> > Maybe we should get 1.2 out now/soon so it will be ready when the RFC comes
> > out rather than shortly after.

Ok, we'll do the release on Friday the 25th.  This will be version 1.2.0.  Having NTS under RFC is worth a 0.X.0 version bump.

Everyone, do the stuff.  Wrap up your almost done WIPs, merge them, test them, and update the docs and the Changelog.

..m


..???
Mark Atwood <mark.atwood at ntpsec.org>
Project Manager of the NTPsec Project
+1-206-604-2198


From hmurray at megapathdsl.net  Mon Sep 21 19:45:51 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Mon, 21 Sep 2020 12:45:51 -0700
Subject: get ready for 1.2.0 on Friday 2020-09-25
In-Reply-To: Message from Mark Atwood via devel <devel@ntpsec.org> of "Mon,
 21 Sep 2020 08:50:00 PDT."
 <879075f8-abe3-4d21-ac2e-c65a35e1359d@www.fastmail.com>
Message-ID: <20200921194551.2389940605C@ip-64-139-1-69.sjc.megapath.net>

> update the docs and the Changelog

I assume you meant NEWS.


devel/ChangeLog says:
This is the historical change log from before the DVCS repository conversion.
If you want the level of detail this contained about post-conversion changes,
read the per-commit change comments.


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Tue Sep 22 23:35:35 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 22 Sep 2020 16:35:35 -0700
Subject: Blog announcing NTS
Message-ID: <20200922233535.8480540605C@ip-64-139-1-69.sjc.megapath.net>

Subject: Re: Coordinating some blog posts celebrating the publication of NTS
From: Watson Ladd <watson at cloudflare.com>
Date: Tue, 22 Sep 2020 13:02:06 -0400
To: Hal Murray <hmurray at megapathdsl.net>
Cc: Susannah Gray <gray at isoc.org>, "Karen O'Donoghue" <odonoghue at isoc.org>,
        Patrik F??ltstr??m <paf at netnod.se>,
        Miroslav Lichvar <mlichvar at redhat.com>,
        Dieter Sibold <dsibold.ietf at gmail.com>,
        "Langer, Martin" <mart.langer at ostfalia.de>,
        Marcus Dansarie <marcus at dansarie.se>,
        Daniel Franke <dfoxfranke at gmail.com>,
        "kristof.teichel at ptb.de" <kristof.teichel at ptb.de>,
        Ragnar Sundblad <ragge at netnod.se>, Phil Roberts <roberts at dkey.org>,
        Johanna Eriksson <johanna at netnod.se>

So right now it looks like Daniel Franke is the last author who needs
to say yes. Please share the URLs you want us to point to before then!


-- 
These are my opinions.  I hate spam.




From dfoxfranke at gmail.com  Wed Sep 23 00:36:58 2020
From: dfoxfranke at gmail.com (Daniel Franke)
Date: Tue, 22 Sep 2020 20:36:58 -0400
Subject: Blog announcing NTS
In-Reply-To: <20200922233535.8480540605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200922233535.8480540605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAJm83bC9FXQ16jJFKp5ZSOKV8i5bA8sFhMG7iX+FZVrnVgAukQ@mail.gmail.com>

I've already said yes, but the yes was contingent on IANA fixing an
error in a descriptive field so the change in the datatracker is
waiting on that happening.

On Tue, Sep 22, 2020 at 7:35 PM Hal Murray via devel <devel at ntpsec.org> wrote:
>
> Subject: Re: Coordinating some blog posts celebrating the publication of NTS
> From: Watson Ladd <watson at cloudflare.com>
> Date: Tue, 22 Sep 2020 13:02:06 -0400
> To: Hal Murray <hmurray at megapathdsl.net>
> Cc: Susannah Gray <gray at isoc.org>, "Karen O'Donoghue" <odonoghue at isoc.org>,
>         Patrik F??ltstr??m <paf at netnod.se>,
>         Miroslav Lichvar <mlichvar at redhat.com>,
>         Dieter Sibold <dsibold.ietf at gmail.com>,
>         "Langer, Martin" <mart.langer at ostfalia.de>,
>         Marcus Dansarie <marcus at dansarie.se>,
>         Daniel Franke <dfoxfranke at gmail.com>,
>         "kristof.teichel at ptb.de" <kristof.teichel at ptb.de>,
>         Ragnar Sundblad <ragge at netnod.se>, Phil Roberts <roberts at dkey.org>,
>         Johanna Eriksson <johanna at netnod.se>
>
> So right now it looks like Daniel Franke is the last author who needs
> to say yes. Please share the URLs you want us to point to before then!
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel

From hmurray at megapathdsl.net  Fri Sep 25 02:29:32 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 24 Sep 2020 19:29:32 -0700
Subject: Quirk in wafhelpers/bin_test.py
Message-ID: <20200925022932.69CB740605C@ip-64-139-1-69.sjc.megapath.net>


I have this patch is my local copy.  It's leftover from when I broke something 
and discovered that the test stuff crashed here.  Obviously, I screwed up by 
not keeping better notes and sending in a bug report.

Does anybody understand this corner of python enough to be able to figure out 
what the bug is and what the correct fix is?

--- a/wafhelpers/bin_test.py
+++ b/wafhelpers/bin_test.py
@@ -77,7 +77,7 @@ def run(cmd, reg, pythonic):
         addLog("GREEN", prefix + "  OK")
         return True
     addLog("RED", prefix + "  FAILED")
-    addLog("PINK", "Expected: " + reg)
+    addLog("PINK", "Expected: " + str(breg))
     if stdout:
         addLog("PINK", "Got (stdout): " + stdout)
     if stderr:


-- 
These are my opinions.  I hate spam.




From jamesb.fe80 at gmail.com  Fri Sep 25 02:38:01 2020
From: jamesb.fe80 at gmail.com (James Browning)
Date: Thu, 24 Sep 2020 19:38:01 -0700
Subject: Quirk in wafhelpers/bin_test.py
In-Reply-To: <20200925022932.69CB740605C@ip-64-139-1-69.sjc.megapath.net>
References: <20200925022932.69CB740605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAFTY+dDeWPiskXa21AQHNrHu_LpubjjZ0ExGtfovGYtiKvWSew@mail.gmail.com>

On Thu, Sep 24, 2020 at 7:29 PM Hal Murray via devel <devel at ntpsec.org> wrote:
>
> I have this patch is my local copy.  It's leftover from when I broke something
> and discovered that the test stuff crashed here.  Obviously, I screwed up by
> not keeping better notes and sending in a bug report.
>
> Does anybody understand this corner of python enough to be able to figure out
> what the bug is and what the correct fix is?
>
> --- a/wafhelpers/bin_test.py
> +++ b/wafhelpers/bin_test.py
> @@ -77,7 +77,7 @@ def run(cmd, reg, pythonic):
>          addLog("GREEN", prefix + "  OK")
>          return True
>      addLog("RED", prefix + "  FAILED")
> -    addLog("PINK", "Expected: " + reg)
> +    addLog("PINK", "Expected: " + str(breg))
>      if stdout:
>          addLog("PINK", "Got (stdout): " + stdout)
>      if stderr:

IIRC unless universal_newlines=True is passed to subprocess.popen it
returns bytes in the communication hook. I had it so that it compared
bytes. I believe the argument was recently added and all traces of
bytes were ripped out in 3f7f79 'bin_test: use universal_newlines
instead of futzing w/ polystr -r2 ...' on Aug 24.

From hmurray at megapathdsl.net  Fri Sep 25 02:48:47 2020
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 24 Sep 2020 19:48:47 -0700
Subject: Quirk in wafhelpers/bin_test.py
In-Reply-To: Message from James Browning <jamesb.fe80@gmail.com> of "Thu,
 24 Sep 2020 19:38:01 PDT."
 <CAFTY+dDeWPiskXa21AQHNrHu_LpubjjZ0ExGtfovGYtiKvWSew@mail.gmail.com>
Message-ID: <20200925024847.8626B40605C@ip-64-139-1-69.sjc.megapath.net>


> IIRC unless universal_newlines=True is passed to subprocess.popen it returns
> bytes in the communication hook. I had it so that it compared bytes. I
> believe the argument was recently added and all traces of bytes were ripped
> out in 3f7f79 'bin_test: use universal_newlines instead of futzing w/ polystr
> -r2 ...' on Aug 24. 

Thanks.  Sounds like a good story.  I through away my patch.


-- 
These are my opinions.  I hate spam.




From paul at anastrophe.com  Sat Sep 26 20:03:37 2020
From: paul at anastrophe.com (Paul Theodoropoulos)
Date: Sat, 26 Sep 2020 13:03:37 -0700
Subject: get ready for 1.2.0 on Friday 2020-09-25
In-Reply-To: <879075f8-abe3-4d21-ac2e-c65a35e1359d@www.fastmail.com>
References: <20200918154342.DD349406061@ip-64-139-1-69.sjc.megapath.net>
 <CAJm83bDCek=5ycAFtM2hxvLzrgvDDQv0eht9WfFQV53-6Kw6pw@mail.gmail.com>
 <879075f8-abe3-4d21-ac2e-c65a35e1359d@www.fastmail.com>
Message-ID: <05d2b9fe-9083-4410-e482-c72b63052c08@anastrophe.com>

Any updates on this? I don't see a 1.2.0 release on gitlab.

On 9/21/2020 8:50 AM, Mark Atwood via devel wrote:
> On Fri, Sep 18, 2020, at 13:33, Daniel Franke wrote:
>> The normative content of the RFC is not going to change. There's no
>> reason to hold back any release while waiting for publication.
>> On Fri, Sep 18, 2020 at 11:43 AM Hal Murray via devel <devel at ntpsec.org> wrote:
>>> Maybe we should get 1.2 out now/soon so it will be ready when the RFC comes
>>> out rather than shortly after.
> Ok, we'll do the release on Friday the 25th.  This will be version 1.2.0.  Having NTS under RFC is worth a 0.X.0 version bump.
>
> Everyone, do the stuff.  Wrap up your almost done WIPs, merge them, test them, and update the docs and the Changelog.
>
> ..m
>
>
> ..???
> Mark Atwood <mark.atwood at ntpsec.org>
> Project Manager of the NTPsec Project
> +1-206-604-2198
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel

-- 
Paul Theodoropoulos
www.anastrophe.com