|
Thanks for that Viktor - I'll see if the shlib_variant is
an option.
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> on behalf of Viktor Dukhovni <openssl-users@xxxxxxxxxxxx>
Sent: Monday, August 16, 2021 11:29 AM To: openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx> Subject: Re: One iOS App - 2 OpenSSL libraries. WARNING: This message originated outside of Ford Motor Company. Use caution when opening attachments, clicking links, or responding.
On Mon, Aug 16, 2021 at 12:57:54PM +0000, Goetzke, Arnold (A.P.) wrote: > We have a large application, and two vendors are using the OpenSSL > library in their project. However, only one of the projects encrypts > data successfully when joined in our application > > Is this a known limitation? On Linux and BSD systems, when recent versions of OpenSSL (e.g. 1.1.1) are built and used as dynamically linked libraries, the symbols in the libraries are "versioned". Provided that the two library builds use distinct non-overlapping symbol versions they can operate independently side by side. The OpenSSL build configuration templates have "shlib_variant" directive that can be used to build OpenSSL with a customized format of the symbol versions. On platforms where symbol versions are not employed, or are employed, but overlap between two distinct OpenSSL versions, having two versions of OpenSSL in the same address space can and will often lead to unpredictable results. Vendors should either stick to the platform's default OpenSSL (if there is one), or else if shipping OpenSSL along with their product use "shlib_variant" to inject a vendor-specific tag into all symbol versions. If symbol versioning is not a feature of iOS, then the only option is using Apple's APIs for all cryptography. -- Viktor. |
