Old OpenSSL Compatibility (x: Old OpenSSL Cpmpaitibility)

[Fred Wright]

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