One iOS App - 2 OpenSSL libraries.
Goetzke, Arnold (A.P.)
agoetzke at ford.com
Mon Aug 16 15:33:33 UTC 2021
Thanks for that Viktor - I'll see if the shlib_variant is an option.
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Viktor Dukhovni <openssl-users at dukhovni.org>
Sent: Monday, August 16, 2021 11:29 AM
To: openssl-users at openssl.org <openssl-users at openssl.org>
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
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
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
If symbol versioning is not a feature of iOS, then the only option is
using Apple's APIs for all cryptography.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users