On Wed, 18 Dec 2024, Hal Murray wrote:
It used to be possible to build with --disable-nts when a sufficiently
new OpenSSL wasn't available, but commit 7c8b5fe20 broke that. I'm not
sure why cryptographic functions are needed at all with --disable-nts,
but even if they are, the compatibility definitions could have been in a
single header instead of replicated all over the place.
[...]
What system do you have that is now causing troubles? Do we want to be
supporting systems that old and/or does anybody running stuff that old
want to run our code?
I'm always in favor of maximum compatibility.
The non-Mac systems I have here are:
Ubuntu 22
Ubuntu 14
Debian 7
FreeBSD 10.3
OpenBSD 5.6
NetBSD 6.1.5
NetBSD was previously broken by another issue, but all the others worked
as of v1.2.3, at least with --disable-nts (though OpenBSD requires the
same patches as I use for older OSX versions). Of the above, only Ubuntu
22 can build the latest code.
[...]
We need crypto for hashing IPv6 addresses, shared key authentication, the
cookies that mode6 uses, and checking the leapsecond file.
For non-cryptographic uses, a Bob Jenkins hash is usually a better choice,
anyway, though the shared-key case probably doesn't qualify.
[...]
The cleanest fix I can think of right now would be something like
#ifndef HAVE_EVP_MD_CTX_new
#define EVP_MD_CTX_new EVP_MD_CTX_create
$define EVP_MD_CTX_free EVP_MD_CTX_destroy
#endif
I don't see a good header file to put that in so I would make a new one
and include it where needed.
That's roughly what I'd do, though using function macros instead of simple
macros reduces the collision risk.
Modern header files have this:
# define EVP_MD_CTX_create() EVP_MD_CTX_new()
# define EVP_MD_CTX_init(ctx) EVP_MD_CTX_reset((ctx))
# define EVP_MD_CTX_destroy(ctx) EVP_MD_CTX_free((ctx))
I don't see any ifdef around that.
That's also in 1.1.0. So I think it would work if we hacked our code to
use the old names. But that is pretty ugly to me and could get confusing
if somebody was trying to use man pages to understand the code.
That approach seems backwards, and yes, confusing.
On Wed, 18 Dec 2024, Hal Murray via devel wrote:
I think the standalone MD5 and SHA code is long gone.
Yes, but it's in git someplace. It won't be that hard to find if we
really want it. I don't want to go there, but don't want to hide options
either in case somebody thinks it is important.
But more work and more code than a couple of compatibility definitions.
I would be nice to move the control interface off of port 123 and away
from UDP in general.
Yup. But that requires some thought and planning. It's not going to
happen before a release.
The most important thing to get off of port 123 (and again, not right
before a release) is the client port. Using 123 as the client port is
extremely NAT-hostile. Some people switched from classic NTP to chrony
for that reason alone.
Fred Wright
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
