From: Marc Singer <e...@buici.com>
Date: Sat, Apr 7, 2012 at 12:27 PM
Subject: Re: Bug#667938: shellinabox: depends on unavailable packages
To: Sven Joachim <svenj...@gmx.de>
On Sat, Apr 7, 2012 at 12:09 PM, Sven Joachim <svenj...@gmx.de> wrote:
> On 2012-04-07 20:39 +0200, Marc Singer wrote:
>
> > On Sat, Apr 7, 2012 at 10:55 AM, Sven Joachim <svenj...@gmx.de> wrote:
> >>
> >> Apparently shellinaboxd is statically linked with ssl, which is bad.
>
> Sorry, should have read the build logs more carefully and actually
> peeked in the source code.
>
> > No, it's dynamically link at runtime which is good. :-)
>
> It dlopens libssl.so which is not good, since that file only exists if
> libssl-dev is installed.
>
Are you sure about that.
> ls -l libssl.*
-rw-r--r-- 1 root root 634382 Mar 31 12:00 libssl.a
lrwxrwxrwx 1 root root 15 Mar 31 12:00 libssl.so -> libssl.so.1.0.0
-rw-r--r-- 1 root root 383600 Mar 31 12:00 libssl.so.1.0.0
I've always thought that libX.so needs to be a symbolic link because the
executables
don't have the full name of the library. They link against libX.a. Yet
when I look into a
sample program that I've linked, it has the full name.
> strings sample | grep lib
/lib64/ld-linux-x86-64.so.2
libcrypto.so.1.0.0
libc.so.6
__libc_start_main
Hmm.
Still, I do believe that there is a stipulation in the dynamic linking
infrastructure that
libX.so points to the most recent version of the library. At least, I
think that used
to be the case.
>
> > I'm looking into how to get a Recommends: dependency on libssl without
> > knowing the soname a priori.
>
> Trick upstream into linking against ssl rather than dlopening it? Until
> that happens, I don't have a better idea than to patch libhttp/ssl.c:
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/libhttp/ssl.c b/libhttp/ssl.c
> index f9cb37f..0d39079 100755
> --- a/libhttp/ssl.c
> +++ b/libhttp/ssl.c
> @@ -298,7 +298,7 @@ static void loadSSL(void) {
> { { &X509_free }, "X509_free" }
> };
> for (unsigned i = 0; i < sizeof(symbols)/sizeof(symbols[0]); i++) {
> - if (!(*symbols[i].var = loadSymbol("libssl.so", symbols[i].fn))) {
> + if (!(*symbols[i].var = loadSymbol("libssl.so.1.0.0",
> symbols[i].fn))) {
> debug("Failed to load SSL support. Could not find \"%s\"",
> symbols[i].fn);
> for (unsigned j = 0; j < sizeof(symbols)/sizeof(symbols[0]); j++) {
> --8<---------------cut here---------------end--------------->8---
>
> and to add a "Recommends: libssl1.0.0" to debian/control. Of course,
> this will break on the next libssl soname change.
>
> Cheers,
> Sven
>
>
Sure, but that is more of a hack than the author wants. His design should
work as long
as the library links are in place.
My current path of investigation is to build another executable that links
against libcrypto
when the package is built. Then, I can generate dependencies from that
executable for the package.
Thanks for the input.
