[
https://issues.apache.org/jira/browse/KUDU-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074719#comment-17074719
]
Todd Lipcon commented on KUDU-3105:
-----------------------------------
I ran into this last night while using conda on el7 to get a rather new version
of python. The conda environment has openssl 1.1 in it, but my client was built
outside of conda and has openssl 1.0.x from el7.
My initial attempt to fix this was to change Kudu to use dlsym to look for the
OPENSSL_version_number() functoin and use that to determine runtime behavior.
However, I hit a different related issue:
- the python client code uses 'import _ssl' to force Python to do its own
OpenSSL initialization. In the conda environment, this linked against libssl.so
from conda's lib dircetory (openssl 1.1). So, the python side inits openssl 1.1.
- the python C++ so file has a link to libssl.so.10, with the explicit versoin
suffix in the file name, rather than just to 'libssl.so'. So, it still links to
libssl _outside_ the environment. So, it gets a not-initialized SSL and can't
make an SSL context.
Not sure the right fix here.. .seems like we could either get the kuduclient.so
to link against libssl.so instead of libssl.so.10, or we could be a little more
"fast and loose" about trying to auto-detect whether SSL is initialized.
> kudu_client based application reports 'Locking callback not initialized' error
> ------------------------------------------------------------------------------
>
> Key: KUDU-3105
> URL: https://issues.apache.org/jira/browse/KUDU-3105
> Project: Kudu
> Issue Type: Bug
> Components: client, python, security
> Affects Versions: 1.9.0, 1.10.0, 1.10.1, 1.11.0, 1.11.1
> Reporter: Alexey Serbin
> Priority: Major
>
> When using kudu_client library compiled against OpenSSL 1.0.x with OpenSSL
> 1.1.x run-time, Kudu client applications might report 'Runtime error: Locking
> callback not initialized' error.
> For example, {{kudu-python}} based applications on RHEL/CentOS 7.7, if using
> {{kudu-client}} of versions 1.9, 1.10, 1.11 in Python environment with
> OpenSSL 1.1.1d might report an error like below:
> {noformat}
> Traceback (most recent call last):
> File "kudu-python-app.py", line 22, in <module>
> client = kudu.connect(host=args.masters, port=args.ports)
> File "/opt/lib/python3.6/site-packages/kudu/__init__.py", line 96, in
> connect
> rpc_timeout_ms=rpc_timeout_ms)
> File "kudu/client.pyx", line 297, in kudu.client.Client.__cinit__
> File "kudu/errors.pyx", line 62, in kudu.errors.check_status
> kudu.errors.KuduBadStatus: b'Runtime error: Locking callback not initialized'
> {noformat}
> The issue is that the code {{libkudu_client}} compiled against OpenSSL 1.0.x
> uses initialization code path specific for OpenSSL 1.0.x version, and the
> post-condition requires presence of thread-safe callbacks installed after the
> initialization is done. However, those functions do not install the expected
> locking callbacks in OpenSSL 1.1.x since OpenSSL uses different approach
> w.r.t. locking callbacks since 1.1.0 version: the callbacks are not required
> since the multi-threading model was revamped in the newer versions of the
> library.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
