openssl: External symbols that don't follow the naming convention
Running a script over the .a files produced by a build reveals all defined global symbols that aren’t in the .num files. This majority of these will be false positives or historical. The script will also produce different output depending on the configuration options.
For a shared build, none of these should be exposed because the exported symbols are set. For a non-shared build, things are different.
#!/bin/sh
SRCDIR="."
OBJDIR="."
for l in crypto ssl
do
cut -f1 -d\ "$SRCDIR/util/lib$l.num" >/tmp/$$
nm -g --defined-only "$OBJDIR/lib$l.a" | grep -Fv -f /tmp/$$ >$l.symbols
rm -f /tmp/$$
done
edit: long list of functions deleted in preference of following list which includes only new functions since 1.1.1
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 44 (44 by maintainers)
Commits related to this issue
- Fix external symbols in the provider cipher implementations. Partial fix for #12964 This add ossl_ names for the following symbols. chacha20_dinit, chacha20_einit, chacha20_initctx, ccm_cipher, ccm... — committed to slontis/openssl by slontis 3 years ago
- Fix external symbols in the provider digest implementations. Partial fix for #12964 This adds ossl_ names for the following symbols: blake2b512_init,blake2b_final,blake2b_init,blake2b_init_key, bla... — committed to slontis/openssl by slontis 3 years ago
- Fix external symbols related to provider related security checks for keys and digests. Partial fix for #12964 This adds ossl_ names for the following symbols: digest_get_approved_nid, digest_get_ap... — committed to slontis/openssl by slontis 3 years ago
- Fix external symbols in the provider cipher implementations. Partial fix for #12964 This add ossl_ names for the following symbols. chacha20_dinit, chacha20_einit, chacha20_initctx, ccm_cipher, ccm... — committed to openssl/openssl by slontis 3 years ago
- Fix external symbols in the provider digest implementations. Partial fix for #12964 This adds ossl_ names for the following symbols: blake2b512_init,blake2b_final,blake2b_init,blake2b_init_key, bla... — committed to openssl/openssl by slontis 3 years ago
- Fix external symbols related to provider related security checks for keys and digests. Partial fix for #12964 This adds ossl_ names for the following symbols: digest_get_approved_nid, digest_get_ap... — committed to openssl/openssl by slontis 3 years ago
- Fix external symbols for cms. Partial fix for #12964 This adds ossl_ names for symbols related to cms_* and ess_* — committed to slontis/openssl by slontis 3 years ago
- Fix external symbols for pkcs7. Partial fix for #12964 This adds ossl_ names for symbols related to pkcs7_* — committed to slontis/openssl by slontis 3 years ago
- Fix external symbols for cms. Partial fix for #12964 This adds ossl_ names for symbols related to cms_* and ess_* Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openss... — committed to openssl/openssl by slontis 3 years ago
- Fix external symbols for pkcs7. Partial fix for #12964 This adds ossl_ names for symbols related to pkcs7_* Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/open... — committed to openssl/openssl by slontis 3 years ago
Hit them all. They should all be renamed. We should be as clean as possible for namespace usage. And these things are easy to review …
I suppose except maybe some of the libssl symbols the remaining symbols were there in 1.1.1 as well. And those new symbols in libssl do not introduce any new prefix as functions with tls_, tls1_, ssl_, ssl3_ were there definitely in 1.1.1 already. So IMO I think it is good enough. If anybody reports a real conflict with an existing application we can always consider further renames later.
The i2x and x2i pattern is already established, it would be very surprising to see that suddenly change, or worse, to have some prefixed with
ossl_and others not. So, good move.I’m looking for a third opinion. I don’t much mind either way, you don’t want them. Will anyone else weigh in? If not I’ll close that PR unmerged.