> Wouldn't it be simpler to ude a base image in the CI that isn't buggy?
Maybe. I don't know that area. If that is the only place we test seccomp,
then yes, we should switch to Fedora or Debian. If that is testing if we can
build on Alpine, then it has found a bug but the bug is in Alpine ra
Hal Murray via devel :
>
> Fedora fixed their problem. seccomp now builds and works on both Fedora and
> Arch.
>
> But now it won't build on Alpine. It looks like the same problem that Fedora
> had. The problem is a bug in a header file. Copying the ppoll bits from a
> Fedora header file f
Fedora fixed their problem. seccomp now builds and works on both Fedora and
Arch.
But now it won't build on Alpine. It looks like the same problem that Fedora
had. The problem is a bug in a header file. Copying the ppoll bits from a
Fedora header file fixes the problem.
The CI checker ha
Hal Murray via devel :
> Should we drop secomp? It's a pain to maintain.
We're a security-focused prodict. I don't think it would be good optics
to drop a layer of defense just because it's a pain to maintain.
> How many people use it? Richard: do you turn it on for the Debian builds?
I have
Udo van den Heuvel via devel writes:
> Ah, thanks, then I find:
>
> NTSc: certificate invalid: 10=>certificate has expired
How about you post the log for the whole key exchange and not always
just a single line and the another one in the next mail? Here's what
that looks like here:
2020-02-23T07
[Was Subject: Re: Is there a clean way for waf to test for the distro?]
> Are you really, absolutely, positively sure that you can't check for the
> feature itself directly. If you start going down the distro-checking path,
> things get very messy, very fast. For example, is "Linux Mint" like Ub
> NTSc: certificate invalid: 10=>certificate has expired
> is that a local expiration or a remote one?
That's your client side saying that it thinks the remote certificate has
expired. You could get the same error if your system clock was set into the
far future.
The local certificate (if a
On 23-02-2020 11:30, Achim Gratz via devel wrote:
> Udo van den Heuvel via devel writes:
>> ntpd[2256]: NTSc: NTS-KE req to pi4.rellim.com took 0.370 sec, fail
>
> You'd need the /^NTSc: / lines immediately preceding this to figure out
> where it failed. There is no full separation of all the dif
Udo van den Heuvel via devel writes:
> ntpd[2256]: NTSc: NTS-KE req to pi4.rellim.com took 0.370 sec, fail
You'd need the /^NTSc: / lines immediately preceding this to figure out
where it failed. There is no full separation of all the different fail
modes however, for instance a failed certificat
Hello,
What does a line of
ntpd[2256]: NTSc: NTS-KE req to pi4.rellim.com took 0.370 sec, fail
signify?
A remote issue?
Or a local failure?
What is failing exactly?
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mai
10 matches
Mail list logo
