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

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?

Best,
Gordon