Subject: Libpq linked statically linked to OpenSSL/LibreSSL

From: Marco Bambini <[email-masked]>
Date: Sun, 4 Dec 2022 14:22:07 +0100

Hi all,

After several attempts, I am asking for help with how to compile libpq with OpenSSL statically linked.
I need to have libpq linked with LibreSSL, but if I could statically link OpenSSL, I think I could switch the TLS libraries at compile time.

Any help would be really appreciated.
Thanks,
Marco

---

From: ALBERTO CABELLO SÁNCHEZ <[email-masked]>
Date: Mon, 5 Dec 2022 12:48:51 +0000

> I need to have libpq linked with LibreSSL, but if I could statically link OpenSSL, I think
> I could switch the TLS libraries at compile time.

Hi,

I'm not sure if it will work this way, but I think you could build libpq from source, then
enter src/interfaces/libpq and rebuild the final libpq manually including libssl.a, so redo
the step which creates libpq.so

gcc (blah blah blah) -o libpq.so.5.15 (more blah blah)

appending your libssl.a location (mine is /usr/lib/x86_64-linux-gnu/libssl.a) at the end.
It look prettier if you add it to the list of input ".o" files. You'll end with a bigger libpq.so.

That "15" is the PostgreSQL major version number. Yours could be different.

Hope that helps.

---

From: ALBERTO CABELLO SÁNCHEZ <[email-masked]>
Date: Mon, 5 Dec 2022 13:10:33 +0000

> redo the step which creates libpq.so appending your libssl.a location
> (mine is /usr/lib/x86_64-linux-gnu/libssl.a) at the end.

Just wanted to correct: you also have to remove "-lssl". So I guess you can just
substitute "-lssl" for libssl.a location in src/interfaces/libpq/Makefile (two occurrences)
and build as usual.

---

From: Marco Bambini <[email-masked]>
Date: Mon, 5 Dec 2022 17:47:07 +0100

Thanks Alberto,

This is a very promising approach.

I tried to modify the Makefile in src/interfaces/libpq/Makefile and I replaced the occurrences of -lssl and -lcrypto with:
/root/rothsoft/libressl-3.6.1/ssl/.libs/libssl.a
/root/rothsoft/libressl-3.6.1/crypto/.libs/libcrypto.a

The compilation process is OK but when I tried to execute the test app I receive a link error:
Error loading DLL: /root/rothsoft/engines/postgreSQL/Linux/postgresql/libpq.so: undefined symbol: GENERAL_NAME_free

GENERAL_NAME_free usually means that libcrypto is missed.

Please note that I also tried with:
-l:/root/rothsoft/libressl-3.6.1/ssl/.libs/libssl.a
-l:/root/rothsoft/libressl-3.6.1/crypto/.libs/libcrypto.a

Thanks,
Marco

> On 5 Dec 2022, at 14:10, ALBERTO CABELLO SÁNCHEZ <[email-masked]> wrote:
> 
>>> Hi all,
>>>

---

From: Marco Bambini <[email-masked]>
Date: Tue, 6 Dec 2022 11:05:49 +0100

Hi,

I made some progresses, especially in understanding where the issue can be.

I started with a fresh postgresql-15.1 source code installation:
# ./configure --with-openssl --without-readline

I then modified the Makefile.global in the src directory by replacing the occurrences of -lssl and -lcrypto with:
/root/rothsoft/libressl-3.6.1/ssl/.libs/libssl.a /root/rothsoft/libressl-3.6.1/crypto/.libs/libcrypto.a
in the LIBS entry.

Then from src/interfaces/libpq I executed:
# make

libpq was successfully created but when I perform a:
# nm -D libpq.so

the output looks like:

000000000001f110 T appendBinaryPQExpBuffer
000000000001f000 T appendPQExpBuffer
000000000001f0d0 T appendPQExpBufferChar
000000000001f150 T appendPQExpBufferStr
                 U ASN1_STRING_data
                 U ASN1_STRING_length
                 U BIO_clear_flags
                 U BIO_int_ctrl
                 U BIO_new
                 U BIO_set_flags
                 U BIO_s_socket
                 U calloc
                 U close
                 U connect
