> I'll study authinfo and get back to you, probably tomorrow.
authinfo is a bad example. ntpq has its own copy of that list.
I thought there was at least one command that didn't need it's own list, but I
can't find an example.
Beware, you may get sucked in. The swamp is pretty deep, but it's
dfoxfra...@gmail.com said:
> You can assume it's a verification failure because "failure in underlying
> machinery" shouldn't be possible. The call doesn't allocate memory and
> doesn't make any system calls. There's nothing that can fail.
Thanks.
It would be nice to have that in the man page.
dfoxfra...@gmail.com said:
> Try the new HEAD (3562205). I changed ANSI to POSIX.1-2001 which should
> hopefully make FreeBSD happy again while still suppressing the colliding
> symbols on NetBSD.
Works on both FreeBSD and NetBSD.
Thanks.
--
These are my opinions. I hate spam.
Okay, not surprised that's where the breakage was introduced, since
OpenSSL 1.1.0 rearchitected how it handles threading:
https://www.openssl.org/blog/blog/2017/02/21/threads/
Did my commit switching _ANSI_SOURCE to _POSIX_SOURCE resolve the build failure?
On Mon, Feb 18, 2019 at 11:53 PM Hal Mur
dfoxfra...@gmail.com said:
> What version of OpenSSL are you building against on FreeBSD? I want to go
> through sources to figure out exactly why it fails.
Current release:
12.0-RELEASE
/usr/include/openssl/opensslv.h:# define OPENSSL_VERSION_NUMBER 0x1010101fL
Fails
An older system:
11.2-RE
You can assume it's a verification failure because "failure in
underlying machinery" shouldn't be possible. The call doesn't allocate
memory and doesn't make any system calls. There's nothing that can
fail.
On Mon, Feb 18, 2019 at 3:53 PM Hal Murray wrote:
>
>
> There is a rough edge that I don't
Try the new HEAD (3562205). I changed ANSI to POSIX.1-2001 which
should hopefully make FreeBSD happy again while still suppressing the
colliding symbols on NetBSD.
What version of OpenSSL are you building against on FreeBSD? I want to
go through sources to figure out exactly why it fails.
On Mon,
Richard Laager via devel :
> Is there a particular reason this needs to be handled right now?
No. But I had some deasd time wile waur=ing for CI to unjam.
> For what it's worth, I think this should wait until NTS is done. NTPv5
> is going to require IETF action. Both the NTPsec developers and
Hal Murray via devel :
> Eric: If you feel like hacking, the thing that I'm going to want real soon
> is
> something similar to ntpq's authinfo. I think the ntpq side just displays
> whatever it gets back. That makes it easy to add more slots - server only,
> no
> changes to ntpq. If you g
dfoxfra...@gmail.com said:
> The BSDs work the same way Linux does except on FreeBSD the configuration
> file is called /etc/ld-elf.so.conf and you run 'ldconfig -elf' after you've
> changed it.
Thanks.
My NetBSD systems don't have a ldconfig.
My FreeBSD systems don't come with a /etc/ld-elf
On 2/18/19 4:11 PM, Eric S. Raymond via devel wrote:
> Whle awaiting Daniel's libaes_siv release and the unjamming of our CI,
> I did some serious design work on the NTPv5 proposal at
> devel/ntpv5.adoc.
>
> It's no longer a disconnected grab-bag of wishlist items. I've
> brought it to a state th
The client adds the NTS extensions and the server decodes them.
I'm going to stretch my legs and try to catch up on email before starting on
the response side.
Eric: If you feel like hacking, the thing that I'm going to want real soon is
something similar to ntpq's authinfo. I think the ntpq
> You also have to add a few lines on the NTP server to reject requests without
> certificates.
I expect that just that "simple" feature would eliminate most of the trash.
For a while.
--
These are my opinions. I hate spam.
___
devel mailing
Yo Project Manager via devel!
On Thu, 14 Feb 2019 20:54:06 -0800
"Mark Atwood, Project Manager via devel" wrote:
> How hard would it be to implement, and what does it buy us?
My WAG is under 100 lines of code to implement. The client needs to
send his client cert, and the server needs to chec
Whle awaiting Daniel's libaes_siv release and the unjamming of our CI,
I did some serious design work on the NTPv5 proposal at
devel/ntpv5.adoc.
It's no longer a disconnected grab-bag of wishlist items. I've
brought it to a state that is, in principle, implementable. Though the
change in datesta
There is a rough edge that I don't fully understand.
The man page for AES_SIV_Decrypt says:
These functions return 1 on success and 0 on failure.
There are 2 types of errors: the CMAC check failed, or there was a problem in
some underlying machinery.
Is there any way to distinguish bet
Google/gmail has been rejecting some of my mail recently.
Daniel said:
> I'm also waiting on Hal to run it through his build farm again to let me know
> if last-minute changes caused any breakage.
The ANSI fix for NetBSD broke FreeBSD.
-- Build files have been written to: /home/murray/ntpsec/lib
The current HEAD of libaes_siv is a release candidate. Whether or not
it becomes the release depends on what I decide to do about the CentOS
6 issue, which in turn depends on the OpenSSL team getting back to me.
I'm also waiting on Hal to run it through his build farm again to let
me know if last-m
18 matches
Mail list logo
