Page MenuHomeFreeBSD

openssl: make libcrypto export the same symbols as upstream
ClosedPublic

Authored by gordon on Tue, Oct 6, 12:14 AM.
Tags
None
Referenced Files
F176366935: D60397.id188778.diff
Sun, Oct 18, 6:59 AM
Unknown Object (File)
Sat, Oct 17, 1:45 PM
Unknown Object (File)
Thu, Oct 15, 7:45 PM
Unknown Object (File)
Wed, Oct 14, 4:27 PM
Unknown Object (File)
Wed, Oct 14, 3:21 PM
Unknown Object (File)
Wed, Oct 14, 1:29 PM
Unknown Object (File)
Wed, Oct 14, 9:18 AM
Unknown Object (File)
Wed, Oct 14, 6:41 AM
Subscribers

Details

Summary

Make the libcrypto Version.map export the same symbol names as upstream
3.5.8.

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.

Add 7 public names that were missing (ASYNC_get_mem_functions,
ASYNC_set_mem_functions, CMS_EnvelopedData_it, EVP_CipherPipeline*) to
OPENSSL_3_5_0, where the other symbols from upstream 3.1 to 3.5 are.

The version node names do not change. EC_GFp_nistp224_method,
EC_GFp_nistp256_method and EC_GFp_nistp521_method stay unexported
(6f6446b33064).

Compatibility: libssl.so.35 from earlier builds imports the removed
internal symbols, so it does not load with this libcrypto.so.35.
libcrypto and libssl must be updated together. This change needs the
previous libssl change, which gives libssl its own copies. On the test
host, nothing else in the base system (including lib32) imports a
removed symbol, and neither do the few installed ports.

Tested on arm64: the build links with --no-undefined-version. The
libcrypto exports match upstream except for the three nistp methods
above. libssl, the engines, the legacy provider and openssl(1) load
with LD_BIND_NOW=1.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

This revision is now accepted and ready to land.Tue, Oct 6, 3:27 AM
markj added a subscriber: markj.

Do you have any script which could be used to verify the linker script after future imports?

Do you have any script which could be used to verify the linker script after future imports?

That would be really nice. I was working on automating this, but stalled on this effort -- partly due to other backups in the OpenSSL space submitting things upstream to them and pulling the changes back in to our repo.