000000000001ecd0 T createPQExpBuffer
                 U CRYPTO_get_id_callback
                 U CRYPTO_get_locking_callback
                 U CRYPTO_num_locks
                 U CRYPTO_set_id_callback
                 U CRYPTO_set_locking_callback
                 U __ctype_b_loc
                 U __ctype_tolower_loc
                 U __ctype_toupper_loc
                 w __cxa_finalize
000000000001ed30 T destroyPQExpBuffer
                 U ENGINE_by_id
                 U ENGINE_finish
                 U ENGINE_free
                 U ENGINE_init
                 U ENGINE_load_private_key
000000000001ed90 T enlargePQExpBuffer
                 U ERR_clear_error
                 U ERR_get_error
                 U __errno_location
                 U ERR_put_error
                 U ERR_reason_error_string
                 U EVP_DigestFinal_ex
                 U EVP_DigestInit_ex
...

Please notice all the U entries in the crypto/ssl functions, so it looks like that they are NOT statically linked inside the libpq.so shared library, even if I replaced the LIBS in the Makefile.

Anyone can help me with this issue?

Thanks,
Marco

> On 5 Dec 2022, at 17:47, Marco Bambini <[email-masked]> wrote:
> 
> Thanks Alberto,
>

---

From: Andres Freund <[email-masked]>
Date: Tue, 6 Dec 2022 10:01:00 -0800

Hi,

> /root/rothsoft/libressl-3.6.1/ssl/.libs/libssl.a /root/rothsoft/libressl-3.6.1/crypto/.libs/libcrypto.a

I think this is completely the wrong path. You should add libressl's include
and library directories to --with-includes=, --with-libraries=.

> Please notice all the U entries in the crypto/ssl functions, so it looks like that they are NOT statically linked inside the libpq.so shared library, even if I replaced the LIBS in the Makefile.

If there's also a shared version of libressl, you possibly would need to
specify that you'd want to link statically. Something like
-Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic

But I suspect that you're better of linking dynamically, specifying
--with-includes= --with-libraries= should provide a path towards that. It's
possible that you should add -Wl,-rpath,/path/to/libressl/lib to the LDFLAGS,
so that the dynamic version can be found at runtime.

Greetings,

Andres Freund

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 6 Dec 2022 13:24:22 -0500

> and library directories to --with-includes=, --with-libraries=.

The big point is that a compile-compatible library is not necessarily a
link-compatible library, and that LibreSSL is probably only
compile-compatible with OpenSSL, hence the need to use the LibreSSL
includes.

-- 
  Bruce Momjian  <[email-masked]>        https://momjian.us
  EDB                                      https://enterprisedb.com

Embrace your flaws.  They make you human, rather than perfect,
which you will never be.

---

From: Marco Bambini <[email-masked]>
Date: Thu, 8 Dec 2022 07:07:17 +0100

Hi all,

I tried to follow the advices from Andreas but without any luck.
I added the  --with-includes=, --with-libraries= arguments to the configure command (with path to my static LibreSSL libraries) and I also modified the Makefile.global with:
-Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic

The resulting libpq.so is bigger (in size) than the previous one but it continues to try to dynamically load the SSL functions.
# nm -D libpq.so

the output looks like:

I really don't know why it is so difficult to have the SSL libraries statically linked to libpq.
Any help would be greatly appreciated.

Thanks,
Marco

> On 6 Dec 2022, at 19:01, Andres Freund <[email-masked]> wrote:
> 
> Hi,
>

---

From: ALBERTO CABELLO SÁNCHEZ <[email-masked]>
Date: Fri, 9 Dec 2022 08:00:52 +0000

> Marco Bambini <[email-masked]> wrote:
>
> I added the  --with-includes=, --with-libraries= arguments to the configure
> command (with path to my static LibreSSL libraries) and I also modified the Makefile.global with:
> The resulting libpq.so is bigger (in size) than the previous one but it continues 
> to try to dynamically load the SSL functions.

This was also the result I got, -lssl seems to leave without effect the "-with-*" options.

---

From: Marco Bambini <[email-masked]>
Date: Sat, 10 Dec 2022 08:55:57 +0100

What sounds really odd is that I replaced all the occurrences of -lssl -lcrypto with the full path to the static libraries in all involved Makefile, but the resulting libpq.so library still has undefined links to the SSL functions.

> On 9 Dec 2022, at 09:00, ALBERTO CABELLO SÁNCHEZ <[email-masked]> wrote:
>