Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

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

Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Chethan Kumar

Dear all,

 

While migrating from openssl 1.0.2n to openssl 1.1.1b, application which uses openssl was compiling against openssl 1.1.1b.

Compilation is fine but its linking to both libcrypto.so.1.0.0[from /usr/lib/] and libcrypto.so.1.1.

Its linking correctly to libssl.1.1.

Is this correct? If so, what could be the possible reason.

 

Thanks in advance,

Chethan Kumar

 

The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the
recipient and may contain privileged information. If you are not the intended recipient, please notify the
sender and delete the message along with any attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.

Reply | Threaded
Open this post in threaded view
|

RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Chethan Kumar

Dear all,

 

Any help for the below query would be appreciated.

 

Thanks in advance,

Chethan Kumar

 

From: openssl-users [mailto:[hidden email]] On Behalf Of Chethan Kumar
Sent: Wednesday, May 22, 2019 11:35 AM
To: [hidden email]
Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

 

Dear all,

 

While migrating from openssl 1.0.2n to openssl 1.1.1b, application which uses openssl was compiling against openssl 1.1.1b.

Compilation is fine but its linking to both libcrypto.so.1.0.0[from /usr/lib/] and libcrypto.so.1.1.

Its linking correctly to libssl.1.1.

Is this correct? If so, what could be the possible reason.

 

Thanks in advance,

Chethan Kumar

 

The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the
recipient and may contain privileged information. If you are not the intended recipient, please notify the
sender and delete the message along with any attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.

The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the
recipient and may contain privileged information. If you are not the intended recipient, please notify the
sender and delete the message along with any attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.

Reply | Threaded
Open this post in threaded view
|

Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Richard Levitte - VMS Whacker-2
In what way does it link to both?  What output do you get when running
'ldd' in your application?  Is it using some kind of dynamic module
that happens to be linked with an older OpenSSL version?

Cheers,
Richard

On Tue, 28 May 2019 06:59:27 +0200,
Chethan Kumar wrote:

>
>
> Dear all,
>
> Any help for the below query would be appreciated.
>
> Thanks in advance,
>
> Chethan Kumar
>
> From: openssl-users [mailto:[hidden email]] On Behalf Of Chethan Kumar
> Sent: Wednesday, May 22, 2019 11:35 AM
> To: [hidden email]
> Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1
>
> Dear all,
>
> While migrating from openssl 1.0.2n to openssl 1.1.1b, application which uses openssl was
> compiling against openssl 1.1.1b.
>
> Compilation is fine but its linking to both libcrypto.so.1.0.0[from /usr/lib/] and
> libcrypto.so.1.1.
>
> Its linking correctly to libssl.1.1.
>
> Is this correct? If so, what could be the possible reason.
>
> Thanks in advance,
>
> Chethan Kumar
>
> The information contained in this e-mail message and in any attachments/annexure/appendices is
> confidential to the
> recipient and may contain privileged information. If you are not the intended recipient, please
> notify the
> sender and delete the message along with any attachments/annexure/appendices. You should not
> disclose,
> copy or otherwise use the information contained in the message or any annexure. Any views
> expressed in this e-mail
> are those of the individual sender except where the sender specifically states them to be the
> views of
> Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> Although this transmission and any attachments are believed to be free of any virus or other
> defect that might affect any computer system into which it is received and opened, it is the
> responsibility of the recipient to ensure that it is virus free and no responsibility is accepted
> by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.
>
> The information contained in this e-mail message and in any attachments/annexure/appendices is
> confidential to the
> recipient and may contain privileged information. If you are not the intended recipient, please
> notify the
> sender and delete the message along with any attachments/annexure/appendices. You should not
> disclose,
> copy or otherwise use the information contained in the message or any annexure. Any views
> expressed in this e-mail
> are those of the individual sender except where the sender specifically states them to be the
> views of
> Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> Although this transmission and any attachments are believed to be free of any virus or other
> defect that might affect any computer system into which it is received and opened, it is the
> responsibility of the recipient to ensure that it is virus free and no responsibility is accepted
> by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.
>
>
--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Chethan Kumar
I  meant to say linking to both by doing ldd.
When ldd is done on application, both libcrypto.so.1.0.0 and libcrypto.1.1 is shown.
Here libcrypto.so.1.0.0 is taken from the one provided by OS.

