[jira] [Commented] (KUDU-1738) Allow users of C++ client to disable initialization of OpenSSL

["Todd Lipcon (JIRA)" <ji...@apache.org>]

    [ 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)