[ 
https://issues.apache.org/jira/browse/THRIFT-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer updated THRIFT-6185:
-------------------------------
    Description: 
The OpenSSL-dependent modules in lib/d do not link against OpenSSL 3.x. On 
Ubuntu 24.04 (OpenSSL 3.0.13) the first SSL unittest binary fails at link:

{code}
dmd -g -ofunittest/debug/thrift/async/ssl -unittest -w -wi -I../../lib/d/src    
 -version=use_openssl_1_0_x -L-fuse-ld=gold -L-levent -L-lssl -L-lcrypto     
src/thrift/async/ssl.d libthriftd-event.a libthriftd-ssl.a libthriftd.a 
unittest/emptymain.d

libthriftd-ssl.a(ssl_347_3db.o):src/thrift/internal/ssl.d:
  error: undefined reference to 'SSL_get_peer_certificate'
libthriftd-ssl.a(ssl_bio_34b_356.o):src/thrift/internal/ssl_bio.d:
  error: undefined reference to 'ERR_put_error'
Error: linker exited with status 1
{code}

Two separate OpenSSL 3.0 changes:

* {{ERR_put_error}} was removed in 3.0. The replacement is {{ERR_new}} plus 
{{ERR_set_debug}} and {{ERR_set_error}}, or {{ERR_raise}}.
* {{SSL_get_peer_certificate}} was renamed to {{SSL_get1_peer_certificate}}. 
The old name survives only as a compatibility macro in the C header, so it is 
not an exported symbol a D binding can reach.

Three things line up behind this:

# lib/d/Makefile.am compiles with {{-version=use_openssl_1_0_x}} 
unconditionally, in both {{d_lib_flags}} and {{d_test_flags}}. There is no 1.1 
or 3.x variant of that version identifier anywhere in the tree.
# build/docker/ubuntu-*/Dockerfile pin the deimos OpenSSL bindings at 
{{v2.0.0+1.1.0h}}, which describe the 1.1.0 API.
# Of the three images, only ubuntu-focal ships an OpenSSL these two symbols 
still exist in (1.1.1f). jammy has 3.0.2 and noble has 3.0.13, so {{make -C 
lib/d check}} cannot pass in the project's own current images.

Affects five modules: thrift/async/ssl, thrift/internal/ssl, 
thrift/internal/ssl_bio, thrift/transport/ssl and thrift/server/transport/ssl. 
It is a link-time failure, so it is equally a problem for anyone using the D 
binding with TLS on a current distribution, not only for the build.

The CI job added in THRIFT-6170 works around it by not installing the deimos 
OpenSSL headers at all: configure then reports "Building D SSL tests ...... : 
no" and drops those five modules from both the library and the test set. The 
workflow step carries a comment pointing here. Once this is fixed, the headers 
should be installed in that job so the SSL modules are covered too.

Compare THRIFT-6168, which was the last lib/d change that had to be verified by 
hand.

----
Investigated and written with AI assistance (Claude Opus 5). The build failures 
quoted above were reproduced by hand in clean containers.

  was:
The OpenSSL-dependent modules in lib/d do not link against OpenSSL 3.x. On 
Ubuntu 24.04 (OpenSSL 3.0.13) the first SSL unittest binary fails at link:

{code}
dmd -g -ofunittest/debug/thrift/async/ssl -unittest -w -wi -I../../lib/d/src \
    -version=use_openssl_1_0_x -L-fuse-ld=gold -L-levent -L-lssl -L-lcrypto \
    src/thrift/async/ssl.d libthriftd-event.a libthriftd-ssl.a libthriftd.a 
unittest/emptymain.d

libthriftd-ssl.a(ssl_347_3db.o):src/thrift/internal/ssl.d:
  error: undefined reference to 'SSL_get_peer_certificate'
libthriftd-ssl.a(ssl_bio_34b_356.o):src/thrift/internal/ssl_bio.d:
  error: undefined reference to 'ERR_put_error'
Error: linker exited with status 1
{code}

Two separate OpenSSL 3.0 changes:

* {{ERR_put_error}} was removed in 3.0. The replacement is {{ERR_new}} plus 
{{ERR_set_debug}} and {{ERR_set_error}}, or {{ERR_raise}}.
* {{SSL_get_peer_certificate}} was renamed to {{SSL_get1_peer_certificate}}. 
The old name survives only as a compatibility macro in the C header, so it is 
not an exported symbol a D binding can reach.

Three things line up behind this:

# lib/d/Makefile.am compiles with {{-version=use_openssl_1_0_x}} 
unconditionally, in both {{d_lib_flags}} and {{d_test_flags}}. There is no 1.1 
or 3.x variant of that version identifier anywhere in the tree.
# build/docker/ubuntu-*/Dockerfile pin the deimos OpenSSL bindings at 
{{v2.0.0+1.1.0h}}, which describe the 1.1.0 API.
# Of the three images, only ubuntu-focal ships an OpenSSL these two symbols 
still exist in (1.1.1f). jammy has 3.0.2 and noble has 3.0.13, so {{make -C 
lib/d check}} cannot pass in the project's own current images.

Affects five modules: thrift/async/ssl, thrift/internal/ssl, 
thrift/internal/ssl_bio, thrift/transport/ssl and thrift/server/transport/ssl. 
It is a link-time failure, so it is equally a problem for anyone using the D 
binding with TLS on a current distribution, not only for the build.

The CI job added in THRIFT-6170 works around it by not installing the deimos 
OpenSSL headers at all: configure then reports "Building D SSL tests ...... : 
no" and drops those five modules from both the library and the test set. The 
workflow step carries a comment pointing here. Once this is fixed, the headers 
should be installed in that job so the SSL modules are covered too.

Compare THRIFT-6168, which was the last lib/d change that had to be verified by 
hand.


> lib/d does not build against OpenSSL 3.x
> ----------------------------------------
>
>                 Key: THRIFT-6185
>                 URL: https://issues.apache.org/jira/browse/THRIFT-6185
>             Project: Thrift
>          Issue Type: Bug
>          Components: Build Process, D - Library
>            Reporter: Jens Geyer
>            Priority: Major
>
> The OpenSSL-dependent modules in lib/d do not link against OpenSSL 3.x. On 
> Ubuntu 24.04 (OpenSSL 3.0.13) the first SSL unittest binary fails at link:
> {code}
> dmd -g -ofunittest/debug/thrift/async/ssl -unittest -w -wi -I../../lib/d/src  
>    -version=use_openssl_1_0_x -L-fuse-ld=gold -L-levent -L-lssl -L-lcrypto    
>  src/thrift/async/ssl.d libthriftd-event.a libthriftd-ssl.a libthriftd.a 
> unittest/emptymain.d
> libthriftd-ssl.a(ssl_347_3db.o):src/thrift/internal/ssl.d:
>   error: undefined reference to 'SSL_get_peer_certificate'
> libthriftd-ssl.a(ssl_bio_34b_356.o):src/thrift/internal/ssl_bio.d:
>   error: undefined reference to 'ERR_put_error'
> Error: linker exited with status 1
> {code}
> Two separate OpenSSL 3.0 changes:
> * {{ERR_put_error}} was removed in 3.0. The replacement is {{ERR_new}} plus 
> {{ERR_set_debug}} and {{ERR_set_error}}, or {{ERR_raise}}.
> * {{SSL_get_peer_certificate}} was renamed to {{SSL_get1_peer_certificate}}. 
> The old name survives only as a compatibility macro in the C header, so it is 
> not an exported symbol a D binding can reach.
> Three things line up behind this:
> # lib/d/Makefile.am compiles with {{-version=use_openssl_1_0_x}} 
> unconditionally, in both {{d_lib_flags}} and {{d_test_flags}}. There is no 
> 1.1 or 3.x variant of that version identifier anywhere in the tree.
> # build/docker/ubuntu-*/Dockerfile pin the deimos OpenSSL bindings at 
> {{v2.0.0+1.1.0h}}, which describe the 1.1.0 API.
> # Of the three images, only ubuntu-focal ships an OpenSSL these two symbols 
> still exist in (1.1.1f). jammy has 3.0.2 and noble has 3.0.13, so {{make -C 
> lib/d check}} cannot pass in the project's own current images.
> Affects five modules: thrift/async/ssl, thrift/internal/ssl, 
> thrift/internal/ssl_bio, thrift/transport/ssl and 
> thrift/server/transport/ssl. It is a link-time failure, so it is equally a 
> problem for anyone using the D binding with TLS on a current distribution, 
> not only for the build.
> The CI job added in THRIFT-6170 works around it by not installing the deimos 
> OpenSSL headers at all: configure then reports "Building D SSL tests ...... : 
> no" and drops those five modules from both the library and the test set. The 
> workflow step carries a comment pointing here. Once this is fixed, the 
> headers should be installed in that job so the SSL modules are covered too.
> Compare THRIFT-6168, which was the last lib/d change that had to be verified 
> by hand.
> ----
> Investigated and written with AI assistance (Claude Opus 5). The build 
> failures quoted above were reproduced by hand in clean containers.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to