Re: One iOS App - 2 OpenSSL libraries.

[Viktor Dukhovni]

> On 16 Aug 2021, at 11:33 am, Goetzke, Arnold (A.P.)  wrote:
> 
> Thanks for that Viktor - I'll see if the shlib_variant is an option.

Note that setting "shlib_variant" is something the vendor has to set
when building the bundled OpenSSL libraries.  The Configurations/README
file documents this as follows:

shlib_variant   => A "variant" identifier inserted between the base
   shared library name and the extension.  On "unixy"
   platforms (BSD, Linux, Solaris, MacOS/X, ...) this
   supports installation of custom OpenSSL libraries
   that don't conflict with other builds of OpenSSL
   installed on the system.  The variant identifier
   becomes part of the SONAME of the library and also
   any symbol versions (symbol versions are not used or
   needed with MacOS/X).  For example, on a system
   where a default build would normally create the SSL
   shared library as 'libssl.so -> libssl.so.1.1' with
   the value of the symlink as the SONAME, a target
   definition that sets 'shlib_variant => "-abc"' will
   create 'libssl.so -> libssl-abc.so.1.1', again with
   an SONAME equal to the value of the symlink.  The
   symbol versions associated with the variant library
   would then be 'OPENSSL_ABC_' rather than
   the default 'OPENSSL_'. The string inserted
   into symbol versions is obtained by mapping all
   letters in the "variant" identifier to upper case
   and all non-alphanumeric characters to '_'.

So the effect of shlib_variant is change both the shared object names (SONAME)
and its symbol versions (where applicable).  Applications linked with a
shlib_variant "libssl.so" and "libcrypto.so" will at runtime search for
"libssl-.so." and "libcrypto-.so.".

-- 
Viktor.

Re: One iOS App - 2 OpenSSL libraries.

[Goetzke, Arnold (A.P.)]

Thanks for that Viktor - I'll see if the shlib_variant is an option.


From: openssl-users  on behalf of Viktor 
Dukhovni 
Sent: Monday, August 16, 2021 11:29 AM
To: openssl-users@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 +, 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.

Re: One iOS App - 2 OpenSSL libraries.

[Viktor Dukhovni]

On Mon, Aug 16, 2021 at 12:57:54PM +, 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.

Re: One iOS App - 2 OpenSSL libraries.

[Dr Paul Dale]

There shouldn't be a limitation.  Although if two different versions of 
OpenSSL are being used, it is possible that they could interact together 
in odd ways.



OpenSSL will automatically use assembly implementations of algorithms 
unless:


* the "no-asm" option is specified at configuration time;
* the processor is detected, at run time, as being unable to support 
what we supply;

* there isn't such an implementation available.

I'm assuming that this is what you meant by "Bit-Code".


Paul Dale

On 16/8/21 10:57 pm, Goetzke, Arnold (A.P.) wrote:

Hi -

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?

Also, is there a way to enable Bit-Code for iOS when compiling?  I 
don't see build setting to enable Bit-Code in the configuration options.


https://wiki.openssl.org/index.php/Compilation_and_Installation 



Thanks for the help!

Arnold