Compiling OpenSSL shared libraries with custom name on Unix platforms

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiling OpenSSL shared libraries with custom name on Unix platforms

shivaramakrishna chakravarthula
Hello,

Is it possible to compile OpenSSL shared libraries with custom names on Linux/ Unix platforms to avoid conflicts with installed OpenSSL libraries? 
I have tried to modify the SHLIB_EXT in Configure script but it is not working. I am sure it is a common problem and someone in this group can help. 

Thanks in advance. 

Thanks,
Shiva 
Reply | Threaded
Open this post in threaded view
|

Re: Compiling OpenSSL shared libraries with custom name on Unix platforms

Ken Goldman-2

> From: shivaramakrishna chakravarthula <[hidden email]>
>
> Is it possible to compile OpenSSL shared libraries with custom
> names on Linux/ Unix platforms to avoid conflicts with installed
> OpenSSL libraries? 

> I have tried to modify the SHLIB_EXT in Configure script but it is
> not working. I am sure it is a common problem and someone in this
> group can help. 


If this is just for local testing, I typically build but don't
install.  By changing my paths, I can use the local copy.

If you're sure you have ABI compatibility, could you
manually copy and rename the .so files to /usr/include,
/usr/local/include  or equivalent?

Reply | Threaded
Open this post in threaded view
|

Re: Compiling OpenSSL shared libraries with custom name on Unix platforms

shivaramakrishna chakravarthula
Hi,

I have compatibility issues for my application with new versions of OpenSSL and I want to use the older version of OpenSSL with my application. So, I want to link my application with an OpenSSL library built with the custom name so that it works fine on all systems and I can be assured of using the desired OpenSSL version. I am using RPATH to locate the libraries in runtime and I want to make sure my libraries don't conflict with existing libraries. 

Thanks,
Shiva

On Tue, 14 Jul 2020 at 16:31, Kenneth Goldman <[hidden email]> wrote:

> From: shivaramakrishna chakravarthula <[hidden email]>
>
> Is it possible to compile OpenSSL shared libraries with custom
> names on Linux/ Unix platforms to avoid conflicts with installed
> OpenSSL libraries? 

> I have tried to modify the SHLIB_EXT in Configure script but it is
> not working. I am sure it is a common problem and someone in this
> group can help. 


If this is just for local testing, I typically build but don't
install.  By changing my paths, I can use the local copy.

If you're sure you have ABI compatibility, could you
manually copy and rename the .so files to /usr/include,
/usr/local/include  or equivalent?

Reply | Threaded
Open this post in threaded view
|

RE: Compiling OpenSSL shared libraries with custom name on Unix platforms

Michael Wojcik
> From: openssl-users <[hidden email]> On Behalf Of shivaramakrishna chakravarthula
> Sent: Tuesday, 14 July, 2020 08:59

> I have compatibility issues for my application with new versions of OpenSSL and
> I want to use the older version of OpenSSL with my application. So, I want to
> link my application with an OpenSSL library built with the custom name so that
> it works fine on all systems and I can be assured of using the desired OpenSSL
> version.

The right way to fix this, of course, is to fix your application so it works with a current, supported OpenSSL version.

Failing that, it would be best to link OpenSSL statically into your application. Then you don't have to worry about shared object location, and no one else will be using your outdated OpenSSL.

--
Michael Wojcik

Reply | Threaded
Open this post in threaded view
|

Re: Compiling OpenSSL shared libraries with custom name on Unix platforms

shivaramakrishna chakravarthula
That was something I have tried initially until I had problems with FIPS mode. I have compiled OpenSSL with FIPS support. But, I see FIPS self-tests failing when I link my application with OpenSSL static libraries. 

On Tue, 14 Jul 2020 at 17:57, Michael Wojcik <[hidden email]> wrote:
> From: openssl-users <[hidden email]> On Behalf Of shivaramakrishna chakravarthula
> Sent: Tuesday, 14 July, 2020 08:59

> I have compatibility issues for my application with new versions of OpenSSL and
> I want to use the older version of OpenSSL with my application. So, I want to
> link my application with an OpenSSL library built with the custom name so that
> it works fine on all systems and I can be assured of using the desired OpenSSL
> version.

The right way to fix this, of course, is to fix your application so it works with a current, supported OpenSSL version.

Failing that, it would be best to link OpenSSL statically into your application. Then you don't have to worry about shared object location, and no one else will be using your outdated OpenSSL.

--
Michael Wojcik

Reply | Threaded
Open this post in threaded view
|

Re: Compiling OpenSSL shared libraries with custom name on Unix platforms

OpenSSL - User mailing list
In reply to this post by shivaramakrishna chakravarthula
On Tue, Jul 14, 2020 at 04:58:38PM +0200, shivaramakrishna chakravarthula wrote:
> Hi,
>
> I have compatibility issues for my application with new versions of OpenSSL
> and I want to use the older version of OpenSSL with my application. So, I
> want to link my application with an OpenSSL library built with the custom
> name so that it works fine on all systems and I can be assured of using the
> desired OpenSSL version. I am using RPATH to locate the libraries in
> runtime and I want to make sure my libraries don't conflict with existing
> libraries.

How old is this "older version"?

The functionality you want sounds exactly like the "variant SONAMEs introduced
in commit https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb
but that's only in 1.1.0g and later.

-Ben
Reply | Threaded
Open this post in threaded view
|

Re: Compiling OpenSSL shared libraries with custom name on Unix platforms

shivaramakrishna chakravarthula
This is exactly similar to what I am looking for. I am using 1.0.2J version and there are some changes in the next version onwards that causes problems in SSL connections to older versions when DH key = 256 bytes are used. For backward compatibility reasons, I need to continue supporting 256 bytes DH keys for some more time and hence I want to stay on 1.0.2J version for now. 

Anyways, Thanks for sharing the details. 

Thanks,
Shiva 

On Tue, 14 Jul 2020 at 19:03, Benjamin Kaduk <[hidden email]> wrote:
On Tue, Jul 14, 2020 at 04:58:38PM +0200, shivaramakrishna chakravarthula wrote:
> Hi,
>
> I have compatibility issues for my application with new versions of OpenSSL
> and I want to use the older version of OpenSSL with my application. So, I
> want to link my application with an OpenSSL library built with the custom
> name so that it works fine on all systems and I can be assured of using the
> desired OpenSSL version. I am using RPATH to locate the libraries in
> runtime and I want to make sure my libraries don't conflict with existing
> libraries.

How old is this "older version"?

The functionality you want sounds exactly like the "variant SONAMEs introduced
in commit https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb
but that's only in 1.1.0g and later.

-Ben
Reply | Threaded
Open this post in threaded view
|

Re: Compiling OpenSSL shared libraries with custom name on Unix platforms

OpenSSL - User mailing list
On Tue, Jul 14, 2020 at 09:08:10PM +0200, shivaramakrishna chakravarthula wrote:
> This is exactly similar to what I am looking for. I am using 1.0.2J version
> and there are some changes in the next version onwards that causes problems
> in SSL connections to older versions when DH key = 256 bytes are used. For
> backward compatibility reasons, I need to continue supporting 256 bytes DH
> keys for some more time and hence I want to stay on 1.0.2J version for now.
>
> Anyways, Thanks for sharing the details.

Ah, thanks for the details.
The change I linked to is not going to be of much use to you, since the build system
got completely redone between those versions.

I will note that, at least on some systems, you can use sed to change the SONAME
of the compiled library before/during the installation process, which may
be enough of a workaround for your purposes.

-Ben