> Is it using some kind of dynamic module that happens to be linked with an older OpenSSL version?
No, its not using any dynamic module.

Its built on platform: Linux version 4.4.130-cip23-eBN-kernel (jenkins@skelios-plt) (gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) )

-----Original Message-----
From: openssl-users [mailto:[hidden email]] On Behalf Of Richard Levitte
Sent: Tuesday, May 28, 2019 7:37 PM
To: [hidden email]
Subject: Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

In what way does it link to both?  What output do you get when running 'ldd' in your application?  Is it using some kind of dynamic module that happens to be linked with an older OpenSSL version?

Cheers,
Richard

On Tue, 28 May 2019 06:59:27 +0200,
Chethan Kumar wrote:

>
>
> Dear all,
>
> Any help for the below query would be appreciated.
>
> Thanks in advance,
>
> Chethan Kumar
>
> From: openssl-users [mailto:[hidden email]] On
> Behalf Of Chethan Kumar
> Sent: Wednesday, May 22, 2019 11:35 AM
> To: [hidden email]
> Subject: Application linking to both libcrypto.so.1.0.0 and
> libcrypto.so.1.1
>
> Dear all,
>
> While migrating from openssl 1.0.2n to openssl 1.1.1b, application
> which uses openssl was compiling against openssl 1.1.1b.
>
> Compilation is fine but its linking to both libcrypto.so.1.0.0[from
> /usr/lib/] and libcrypto.so.1.1.
>
> Its linking correctly to libssl.1.1.
>
> Is this correct? If so, what could be the possible reason.
>
> Thanks in advance,
>
> Chethan Kumar
>
> The information contained in this e-mail message and in any
> attachments/annexure/appendices is confidential to the recipient and
> may contain privileged information. If you are not the intended
> recipient, please notify the sender and delete the message along with
> any attachments/annexure/appendices. You should not disclose, copy or
> otherwise use the information contained in the message or any
> annexure. Any views expressed in this e-mail are those of the
> individual sender except where the sender specifically states them to
> be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> Although this transmission and any attachments are believed to be free
> of any virus or other defect that might affect any computer system
> into which it is received and opened, it is the responsibility of the
> recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.
>
> The information contained in this e-mail message and in any
> attachments/annexure/appendices is confidential to the recipient and
> may contain privileged information. If you are not the intended
> recipient, please notify the sender and delete the message along with
> any attachments/annexure/appendices. You should not disclose, copy or
> otherwise use the information contained in the message or any
> annexure. Any views expressed in this e-mail are those of the
> individual sender except where the sender specifically states them to
> be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> Although this transmission and any attachments are believed to be free
> of any virus or other defect that might affect any computer system
> into which it is received and opened, it is the responsibility of the
> recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.
>
>
--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

Reply | Threaded
Open this post in threaded view
|

RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Chethan Kumar
> Sent: Tuesday, May 28, 2019 08:49
>
> I  meant to say linking to both by doing ldd.
> When ldd is done on application, both libcrypto.so.1.0.0 and libcrypto.1.1 is
> shown.

Don't tell us about the ldd output. Show us. ldd output is short enough to include in an email message.

> > Is it using some kind of dynamic module that happens to be linked with an
> older OpenSSL version?
> No, its not using any dynamic module.

This is obviously incorrect. You've already noted that it's loading at least three - the two versions of libcrypto and libssl.

Your application may not be doing any explicit dynamic loading, but it has implicit dynamic loads. That's what ldd shows.

You haven't shown us the link line for the application.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Viktor Dukhovni
> On May 28, 2019, at 11:35 AM, Michael Wojcik <[hidden email]> wrote:
>
> Don't tell us about the ldd output. Show us. ldd output is short enough to include in an email message.

