[
https://issues.apache.org/jira/browse/KUDU-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848038#comment-15848038
]
Todd Lipcon commented on KUDU-1738:
-----------------------------------
bq. Impala might just end up completely depending on Kudu for TLS for now
(meaning we just set the correct TLS flags and expect KRPC's TLS to turn on).
But in the near future this will become more important.
Not sure I follow.. don't you have many consumers of OpenSSL within your
process?
- Squeasel (listening for HTTPS)
- External RPCs with Thrift (listening for HS2 connections with SSL - i believe
that's supported?)
- Internal RPCs (either Thrift or your copy of KRPC)
- Kudu client's usage of OpenSSL once we enable security
We need to make sure that between all of these, the OpenSSL mutex and threadid
callbacks are set exactly once. This JIRA is about making the Kudu part
configurable -- probably based on the same policy as the SASL code:
- add an API to the client to tell the kudu code not to try to enable SSL.
- when we first use SSL:
-- if disabled via the API, just try to verify that it's already set up like we
require. If not, give an error of some kind.
-- if not disabled via the API, try to auto-detect whether it's already set up.
If it is, warn that they should disable it via the API but keep going. If not,
initialize it ourselves without any warning.
(see sasl_common.cc's DoSaslInit function for reference)
> Allow users of C++ client to disable initialization of OpenSSL
> --------------------------------------------------------------
>
> Key: KUDU-1738
> URL: https://issues.apache.org/jira/browse/KUDU-1738
> Project: Kudu
> Issue Type: Bug
> Components: client, security
> Affects Versions: 1.1.0
> Reporter: Todd Lipcon
>
> As we start to use OpenSSL from within the client, we now take care of
> initializing the OpenSSL library. Programs which embed us may have already
> initialized OpenSSL for their own purposes. In that case, we don't want Kudu
> to run the initialization a second time.
> We should probably add some kind of option to KuduClientBuilder which
> disables the SSL initialization. Another thought is that we may want to
> detect if the SSL library has already been initialized and automatically
> skip. (it seems this is possible by calling SSL_CTX_new and checking the
> error code to see if it's not initialized yet)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
