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
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
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@.) Is this something people care a
On Wed, Sep 02, 2020 at 08:53:41AM -0400, Eric S. Raymond via devel wrote:
> Sanjeev Gupta :
> > They support *any* git repository.
>
> Huh. Their docs are out of date, then.
I tried adding our GitLab repo today and I get an error message that new GitLab
repos have been disabled by the site adm
Yo Hal!
On Wed, 02 Sep 2020 18:25:51 -0700
Hal Murray 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. I
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
imp
e...@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
typ
Yo Eric!
On Wed, 2 Sep 2020 20:51:45 -0400
"Eric S. Raymond via devel" wrote:
> Richard Laager via devel :
> > 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,
> >
Richard Laager via devel :
> 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:
>
Yo Richard!
On Wed, 2 Sep 2020 19:29:15 -0500
Richard Laager via devel 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 t
Yo Eric!
On Wed, 2 Sep 2020 20:35:38 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > 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
Gary E. Miller via devel :
> 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 gradie
Let me start over now that I've reviewed the specifics of the NTPsec
scripts and build system again:
We are currently using "#!/usr/bin/env python" in all the scripts, and
waf uses the same. The minimum to do to drop Python 2 is:
1. Change waf's shebang:
-#!/usr/bin/env python
+#!/usr/b
Yo Eric!
On Wed, 2 Sep 2020 19:39:05 -0400
"Eric S. Raymond via devel" 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.
Alr
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.
Hal Murray :
>
> e...@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
On 9/2/20 2:30 PM, Hal Murray wrote:
>> I do ship an AppArmor profile.
>
> Thanks. That's the word I was fishing for.
>
> I've never worked with it. Is there a good introductory writeup?
There is various documentation, but I don't have anything off the top of
my head to direct you to.
> Are t
e...@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'
> 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.
_
Yo Richard!
On Wed, 2 Sep 2020 14:14:43 -0500
Richard Laager via devel 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 comlai
On 9/2/20 12:47 PM, Gary E. Miller via devel wrote:
> Yo Eric!
>
> On Wed, 2 Sep 2020 08:07:53 -0400 (EDT)
> "Eric S. Raymond via devel" wrote:
>
>> Retaining support for Python 2 proliferates test paths and
>> complicates the fix for at least one outstanding bug.
>
> Python 2 will be with us
On 9/1/20 10:27 PM, Hal Murray via devel wrote:
> What's the word for what Debian does?
In the package: no seccomp.
I really don't see the advantage in seccomp; it seems like a lot more
trouble than it is worth.
I do ship an AppArmor profile.
--
Richard
signature.asc
Description: OpenPGP di
Yo Eric!
On Wed, 2 Sep 2020 14:33:10 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > 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 overrun
Gary E. Miller via devel :
> 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
Yo Eric!
On Wed, 2 Sep 2020 08:07:53 -0400 (EDT)
"Eric S. Raymond via devel" wrote:
> Retaining support for Python 2 proliferates test paths and
> complicates the fix for at least one outstanding bug.
Python 2 will be with us for years more. Any time gpsd changes
in a way that breaks Python 2
Yo Eric!
On Wed, 2 Sep 2020 05:52:54 -0400
"Eric S. Raymond via devel" wrote:
> Hal Murray :
> > 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 d
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.
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
Sanjeev Gupta :
> 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.
--
http://www.catb.org/~esr/";>Eric S. Raymond
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
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/deve
folkert :
> > > > 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 k
> > > 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
> > verifica
folkert :
> > 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
> verificati
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
> 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.
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 wor
Hal Murray :
> 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 i
37 matches
Mail list logo
