[openssl-users] Building libcrypto/libssl without symbolic link

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

[openssl-users] Building libcrypto/libssl without symbolic link

Shanku Roy
Hello OpneSSL Community,


OpenSSL build system currently creates symbolic links to actual binaries and actual binaries are named as *.so.1.0.0 :

lrw-r--r-- root     root              2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0
-rw-r--r-- root     root      1988088 2015-04-10 02:27 libcrypto.so.1.0.0
lrw-r--r-- root     root              2015-04-10 02:33 libssl.so -> libssl.so.1.0.0
-rw-r--r-- root     root       354824 2015-04-10 02:27 libssl.so.1.0.0

Is there any configure option in OpenSSL build scripts to not generate the symbolic links and rather generate actual binary as libcrypto.so/libssl.so from the build process like following:

-rw-r--r-- root     root      1235987 2013-03-11 08:15 libcrypto.so
-rw-r--r-- root     root       268972 2013-03-11 08:15 libssl.so

If not then is there a simple way to modify OpenSSL build scripts to achieve this?


Thanks
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Building libcrypto/libssl without symbolic link

Viktor Dukhovni
On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote:

> lrw-r--r-- root     root              2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0
> -rw-r--r-- root     root      1988088 2015-04-10 02:27 libcrypto.so.1.0.0
>
> Is there any configure option in OpenSSL build scripts to not generate
> the symbolic links and rather generate actual binary as
> libcrypto.so/libssl.so from the build process like following:

The library "soname" is part of the ABI.  What platform are you
building for where it would not be appropriate to encode the ABI
compatibility name into the library name?

--
        Viktor.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Building libcrypto/libssl without symbolic link

Erik Forsberg-11
In reply to this post by Shanku Roy
Not sure what platform the other person is using, but, for the record
the soname 1.0.0 causes big problems on Solaris 11 and up. Solaris 11
ships an OpenSSL 1.0.0 version in standard library locations, if anyone just builds
anything higher than that, and do NOT modify build to add -R runtime
load paths, you will see the libssl built link with Solaris 11 libcrypto which is
not good. There are functions in 1.0.1 that do not exist in 1.0.0

I have seen a change in version naming strategy in main branch, so hopefully
this will soon be not an issue. FYI, changing LD_LIBRARY_PATH using crle, is
a bad idea on Solaris 11, made my boot environment un-bootable.

For Solaris at least, I think its a good idea to modify makefiles to always provide
the -R option to the linker. I have used that for a very long time, and avoided
any collisions with standard Solaris versions.


>-- Original Message --
>
>On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote:
>
>> lrw-r--r-- root     root              2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0
>> -rw-r--r-- root     root      1988088 2015-04-10 02:27 libcrypto.so.1.0.0
>>
>> Is there any configure option in OpenSSL build scripts to not generate
>> the symbolic links and rather generate actual binary as
>> libcrypto.so/libssl.so from the build process like following:
>
>The library "soname" is part of the ABI.  What platform are you
>building for where it would not be appropriate to encode the ABI
>compatibility name into the library name?
>
>--
> Viktor.
>_______________________________________________
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Building libcrypto/libssl without symbolic link

Shanku Roy
In reply to this post by Viktor Dukhovni
Am cross compiling the FIPS enabled version for Android; In Android, some apps are having trouble loading their bundled libcrypto library when the binary is named as *.so.1.0.0 instead of libcrypto.so as platform library.

 
----- Original Message -----
From: Viktor Dukhovni <[hidden email]>
To: [hidden email]
Cc:
Sent: Tuesday, April 21, 2015 11:47 PM
Subject: Re: [openssl-users] Building libcrypto/libssl without symbolic link

On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote:
> lrw-r--r-- root     root              2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0
> -rw-r--r-- root     root      1988088 2015-04-10 02:27 libcrypto.so.1.0.0
>
> Is there any configure option in OpenSSL build scripts to not generate
> the symbolic links and rather generate actual binary as
> libcrypto.so/libssl.so from the build process like following:

The library "soname" is part of the ABI.  What platform are you
building for where it would not be appropriate to encode the ABI
compatibility name into the library name?

--
    Viktor.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Building libcrypto/libssl without symbolic link

John Foley-3
Are you packaging libcrypto.so into the APK yourself?  The Android OS
comes with it's own resident copy of libcrypto.  You can leverage this
from your app without having to package libcrypto into your
application.  This assumes the version of libcrypto that comes with
Android meets your needs.  Given the various flavors of Android out in
the wild, this may limit what your application can do with libcrypto.

If you're packaging libcrypto into your APK, one problem I've seen in
Android is the System.LoadLibrary() call will use the host resident copy
of libcrypto instead of the one packaged in the APK.  One way to get
around this is to hack the linker step in the OpenSSL makefile to rename
libcrypto to something different.  You'll need to make sure the -soname
option on the linker step is consistent with whatever you name the
library.  For instance, you can name it libcryptoX.so, and pass in this
same name to the -soname option.  Confirm that it works using objdump to
view the ELF header.  The soname will be in the ELF header.  Then
package libcryptoX.so into your APK and use this name with the
System.LoadLibrary() call.



On 04/22/2015 09:41 AM, Shanku Roy wrote:

> Am cross compiling the FIPS enabled version for Android; In Android, some apps are having trouble loading their bundled libcrypto library when the binary is named as *.so.1.0.0 instead of libcrypto.so as platform library.
>
>  
> ----- Original Message -----
> From: Viktor Dukhovni <[hidden email]>
> To: [hidden email]
> Cc:
> Sent: Tuesday, April 21, 2015 11:47 PM
> Subject: Re: [openssl-users] Building libcrypto/libssl without symbolic link
>
> On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote:
>> lrw-r--r-- root     root              2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0
>> -rw-r--r-- root     root      1988088 2015-04-10 02:27 libcrypto.so.1.0.0
>>
>> Is there any configure option in OpenSSL build scripts to not generate
>> the symbolic links and rather generate actual binary as
>> libcrypto.so/libssl.so from the build process like following:
> The library "soname" is part of the ABI.  What platform are you
> building for where it would not be appropriate to encode the ABI
> compatibility name into the library name?
>


_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Building libcrypto/libssl without symbolic link

Jakob Bohm-7
(Top posting because some other posters did so).

Please note the following problems with the so naming
defaults in version 1.0.2a:

1. On Android, developers are (or were until recently)
officially told *not* to rely on the system copy of OpenSSL,
since it is not part of the official API.  Thus packaging
your own copy or relying on the botched version of Java
JCE implemented on top of the system OpenSSL are the only
officially supported options.

2. On many systems that install OpenSSL 1.0.1 (any patch
level) as libcrypto.so.1.0.0, installing OpenSSL 1.0.2a
as libcrypto.so.1.0.0 will instantly break system software
linked against the 1.0.1 under the same ABI name.  So much
for binary compatibility.

Thus for Android, you would want to link it as
libcom_yourdomain_yourapp_crypto.so (file name must match
lib*.so for theapk to unpack correctly), or as a static
PIC library, making the system think it has nothing to do
with any well-known or other app's copy of OpenSSL. Be
sure to release new versions of your app whenever an
OpenSSL security update affects something you actually use
from the library.

For parallel installation of OpenSSL 1.0.2a and the OS
supplied OpenSSL 1.0.1 (with patches equivalent to the
latest release), modify SHLIB_VERSION_NUMBER from 1.0.0
to 1.0.2 in the folliwing files from the tarball:

crypto/opensslv.h
Makefile
Makefile.bak

I have pasted the patch I use at the end of this mail
(nothing cryptographic, soI think I can post that without
extra red tape).



On 22/04/2015 16:26, John Foley wrote:

> Are you packaging libcrypto.so into the APK yourself?  The Android OS
> comes with it's own resident copy of libcrypto.  You can leverage this
> from your app without having to package libcrypto into your
> application.  This assumes the version of libcrypto that comes with
> Android meets your needs.  Given the various flavors of Android out in
> the wild, this may limit what your application can do with libcrypto.
>
> If you're packaging libcrypto into your APK, one problem I've seen in
> Android is the System.LoadLibrary() call will use the host resident copy
> of libcrypto instead of the one packaged in the APK.  One way to get
> around this is to hack the linker step in the OpenSSL makefile to rename
> libcrypto to something different.  You'll need to make sure the -soname
> option on the linker step is consistent with whatever you name the
> library.  For instance, you can name it libcryptoX.so, and pass in this
> same name to the -soname option.  Confirm that it works using objdump to
> view the ELF header.  The soname will be in the ELF header.  Then
> package libcryptoX.so into your APK and use this name with the
> System.LoadLibrary() call.
>
>
>
> On 04/22/2015 09:41 AM, Shanku Roy wrote:
>> Am cross compiling the FIPS enabled version for Android; In Android, some apps are having trouble loading their bundled libcrypto library when the binary is named as *.so.1.0.0 instead of libcrypto.so as platform library.
>>
>>  
>> ----- Original Message -----
>> From: Viktor Dukhovni <[hidden email]>
>> To: [hidden email]
>> Cc:
>> Sent: Tuesday, April 21, 2015 11:47 PM
>> Subject: Re: [openssl-users] Building libcrypto/libssl without symbolic link
>>
>> On Wed, Apr 22, 2015 at 12:12:45AM +0000, Shanku Roy wrote:
>>> lrw-r--r-- root     root              2015-04-10 02:33 libcrypto.so -> libcrypto.so.1.0.0
>>> -rw-r--r-- root     root      1988088 2015-04-10 02:27 libcrypto.so.1.0.0
>>>
>>> Is there any configure option in OpenSSL build scripts to not generate
>>> the symbolic links and rather generate actual binary as
>>> libcrypto.so/libssl.so from the build process like following:
>> The library "soname" is part of the ABI.  What platform are you
>> building for where it would not be appropriate to encode the ABI
>> compatibility name into the library name?


(Beware of long lines in this patch)
=================== Cut here ===================
diff -Naur openssl-1.0.2a.orig/crypto/opensslv.h
openssl-1.0.2a/crypto/opensslv.h
--- openssl-1.0.2a.orig/crypto/opensslv.h    2015-03-19
14:31:16.000000000 +0100
+++ openssl-1.0.2a/crypto/opensslv.h    2015-03-22 23:10:15.000000000 +0100
@@ -88,7 +88,7 @@
   * should only keep the versions that are binary compatible with the
current.
   */
  # define SHLIB_VERSION_HISTORY ""
-# define SHLIB_VERSION_NUMBER "1.0.0"
+# define SHLIB_VERSION_NUMBER "1.0.2"


  #ifdef  __cplusplus
diff -Naur openssl-1.0.2a.orig/Makefile openssl-1.0.2a/Makefile
--- openssl-1.0.2a.orig/Makefile    2015-03-19 14:31:16.000000000 +0100
+++ openssl-1.0.2a/Makefile    2015-03-22 23:06:50.000000000 +0100
@@ -7,10 +7,10 @@
  VERSION=1.0.2a
  MAJOR=1
  MINOR=0.2
-SHLIB_VERSION_NUMBER=1.0.0
+SHLIB_VERSION_NUMBER=1.0.2
  SHLIB_VERSION_HISTORY=
  SHLIB_MAJOR=1
-SHLIB_MINOR=0.0
+SHLIB_MINOR=0.2
  SHLIB_EXT=
  PLATFORM=dist
  OPTIONS= no-ec_nistp_64_gcc_128 no-gmp no-jpake no-krb5 no-libunbound
no-md2 no-rc5 no-rfc3779 no-sctp no-shared no-ssl-trace no-store
no-unit-test no-zlib no-zlib-dynamic static-engine
diff -Naur openssl-1.0.2a.orig/Makefile.bak openssl-1.0.2a/Makefile.bak
--- openssl-1.0.2a.orig/Makefile.bak    2015-03-19 14:30:59.000000000 +0100
+++ openssl-1.0.2a/Makefile.bak    2015-03-22 23:07:01.000000000 +0100
@@ -7,10 +7,10 @@
  VERSION=1.0.2a-dev
  MAJOR=1
  MINOR=0.2
