[jira] [Commented] (KUDU-1738) Allow users of C++ client to disable initialization of OpenSSL
[ https://issues.apache.org/jira/browse/KUDU-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15848859#comment-15848859 ] Sailesh Mukil commented on KUDU-1738: - [~tlipcon] Ah yes, my bad. That makes it more clear. I was just thinking about internal and external RPCs. This is a necessity even now then. > 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 >Priority: Blocker > > 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)
[jira] [Commented] (KUDU-1738) Allow users of C++ client to disable initialization of OpenSSL
[ https://issues.apache.org/jira/browse/KUDU-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15848797#comment-15848797 ] Henry Robinson commented on KUDU-1738: -- Todd's right - there are many different clients of OpenSSL in Impala, and there's no likelihood of that number decreasing in the medium term. > 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 >Priority: Blocker > > 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)
[jira] [Commented] (KUDU-1738) Allow users of C++ client to disable initialization of OpenSSL
[ https://issues.apache.org/jira/browse/KUDU-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (KUDU-1738) Allow users of C++ client to disable initialization of OpenSSL
[ https://issues.apache.org/jira/browse/KUDU-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840638#comment-15840638 ] Matthew Jacobs commented on KUDU-1738: -- Agreed > 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.4#6332)
[jira] [Commented] (KUDU-1738) Allow users of C++ client to disable initialization of OpenSSL
[ https://issues.apache.org/jira/browse/KUDU-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840547#comment-15840547 ] Todd Lipcon commented on KUDU-1738: --- I think the global one like you suggested is what we were going for. I believe we are already initializing OpenSSL in our client, but it may be that we only do so lazily if connecting to a TLS-enabled Kudu cluster... so either this is already biting us (but is a rare race that isn't likely to happen) or it's going to bite us soon when we start connecting to kudu with TLS. I'd say either way we should go ahead and do it, because we know it's a good idea. > 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.4#6332)
[jira] [Commented] (KUDU-1738) Allow users of C++ client to disable initialization of OpenSSL
[ https://issues.apache.org/jira/browse/KUDU-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840430#comment-15840430 ] Matthew Jacobs commented on KUDU-1738: -- [~tlipcon] is this something we can just test right now or are we still waiting for more client changes to land? > 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.4#6332)
[jira] [Commented] (KUDU-1738) Allow users of C++ client to disable initialization of OpenSSL
[ https://issues.apache.org/jira/browse/KUDU-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840351#comment-15840351 ] Todd Lipcon commented on KUDU-1738: --- [~sailesh] this seems necessary for Impala/Kudu integration to not break, right? > 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.4#6332)
[jira] [Commented] (KUDU-1738) Allow users of C++ client to disable initialization of OpenSSL
[ https://issues.apache.org/jira/browse/KUDU-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15630837#comment-15630837 ] Todd Lipcon commented on KUDU-1738: --- [~sailesh] what do you think about this? I'm nervous that the OpenSSL initialization done by Impala may race with the OpenSSL initialization done within our client. > 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: 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.4#6332)
