THRIFT-6174: Enable TSSLSocket to build with OpenSSL 4.0 Client: cpp,c_glib

OpenSSL 4.0 removes SSLv3_method(), TLSv1_method(), TLSv1_1_method(), TLSv1_2_method(), ERR_remove_state() and ASN1_STRING_data(), and returns const pointers from X509_get_subject_name(), X509_NAME_get_entry() and X509_NAME_ENTRY_get_data(). Neither binding compiles against it.

The per-version methods are replaced by TLS_method() with the protocol window pinned through SSL_CTX_set_min_proto_version() and SSL_CTX_set_max_proto_version(), which is OpenSSL’s own documented migration and reproduces the old methods exactly: TLSv1_2_method() meant TLS 1.2 only, and min == max == TLS1_2_VERSION means the same. No enum value is dropped, so SSLv3, TLSv1_0, TLSv1_1, TLSv1_2 and LATEST keep working on 4.0 rather than starting to throw “Unknown protocol”.

The replacement is selected from 1.1.0 onwards rather than only on 4.0, because no CI configuration builds against 4.0: gating it there would ship a code path that nothing ever compiles, let alone runs. At >= 1.1.0 the existing SSL matrix tests cover it on the OpenSSL 3.x that CI does have. The same reasoning applies to the const qualifiers, whose consumers have all taken const since 1.1.0. LibreSSL is excluded throughout: it reports OPENSSL_VERSION_NUMBER as 0x20000000L but keeps the pre-1.1.0 signatures, so it stays on the path it compiles today.

SSLTLS is untouched. SSLv23_method() is not removed in 4.0 – it is an unconditional #define for TLS_method() – so that arm needed no change, and the protocol floor for it still comes from the SSL_CTX_set_options() call below, not from a version window.

SSLv3 keeps SSLv3_method() below 4.0, which is the only release that removes it, rather than becoming a TLS_method() window like the others: SSL_CTX_set_min_proto_version() consults the security level and would refuse SSL3_VERSION at the default one, where the method function does not, and the context is built before TSSLSocketFactory::ciphers() lowers it. On 4.0 the protocol is gone outright and the arm is compiled out.

ERR_remove_state() has been an empty stub since 1.1.0, so in c_glib it is gated to where it still does something: before 1.1.0, and on LibreSSL, which implements it and has never shipped OPENSSL_thread_stop(). The C++ binding gets the matching guard so LibreSSL reaches the ERR_remove_state() arm instead of losing per-thread cleanup on both paths.

Tests:

SecurityTest gains explicit_protocol_version_window, which asserts the min/max window per enum value instead of merely that a context was created – the latter passes on a remapping that silently leaves the floor to the library default. Proven two-state: with the window not pinned it fails 8 assertions, LATEST among them, reporting floor 0. It also asserts that an unavailable SSLv3 is reported rather than quietly satisfied with another version.
Both matrix tests skip SSLv3 on 4.0. OPENSSL_NO_SSL3 is not defined there, so without this they try SSLv3 and time out.
testtransportsslsocket gains the same two cases for c_glib.
TSSLSocketMatchNameTest built its subject name through X509_get_subject_name(), which is const as of 4.0, then mutated it; it now builds a separate X509_NAME. It also had no SIGPIPE handler while deliberately provoking rejected handshakes, so it died with status 141 in 6 of 20 runs before this change and 11 of 20 after – the allocation pattern shifts the race. It is ignored now, as SecurityTest already does, and 25 of 25 runs pass.

Verified by building and running lib/cpp and lib/c_glib against three libraries: the distribution OpenSSL 3.0.2, a from-source 4.0.2, and a from-source 3.0.2 configured with enable-ssl3 so that the one otherwise uncompiled arm is covered. All 16 matrix cells pass identically on the first two, and all 25 on the third – cell for cell what master produces there. Unpatched master fails to compile against 4.0.2 with 7 errors in C++ and 5 in c_glib.

Co-Authored-By: Sebastian Andrzej Siewior sebastian@breakpoint.cc Co-Authored-By: Jaipaul Cheernam jaipaul.cheernam@est.tech Co-Authored-By: Brad Smith brad@comstyle.com Co-Authored-By: loqs 7595223+loqs@users.noreply.github.com Co-Authored-By: Finn R. Gärtner 65015656+FinnRG@users.noreply.github.com Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Apache Thrift

