GLIBC_2.25 error

[weiw05]

Hi, I'm trying to see if I can use your library on older linux systems, e.g. debian 9, and I get a GLIBC_2.25 not found error (for explicit_bzero). Is there a way to compile without using the system's explicit_bzero?

[michaelforney]

Hmm... explicit_bzero should be provided through compat/explicit_bzero.c.

Could you share a full build log?

[weiw05]

Sorry I should've been more specific. I'm building on a system with explicit_bzero (Ubuntu 18), but would like to use the binary on an older system without (e.g. Debian 9). Is there an easy way to build this without using the system's explicit_bzero?

…

On Wed, Oct 26, 2022 at 1:50 AM Michael Forney ***@***.***> wrote: Hmm... explicit_bzero should be provided through compat/explicit_bzero.c. Could you share a full build log? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[michaelforney]

This should be the default build behavior. If you don't define -D HAVE_EXPLICIT_BZERO, then it will use the included version of explicit_bzero.

Are you doing anything special when building libtls-bearssl? A build log would still be helpful, as well as the binary that isn't working.

[weiw05]

Here is output from a plain Ubuntu18 docker image, building just BearSSL and libtls-bearssl (with no extra defines). The objdump at the end shows the dependency on GLIBC_2.25, which is not present on older systems. Build log attached at the end. Thanks. ***@***.***:/libtls-bearssl# cat /etc/os-release NAME="Ubuntu" VERSION="18.04.6 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.6 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic ***@***.***:/libtls-bearssl# ls libtls.* libtls.a libtls.pc.in libtls.so libtls.ver ***@***.***:/libtls-bearssl# objdump -T libtls.so |grep GLIBC_2.25 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.25 getentropy 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.25 __explicit_bzero_chk ***@***.***:/libtls-bearssl# Build log: ***@***.***:/libtls-bearssl# make c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls.o tls.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls_bio_cb.o tls_bio_cb.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls_client.o tls_client.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls_config.o tls_config.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls_conninfo.o tls_conninfo.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls_keypair.o tls_keypair.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls_ocsp.o tls_ocsp.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls_peer.o tls_peer.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls_server.o tls_server.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls_util.o tls_util.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o tls_verify.o tls_verify.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o bearssl.o bearssl.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o compat/explicit_bzero.o compat/explicit_bzero.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o compat/freezero.o compat/freezero.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o compat/reallocarray.o compat/reallocarray.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -c -o compat/timingsafe_memcmp.o compat/timingsafe_memcmp.c ar cr libtls.a tls.o tls_bio_cb.o tls_client.o tls_config.o tls_conninfo.o tls_keypair.o tls_ocsp.o tls_peer.o tls_server.o tls_util.o tls_verify.o bearssl.o compat/explicit_bzero.o compat/freezero.o compat/reallocarray.o compat/timingsafe_memcmp.o c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls.lo tls.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls_bio_cb.lo tls_bio_cb.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls_client.lo tls_client.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls_config.lo tls_config.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls_conninfo.lo tls_conninfo.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls_keypair.lo tls_keypair.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls_ocsp.lo tls_ocsp.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls_peer.lo tls_peer.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls_server.lo tls_server.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls_util.lo tls_util.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o tls_verify.lo tls_verify.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o bearssl.lo bearssl.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o compat/explicit_bzero.lo compat/explicit_bzero.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o compat/freezero.lo compat/freezero.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o compat/reallocarray.lo compat/reallocarray.c c99 -O -Wall -Wpedantic -D _GNU_SOURCE -I . -fPIC -c -o compat/timingsafe_memcmp.lo compat/timingsafe_memcmp.c sed -f version-script.sed Symbols.list >libtls.ver.tmp && mv libtls.ver.tmp libtls.ver c99 -shared -Wl,-soname,libtls.so.22 -Wl,--version-script=libtls.ver -o libtls.so tls.lo tls_bio_cb.lo tls_client.lo tls_config.lo tls_conninfo.lo tls_keypair.lo tls_ocsp.lo tls_peer.lo tls_server.lo tls_util.lo tls_verify.lo bearssl.lo compat/explicit_bzero.lo compat/freezero.lo compat/reallocarray.lo compat/timingsafe_memcmp.lo -l bearssl -l pthread

…

On Wed, Oct 26, 2022 at 3:49 PM Michael Forney ***@***.***> wrote: This should be the default build behavior. If you don't define -D HAVE_EXPLICIT_BZERO, then it will use the included version of explicit_bzero. Are you doing anything special when building libtls-bearssl? A build log would still be helpful, as well as the binary that isn't working. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[michaelforney]

Thanks. I think I see what is happening. The actual missing symbol is not explicit_bzero, but __explicit_bzero_chk, which comes from glibc's fortify source feature. I guess this must be the default for your toolchain. This is causing explicit_bzero to get defined to an inline function calling glibc's checked version, so even though we build in an implementation of explicit_bzero, the callers are using __explicit_bzero_chk.

I will have to think about how best to solve this. In the mean time, building with -DFORTIFY_SOURCE=0 should work around the issue.

[weiw05]

Thanks Michael, this workaround works.

…

On Sun, Oct 30, 2022 at 7:09 PM Michael Forney ***@***.***> wrote: Thanks. I think I see what is happening. The actual missing symbol is not explicit_bzero, but __explicit_bzero_chk, which comes from glibc's fortify source feature. I guess this must be the default for your toolchain. This is causing explicit_bzero to get defined to an inline function calling glibc's checked version, so even though we build in an implementation of explicit_bzero, the callers are using __explicit_bzero_chk. I will have to think about how best to solve this. In the mean time, building with -DFORTIFY_SOURCE=0 should work around the issue. — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC4EMXAV4XF7YP2N3DNRTLWF35ZBANCNFSM6AAAAAAROMYHL4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[weiw05]

Btw, do you accept pull requests for bug fixes and enhancements? If so, is it through Github?

…

On Mon, Oct 31, 2022 at 2:47 PM Wei Wang ***@***.***> wrote: Thanks Michael, this workaround works. On Sun, Oct 30, 2022 at 7:09 PM Michael Forney ***@***.***> wrote: > Thanks. I think I see what is happening. The actual missing symbol is not > explicit_bzero, but __explicit_bzero_chk, which comes from glibc's > fortify source feature. I guess this must be the default for your > toolchain. This is causing explicit_bzero to get defined to an inline > function calling glibc's checked version, so even though we build in an > implementation of explicit_bzero, the callers are using > __explicit_bzero_chk. > > I will have to think about how best to solve this. In the mean time, > building with -DFORTIFY_SOURCE=0 should work around the issue. > > — > Reply to this email directly, view it on GitHub > <#3 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAC4EMXAV4XF7YP2N3DNRTLWF35ZBANCNFSM6AAAAAAROMYHL4> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >