Re: git: c01c0a27cb82 - main - openssl: make libcrypto export the same symbols as upstream

> On Oct 10, 2026, at 7:53 PM, Gordon Tetlow <gordon@FreeBSD.org> wrote:
> 
> On 9 Oct 2026, at 16:24, Robert Clausecker wrote:
> 
>> Hi,
>> 
>> On Fri, Oct 09, 2026 at 11:15:56PM +0300, Konstantin Belousov wrote:
>>> On Thu, Oct 08, 2026 at 09:10:50PM +0000, Gordon Tetlow wrote:
>>>> The branch main has been updated by gordon:
>>>> 
>>>> URL: https://cgit.FreeBSD.org/src/commit/?id=c01c0a27cb82ca40ed507889c8f78fb2dcf76568
>>>> 
>>>> commit c01c0a27cb82ca40ed507889c8f78fb2dcf76568
>>>> Author:     Gordon Tetlow <gordon@FreeBSD.org>
>>>> AuthorDate: 2026-10-08 21:10:10 +0000
>>>> Commit:     Gordon Tetlow <gordon@FreeBSD.org>
>>>> CommitDate: 2026-10-08 21:10:34 +0000
>>>> 
>>>>    openssl: make libcrypto export the same symbols as upstream
>>>> 
>>>>    Make the libcrypto Version.map export the same symbol names as upstream
>>>>    3.5.8 (and 3.5.9, no new symbols were added).
>>>> 
>>>>    Remove 52 names that upstream does not export:
>>>>    - the internal threading and record layer functions (ossl_crypto_*,
>>>>      ssl3_cbc_*, tls1_cbc_*), which only libssl used;
>>>>    - the internal WPACKET_quic_* functions;
>>>>    - OPENSSL_cpuid_setup;
>>>>    - ASN.1 item functions that are not in util/libcrypto.num.
>>> 
>>> Removing versioned symbol warrants dso name change, generally.  I did not
>>> claim that it is required, but if we are serious about ABI for openssl
>>> libs in base, then it is.
>> 
>> Can we keep the symbols with a legacy ABI version as compat symbols?
> 
> The removed exports were leaked symbols that were internal to libcrypto. Nothing in the base system used them, and anything in ports using the ports version of OpenSSL wouldn’t have been able to use them either. Given that, is there a reason we should carry these exports forward?


(OpenSSL maintainer hat on)

I personally don’t think so. If there are libraries using the internal APIs they should break because they were using undocumented interfaces. The fact that they were added in the first place was a mistake. This happens [largely] because we ship our own Version.map files instead of relying on the ones provided by OpenSSL and juggling all of the symbols across versions with internal and public APIs gets a bit unwieldy.

I’ve been seriously considering moving to the OpenSSL provided Version.map files for later versions of OpenSSL so we don’t run into future problems. We unfortunately can’t do that now for older interfaces (AFAIK) because we released the libraries with those older versioned symbols; breaking that now could make in-place upgrades difficult (to say the least) going to newer major/minor versions of OpenSSL. This is one of the annoying deviations between the base and ports versions of OpenSSL that I honestly think should be reduced and/or eliminated.

There *might* be a way to “fix” it using subminor versioned libraries (we might support that — need to check), but I will not be backporting that change to stable branches *ever*.

Cheers,
-Enji