Introduction

Thrift is a lightweight, language-independent software stack for point-to-point RPC implementation. Thrift provides clean abstractions and implementations for data transport, data serialization, and application level processing. The code generation system takes a simple definition language as input and generates code across programming languages that uses the abstracted stack to build interoperable RPC clients and servers.

Apache Thrift Layered Architecture

Thrift makes it easy for programs written in different programming languages to share data and call remote procedures. With support for 28 programming languages, chances are Thrift supports the languages that you currently use.

Thrift is specifically designed to support non-atomic version changes across client and server code. This allows you to upgrade your server while still being able to service older clients; or have newer clients issue requests to older servers. An excellent community-provided write-up about thrift and compatibility when versioning an API can be found in the Thrift Missing Guide.

For more details on Thrift’s design and implementation, see the Thrift whitepaper included in this distribution, or at the README.md file in your particular subdirectory of interest.

Status

Branch	Travis	Appveyor	Coverity Scan	codecov.io	Website
`master`
`0.23.0`

Releases

Thrift does not maintain a specific release calendar at this time.

We strive to release twice yearly. Download the current release.

License

Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Project Hierarchy

thrift/

compiler/

Contains the Thrift compiler, implemented in C++.

lib/

Contains the Thrift software library implementation, subdivided by
language of implementation.

cpp/
go/
java/
php/
py/
rb/
...

test/

Contains sample Thrift files and test code across the target programming
languages.

tutorial/

Contains a basic tutorial that will teach you how to develop software
using Thrift.

Development

To build the same way Travis CI builds the project you should use docker. We have comprehensive building instructions for docker.

Requirements

See http://thrift.apache.org/docs/install for a list of build requirements (may be stale). Alternatively, see the docker build environments for a list of prerequisites.

Resources

More information about Thrift can be obtained on the Thrift webpage at:

 http://thrift.apache.org

Acknowledgments

Thrift was inspired by pillar, a lightweight RPC tool written by Adam D’Angelo, and also by Google’s protocol buffers.

Installation

If you are building from the first time out of the source repository, you will need to generate the configure scripts. (This is not necessary if you downloaded a tarball.) From the top directory, do:

./bootstrap.sh

Once the configure scripts are generated, thrift can be configured. From the top directory, do:

./configure

You may need to specify the location of the boost files explicitly. If you installed boost in /usr/local, you would run configure as follows:

./configure --with-boost=/usr/local

Note that by default the thrift C++ library is typically built with debugging symbols included. If you want to customize these options you should use the CXXFLAGS option in configure, as such:

./configure CXXFLAGS='-g -O2'
./configure CFLAGS='-g -O2'
./configure CPPFLAGS='-DDEBUG_MY_FEATURE'

To enable gcov required options -fprofile-arcs -ftest-coverage enable them:

./configure  --enable-coverage

Run ./configure –help to see other configuration options

Please be aware that the Python library will ignore the –prefix option and just install wherever Python’s distutils puts it (usually along the lines of /usr/lib/pythonX.Y/site-packages/). If you need to control where the Python modules are installed, set the PY_PREFIX variable. (DESTDIR is respected for Python and C++.)

Make thrift:

make

From the top directory, become superuser and do:

make install

Uninstall thrift:

make uninstall

Note that some language packages must be installed manually using build tools better suited to those languages (at the time of this writing, this applies to Java, Ruby, PHP).

Look for the README.md file in the lib// folder for more details on the installation of each language library package.

Package Managers

Apache Thrift is available via a number of package managers, a list which is is steadily growing. A more detailed overview can be found at the Apache Thrift web site under “Libraries” and/or in the respective READMEs for each language under /lib

Testing

There are a large number of client library tests that can all be run from the top-level directory.

make -k check

This will make all of the libraries (as necessary), and run through the unit tests defined in each of the client libraries. If a single language fails, the make check will continue on and provide a synopsis at the end.

To run the cross-language test suite, please run:

make cross

This will run a set of tests that use different language clients and servers.