More useful than "ldd" output, is output from "readelf -d",
showing the NEEDED libraries, any RPATH, ...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Michael Richardson
In reply to this post by Chethan Kumar

In general, this occurs because you have some other libraries (from your
system) that link against libcrypto.so.1.0.0.  In theory, it should all just
work, but in practice I've often found my application did not work as
expected.

Specifically, I'd get a TLS end point that did not speak ECDSA (1.0 does not,
1.1 does).

You have make a pass through the shared objects that your application
references (ldd output), and then using ldd, you can discover which ones want
libcrypto.so.1.0.0, and then you either have to upgrade those libraries,
or you may have to compile them from source.

The last time I did this, I found it was libpqclient5 (a postgresql client
library), and that I was able to upgrade it to libpqclient10 rather than
resort to source code.
Minimal distributions like containerized alpinelinux also help to minimize
your dependancies.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [



signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Michael Wojcik
In reply to this post by Viktor Dukhovni
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Viktor Dukhovni
> Sent: Tuesday, May 28, 2019 14:21
>
> > On May 28, 2019, at 11:35 AM, Michael Wojcik
> <[hidden email]> wrote:
> >
> > Don't tell us about the ldd output. Show us. ldd output is short enough to
> include in an email message.
>
> More useful than "ldd" output, is output from "readelf -d",
> showing the NEEDED libraries, any RPATH, ...

Well, yes, for this specific case (i.e. when looking at a dynamic-loading issue for a platform that uses ELF binaries and has the readelf utility). But I was making a more generic point: don't just tell us how you interpreted the result of an investigation when you can reasonably show us the actual evidence as well.

This of course is part of the eternal and widespread problem of not knowing how to ask a good question. I'm trying to offer some general advice in that area (without being quite as verbose as ESR's "How To Ask Questions The Smart Way").

--
Michael Wojcik
Distinguished Engineer, Micro Focus

Reply | Threaded
Open this post in threaded view
|

RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Chethan Kumar
Dear all,