-SHLIB_VERSION_NUMBER=1.0.0
+SHLIB_VERSION_NUMBER=1.0.2
  SHLIB_VERSION_HISTORY=
  SHLIB_MAJOR=1
-SHLIB_MINOR=0.0
+SHLIB_MINOR=0.2
  SHLIB_EXT=
  PLATFORM=gcc
  OPTIONS= no-ec_nistp_64_gcc_128 no-gmp no-jpake no-krb5 no-libunbound
no-md2 no-rc5 no-rfc3779 no-sctp no-shared no-ssl-trace no-store
no-unit-test no-zlib no-zlib-dynamic static-engine

=================== Cut here ===================

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Building libcrypto/libssl without symbolic link

Viktor Dukhovni
On Wed, Apr 22, 2015 at 09:04:04PM +0200, Jakob Bohm wrote:

> For parallel installation of OpenSSL 1.0.2a and the OS
> supplied OpenSSL 1.0.1 (with patches equivalent to the
> latest release), modify SHLIB_VERSION_NUMBER from 1.0.0
> to 1.0.2 in the folliwing files from the tarball:

The ABI version really is 1.0.0.  Symbol versioning is the right
way to distinguish between 1.0.[012].  The Debian OpenSSL build
does symbol versioning to avoid conflicts between multiple libraries
that support the 1.0.0 ABI.

Yes, the ABI compatibility is only backwards compatibility, so
applications that link to a newer version of the library at compile
time, need to use the same or newer library at run-time.

Applications using a non-system library need to record a suitable
RPATH (often using "$ORIGIN" is a good bet if the application ships
a copy of the library).  Ideally applications would use the system
supplied library, otherwise patching becomes rather difficult...

--
        Viktor.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Building libcrypto/libssl without symbolic link

h15234
On Wed, Apr 22, 2015, at 12:49 PM, Viktor Dukhovni wrote:
> Applications using a non-system library need to record a suitable
> RPATH (often using "$ORIGIN" is a good bet if the application ships
> a copy of the library).  Ideally applications would use the system
> supplied library, otherwise patching becomes rather difficult...

Along similar lines, it would be useful to get RPATH'ing *in* openssl straigthened out

 "openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's"
  https://marc.info/?l=openssl-users&m=142858615805070&w=2

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Building libcrypto/libssl without symbolic link

Jakob Bohm-7
In reply to this post by Viktor Dukhovni
On 22/04/2015 21:49, Viktor Dukhovni wrote:
On Wed, Apr 22, 2015 at 09:04:04PM +0200, Jakob Bohm wrote:

For parallel installation of OpenSSL 1.0.2a and the OS
supplied OpenSSL 1.0.1 (with patches equivalent to the
latest release), modify SHLIB_VERSION_NUMBER from 1.0.0
to 1.0.2 in the folliwing files from the tarball:
The ABI version really is 1.0.0.  Symbol versioning is the right
way to distinguish between 1.0.[012].  The Debian OpenSSL build
does symbol versioning to avoid conflicts between multiple libraries
that support the 1.0.0 ABI.

Yes, the ABI compatibility is only backwards compatibility, so
applications that link to a newer version of the library at compile
time, need to use the same or newer library at run-time.

Applications using a non-system library need to record a suitable
RPATH (often using "$ORIGIN" is a good bet if the application ships
a copy of the library).  Ideally applications would use the system
supplied library, otherwise patching becomes rather difficult...

My observations were actually made on Debian.  And I seem to recall
it
was the system daemons that failed, not my newly recompiled
daemons,
though I may of cause be mistaken.

As for symbol versioning, if that is not in the upstream tarball,
any such
things added by vendor compiles is just going to break
the ABI, in fact
the absence of symbol versioning in my vanilla
compile may be what
caused the problems for all the installed
packages.
Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users