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

On Sun, Oct 11, 2026 at 07:21:16AM +0000, Robert Clausecker wrote:
> Hi Gordon,
> 
> On Sat, Oct 10, 2026 at 10:53:33PM -0400, Gordon Tetlow 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?
> 
> Yes: the reason is that we should strive to promise compatibility, even to our
> own bugs.  It doesn't hurt to put these symbols in as compat symbols (which in
> particular should mean that they won't be accessible by newly compiled binaries),
> as the routines do in fact exist.
> 
> With the next major version of FreeBSD we can then do a somajor bump and get
> rid of them if desired.

I fully support both the opinion expressed by Robert, and the proposed
solution.

In fact, there _is_ the the observable consequence of the ABI breakage.
The need to be careful and upgrade libcrypto and libssl simultaneously
is exactly the breakage.