Sorry for the inconvenience caused by not asking query clearly.
Below is the output from ldd on application.
Seriously I didn't knew application uses these many libraries[Knew only the problem].
        linux-gate.so.1 (0xf76fc000)
        libpam.so.0 => /lib/i386-linux-gnu/libpam.so.0 (0xf6a63000)
        libldap-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/libldap-2.4.so.2 (0xf6a29000)
        libssl.so.1.1 => /home/SYSROM_SRC/build/release/lib/libssl.so.1.1 (0xf6990000)
        libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf6972000)
        libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xf689c000)
        libcrypto.so.1.1 => /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.1 (0xf65af000)
        libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 (0xf657e000)
        libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xf6566000)
        libext2fs.so.2 => /lib/i386-linux-gnu/libext2fs.so.2 (0xf6516000)
        libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf6511000)
        libdns.so.69 => /home/SYSROM_SRC/build/release/lib/libdns.so.69 (0xf635c000)
        libisc.so.62 => /home/SYSROM_SRC/build/release/lib/libisc.so.62 (0xf62e7000)
        librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf62de000)
        libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0 (0xf62d2000)
        libkrb5.so.25 => /home/SYSROM_SRC/build/release/lib/libkrb5.so.25 (0xf6259000)
        libgssapi.so.2 => /home/SYSROM_SRC/build/release/lib/libgssapi.so.2 (0xf6222000)
        libCryptolib.so.0 => /home/SYSROM_SRC/build/release/lib/libCryptolib.so.0 (0xf6191000)
        libimf.so => /mfp/lib/libimf.so (0xf5dd8000)
        libirng.so => /usr/lib/libirng.so (0xf5c6e000)
        libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf5c1a000)
        libcilkrts.so.5 => /usr/lib/libcilkrts.so.5 (0xf5bec000)
        libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf5afd000)
        libsvml.so => /mfp/lib/libsvml.so (0xf4bbf000)
        libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf4bab000)
        libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf4ba6000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf49e4000)
        liblber-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/liblber-2.4.so.2 (0xf49d9000)
        libsasl2.so.3 => /home/SYSROM_SRC/build/release/lib/libsasl2.so.3 (0xf49a4000)
        /lib/i386-linux-gnu/ld-linux.so.2 (0xf76fd000)
        libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xf49a0000)
        libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xf499b000)
        libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 (0xf494c000)
        libcom_err.so.1 => /home/SYSROM_SRC/build/release/lib/libcom_err.so.1 (0xf4948000)
        libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xf476b000)
        libcap.so.2 => /lib/i386-linux-gnu/libcap.so.2 (0xf4766000)
        libhx509.so.5 => /home/SYSROM_SRC/build/release/lib/libhx509.so.5 (0xf4720000)
        libheimsqlite.so.0 => /home/SYSROM_SRC/build/release/lib/libheimsqlite.so.0 (0xf46a9000)
        libhcrypto.so.4 => /home/SYSROM_SRC/build/release/lib/libhcrypto.so.4 (0xf4673000)
        libasn1.so.8 => /home/SYSROM_SRC/build/release/lib/libasn1.so.8 (0xf45cd000)
        libwind.so.0 => /home/SYSROM_SRC/build/release/lib/libwind.so.0 (0xf45a3000)
        libroken.so.18 => /home/SYSROM_SRC/build/release/lib/libroken.so.18 (0xf458d000)
        libcrypt.so.1 => /lib/i386-linux-gnu/libcrypt.so.1 (0xf455b000)
        libheimntlm.so.0 => /home/SYSROM_SRC/build/release/lib/libheimntlm.so.0 (0xf4555000)
        libintlc.so.5 => /mfp/lib/libintlc.so.5 (0xf44f1000)
        libkrb5.so.3 => /usr/lib/i386-linux-gnu/libkrb5.so.3 (0xf441d000)
        libattr.so.1 => /lib/i386-linux-gnu/libattr.so.1 (0xf4418000)

Here libcrypto.so.1.1 is newly generated using openssl 1.1.1b and libcrypto.so.1.0.0 is one provided by OS.
readelf for same application is below.

Dynamic section at offset 0xc29258 contains 48 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libpam.so.0]
 0x00000001 (NEEDED)                     Shared library: [libldap-2.4.so.2]
 0x00000001 (NEEDED)                     Shared library: [libssl.so.1.1]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libsqlite3.so.0]
 0x00000001 (NEEDED)                     Shared library: [libcrypto.so.1.1]
 0x00000001 (NEEDED)                     Shared library: [libk5crypto.so.3]
 0x00000001 (NEEDED)                     Shared library: [libresolv.so.2]
 0x00000001 (NEEDED)                     Shared library: [libext2fs.so.2]
 0x00000001 (NEEDED)                     Shared library: [libuuid.so.1]
 0x00000001 (NEEDED)                     Shared library: [libdns.so.69]
 0x00000001 (NEEDED)                     Shared library: [libisc.so.62]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libkrb5support.so.0]
 0x00000001 (NEEDED)                     Shared library: [libkrb5.so.25]
 0x00000001 (NEEDED)                     Shared library: [libgssapi.so.2]
 0x00000001 (NEEDED)                     Shared library: [libCryptolib.so.0]
 0x00000001 (NEEDED)                     Shared library: [libimf.so]
 0x00000001 (NEEDED)                     Shared library: [libirng.so]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libcilkrts.so.5]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libsvml.so]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [libssdk.so.0]
 0x0000000f (RPATH)                      Library rpath: [/home/ssdk-test/Matterhorn/Skelios2/B650.10/SYSROM_SRC/NoBuildItems/common/lib/:/opt/skelios/2.0/sysroots/core2-32-skelios-linux/usr/lib/i386-linux-gnu/../i386-linux-gnu/]
 0x0000000c (INIT)                       0x196c88
 0x0000000d (FINI)                       0xae062c
 0x00000004 (HASH)                       0x118
 0x6ffffef5 (GNU_HASH)                   0x13a94
 0x00000005 (STRTAB)                     0x56db4
 0x00000006 (SYMTAB)                     0x288f4
 0x0000000a (STRSZ)                      1027963 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000003 (PLTGOT)                     0xc2a628
 0x00000002 (PLTRELSZ)                   30184 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x18f6a0
 0x00000011 (REL)                        0x157be8
 0x00000012 (RELSZ)                      228024 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x1579c8
 0x6fffffff (VERNEEDNUM)                 9
 0x6ffffff0 (VERSYM)                     0x151d30
 0x6ffffffa (RELCOUNT)                   229
 0x00000000 (NULL)                       0x0

