Bdtjtk

I have an existing pre-built .so shared library (let's call it libjniopenssl.so). It was built by third party on Debian Linux with OpenSSL 1.0.1k-3+deb8u4.
I had to run libjniopenssl.so on CentOS with OpenSSL 1.0.2k package.
Despite the OpenSSL versions are slightly different the API used by libjniopenssl.so were not changed between 1.0.1k and 1.0.2k - so I expected them to be source and binary compatible for my scenario.
Unfortunately just running libjniopenssl.so on CentOS does not work.

The libjniopenssl.so is loaded by JVM via System.loadLibrary, but it fails with the following error when running on CentOS:

Unable to load libjniopenssl: java.lang.UnsatisfiedLinkError: /tmp/jna-112200956/jna6604950569974562639.tmp:

libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

The reason is simple, there is no such file libcrypto.so.1.0.0 on CentOS, because OpenSSL 1.0.2k 16.el7 provides only following .so's:

$ ls -l /lib64/libcrypto*

lrwxrwxrwx. 1 root root      19 Jun  5  2018 /lib64/libcrypto.so.10 -> libcrypto.so.1.0.2k

-rwxr-xr-x. 1 root root 2512832 Apr 11  2018 /lib64/libcrypto.so.1.0.2k

For some reason CentOS package intentionally renamed .so file name from default libcrypto.so.1.0.0 to libcrypto.so.1.0.2k, even so when compiling that version from source it uses name libcrypto.so.1.0.0.

This error message suggested to try creating a symlink with name /lib64/libcrypto.so.1.0.0 which points to /lib64/libcrypto.so.1.0.2k

This resulted in the following error in run-time:

Unable to load libjniopenssl: java.lang.UnsatisfiedLinkError: /tmp/jna-112200956/jna2564265718506275007.tmp: 

/lib64/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /tmp/jna-112200956/jna2564265718506275007.tmp)

Inspecting libjniopenssl.so shown that there are following symbols referenced from OpenSSL:

$ readelf -Ws libjniopenssl.so



Symbol table '.dynsym' contains 40 entries:

Num:    Value          Size Type    Bind   Vis      Ndx Name

    0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND

    1: 0000000000000e98     0 SECTION LOCAL  DEFAULT    9

    2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__

    3: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses

    4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND EVP_CIPHER_CTX_init@OPENSSL_1.0.0 (2)

    5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND malloc@GLIBC_2.2.5 (3)

    6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND OPENSSL_add_all_algorithms_noconf@OPENSSL_1.0.0 (2)

    7: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND HMAC_CTX_cleanup@OPENSSL_1.0.0 (2)

    8: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND EVP_CipherUpdate@OPENSSL_1.0.0 (2)

    9: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTable

    10: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND ERR_load_crypto_strings@OPENSSL_1.0.0 (2)

    11: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND free@GLIBC_2.2.5 (3)

    12: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable

    13: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (3)

    14: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND HMAC_CTX_init@OPENSSL_1.0.0 (2)

    15: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND HMAC_Final@OPENSSL_1.0.0 (2)

    16: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND EVP_sha1@OPENSSL_1.0.0 (2)

    17: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND HMAC_Init_ex@OPENSSL_1.0.0 (2)

    18: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND HMAC_Update@OPENSSL_1.0.0 (2)

    19: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND EVP_CIPHER_CTX_cleanup@OPENSSL_1.0.0 (2)

    20: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND EVP_MD_size@OPENSSL_1.0.0 (2)

    21: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND EVP_aes_128_ctr@OPENSSL_1.0.1 (4)

But the libcrypto.so.1.0.2k on CentOS has symbols which has different postfix, for example:

readelf -Ws /lib64/libcrypto.so.1.0.2k | grep -iE "EVP_CIPHER_CTX_init"

705: 000000000012a6b0   151 FUNC    GLOBAL DEFAULT   13 EVP_CIPHER_CTX_init@@libcrypto.so.10

So, on CentOS postfix is @@libcrypto.so.10, but libjniopenssl.so was linked against shared library which has symbols with postfix @OPENSSL_1.0.0. That's probably why just adding symlink does not work.

The further investigation shown that Debian version of OpenSSL 1.0.1k has included many patches, including one which adds symbol versioning. It was introduced only in OpenSSL 1.1.0, but was back ported by someone who is providing Debian package to 1.0.1.

In contrary CentOS OpenSSL 1.0.2k package does not include that patch for symbol versioning (but they include other patches from 1.1.0 according to symbols in .so).

I could re-build libjniopenssl.so on CentOS against it's copy of OpenSSL, but it actually involving maintaining (building, storing, deploying) own copy of libjniopenssl.so which actually comes from third-party git repository. I don't like rebuild solution, so I'm looking for more elegant one. But I have to say that re-building is what recommended on CentOS forum.

One solution I could think of is generation during build or deploy time a special shim libcrypto.so.1.0.0 (based on target system-provided copy of libcrypto) which has renamed symbols as desired by libjniopenssl.so, but under the hood it will translate all calls to the original system-provided libcrypto.so.1.0.2k.

In general I'm looking for some tool or set of tools which is capable of automatically generating such a "shim/adapter/proxy" .so out of specified "implementation" .so, but with ability to redefine some or all symbols.
I've found that there is objcopy tool which has --redefine-symbol old=new, but it doesn't exactly do what I want: I don't want to copy any code from original .so, I do want to translate calls to original "implementation" .so.

UPD: It is occurred by running local experiment that objcopy does not support renaming of symbols in dynamic library. The problem confirmed from this mail thread.

Summarizing, my questions are:

1. Is there an existing util capable to generate such shared shim library for a specified .so file?


2. Or maybe there is a better way to solve this incompatibility between CentOS and Debian OpenSSL packages, assuming I don't want to modify neither third-party provided libjniopenssl.so nor OS provided copy of OpenSSL?