Let me know in case any more information is needed to resolve the problem.
Thanks in advance,
Chethan

-----Original Message-----
From: openssl-users [mailto:[hidden email]] On Behalf Of Michael Wojcik
Sent: Wednesday, May 29, 2019 2:52 AM
To: [hidden email]
Subject: RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

> From: openssl-users [mailto:[hidden email]] On
> Behalf Of Viktor Dukhovni
> Sent: Tuesday, May 28, 2019 14:21
>
> > On May 28, 2019, at 11:35 AM, Michael Wojcik
> <[hidden email]> wrote:
> >
> > Don't tell us about the ldd output. Show us. ldd output is short
> > enough to
> include in an email message.
>
> More useful than "ldd" output, is output from "readelf -d", showing
> the NEEDED libraries, any RPATH, ...

Well, yes, for this specific case (i.e. when looking at a dynamic-loading issue for a platform that uses ELF binaries and has the readelf utility). But I was making a more generic point: don't just tell us how you interpreted the result of an investigation when you can reasonably show us the actual evidence as well.

This of course is part of the eternal and widespread problem of not knowing how to ask a good question. I'm trying to offer some general advice in that area (without being quite as verbose as ESR's "How To Ask Questions The Smart Way").

--
Michael Wojcik
Distinguished Engineer, Micro Focus

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

Reply | Threaded
Open this post in threaded view
|

RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Michael Wojcik
> From: Chethan Kumar [mailto:[hidden email]]
> Sent: Wednesday, May 29, 2019 04:07
>
> Below is the output from ldd on application.
> Seriously I didn't knew application uses these many libraries[Knew only the
> problem].
>         linux-gate.so.1 (0xf76fc000)
>         libpam.so.0 => /lib/i386-linux-gnu/libpam.so.0 (0xf6a63000)
>         libldap-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/libldap-
> 2.4.so.2 (0xf6a29000)
>         libssl.so.1.1 => /home/SYSROM_SRC/build/release/lib/libssl.so.1.1
> (0xf6990000)
>         libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf6972000)
>         libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0
> (0xf689c000)
>         libcrypto.so.1.1 =>
> /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.1 (0xf65af000)
>         libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3
> (0xf657e000)
>         libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xf6566000)
>         libext2fs.so.2 => /lib/i386-linux-gnu/libext2fs.so.2 (0xf6516000)
>         libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf6511000)
>         libdns.so.69 => /home/SYSROM_SRC/build/release/lib/libdns.so.69
> (0xf635c000)
>         libisc.so.62 => /home/SYSROM_SRC/build/release/lib/libisc.so.62
> (0xf62e7000)
>         librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf62de000)
>         libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0
> (0xf62d2000)
>         libkrb5.so.25 => /home/SYSROM_SRC/build/release/lib/libkrb5.so.25
> (0xf6259000)
>         libgssapi.so.2 => /home/SYSROM_SRC/build/release/lib/libgssapi.so.2
> (0xf6222000)
>         libCryptolib.so.0 =>
> /home/SYSROM_SRC/build/release/lib/libCryptolib.so.0 (0xf6191000)
>         libimf.so => /mfp/lib/libimf.so (0xf5dd8000)
>         libirng.so => /usr/lib/libirng.so (0xf5c6e000)
>         libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf5c1a000)
>         libcilkrts.so.5 => /usr/lib/libcilkrts.so.5 (0xf5bec000)
>         libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf5afd000)
>         libsvml.so => /mfp/lib/libsvml.so (0xf4bbf000)
>         libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf4bab000)
>         libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf4ba6000)
>         libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf49e4000)
>         liblber-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/liblber-
> 2.4.so.2 (0xf49d9000)
>         libsasl2.so.3 => /home/SYSROM_SRC/build/release/lib/libsasl2.so.3
> (0xf49a4000)
>         /lib/i386-linux-gnu/ld-linux.so.2 (0xf76fd000)
>         libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xf49a0000)
>         libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xf499b000)
>         libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2
> (0xf494c000)
>         libcom_err.so.1 => /home/SYSROM_SRC/build/release/lib/libcom_err.so.1
> (0xf4948000)
>         libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/libcrypto.so.1.0.0
> (0xf476b000)

So either the application program depends on libcrypto.so.1.0.0, or one of the preceding libraries does. Some path through the dependency graph leads to libcrypto.so.1.0.0.

From the readelf output below, we see it's not the application program - that only depends on libcrypto.so.1.1. So it's one of the preceding libraries. There's a good chance it's one that comes from the OS library collection rather than a library you've built (though that's by no means certain), so let's focus on ones that aren't under /home/SYSROM_SRC.

Kerberos seems like a candidate, but a quick ldd on libk5crypto and libkrb5support doesn't show any libcrypto dependency. The same is true of libgssapi_krb5. Neither does libkeyutils.

OpenLDAP (libldap) is generally built using NSS rather than OpenSSL, so it doesn't usually link libcrypto.

None of the other OS libraries above look particularly likely to use libcrypto. So I'd suggest you use ldd on each of the libraries listed above to find out which is giving you the dependency on libcrypto.so.1.0.0. Or use LD_DEBUG to generate a loader report for your application, and work backward from that.

Writing a script to use readelf to generate a dependency graph report showing the path for each dependency is left as an exercise for the reader.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Viktor Dukhovni


> On May 29, 2019, at 9:43 AM, Michael Wojcik <[hidden email]> wrote:
>
> So either the application program depends on libcrypto.so.1.0.0, or one of the preceding libraries does. Some path through the dependency graph leads to libcrypto.so.1.0.0.

Not only is the application (dynamically) linked against two different
versions of OpenSSL's crypto library, it is also using both Heimdal and
MIT Kerberos, which may also cause some confusion if symbol versioning
does not fully take care of the overlapping APIs.

> Kerberos seems like a candidate, but a quick ldd on libk5crypto and libkrb5support doesn't show any libcrypto dependency. The same is true of libgssapi_krb5. Neither does libkeyutils.

Heimdal might be linked against OpenSSL.

> OpenLDAP (libldap) is generally built using NSS rather than OpenSSL, so it doesn't usually link libcrypto.

It is also often built against OpenSSL, the choice is rather platform-dependent.

This application is a classic case of DLL-hell.  On the OpenSSL side, it could
benefit from the "shlib_variant" feature of the 1.1.1 builds.  But if the base
system's OpenSSL libraries are adequate, the OP may be better off just using
those.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

Michael Richardson
In reply to this post by Chethan Kumar

Chethan Kumar <[hidden email]> wrote:
    > Sorry for the inconvenience caused by not asking query clearly.
    > Below is the output from ldd on application.

Right, and now you need to recursively go through the list with readelf or
ldd, and which out which one of these libraries then requires
libcrypto.1.0.0.
My bet is on some of the krb libraries, likely required by sqlite or
perhaps something else like this libCryptolib.so.0.
Also, run your application, and use "lsof -p PID" to see the list of
libraries loaded as some dependancies may be done at runtime by dlopen().


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


signature.asc (497 bytes) Download Attachment