[
https://issues.apache.org/jira/browse/DRILL-8370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17646196#comment-17646196
]
ASF GitHub Bot commented on DRILL-8370:
---------------------------------------
github-code-scanning[bot] commented on code in PR #2719:
URL: https://github.com/apache/drill/pull/2719#discussion_r1046056001
##########
contrib/storage-splunk/src/main/java/org/apache/drill/exec/store/splunk/SplunkConnection.java:
##########
@@ -152,4 +172,45 @@
public EntityCollection<Index> getIndexes() {
return service.getIndexes();
}
+
+ /**
+ * As of version 1.8, Splunk's SDK introduced a boolean parameter which
+ * is supposed to control whether the SDK will validate SSL certificates
+ * or not. Unfortunately the parameter does not actually seem to have
+ * any effect and the end result is that when making Splunk calls,
+ * Splunk will always attempt to verify the SSL certificates, even when
+ * the parameter is set to false. This method does what the parameter
+ * is supposed to do in the SDK and adds and all trusting SSL Socket
+ * Factory to the HTTP client in Splunk's SDK. In the event Splunk
+ * fixes this issue, we can remove this method.
+ *
+ * @return A {@link SSLSocketFactory} which trusts any SSL certificate,
+ * even ones from Splunk
+ * @throws KeyManagementException Thros
+ */
+ private SSLSocketFactory createAllTrustingSSLFactory() throws
KeyManagementException {
+ SSLContext context;
+ try {
+ context = SSLContext.getInstance("TLS");
+ } catch (NoSuchAlgorithmException e) {
+ throw UserException.validationError(e)
+ .message("Error establishing SSL connection: Invalid scheme: " +
e.getMessage())
+ .build(logger);
+ }
+ TrustManager[] trustAll = new TrustManager[]{
+ new X509TrustManager() {
+ public X509Certificate[] getAcceptedIssuers() {
+ return null;
+ }
+ public void checkClientTrusted(X509Certificate[] certs, String
authType) {
+ // No op
+ }
+ public void checkServerTrusted(X509Certificate[] certs, String
authType) {
+ // No op
+ }
+ }
+ };
+ context.init(null, trustAll, null);
Review Comment:
## `TrustManager` that accepts all certificates
This uses [TrustManager](1), which is defined in [SplunkConnection$](2) and
trusts any certificate.
[Show more
details](https://github.com/apache/drill/security/code-scanning/42)
> Upgrade splunk-sdk-java to 1.9.3
> --------------------------------
>
> Key: DRILL-8370
> URL: https://issues.apache.org/jira/browse/DRILL-8370
> Project: Apache Drill
> Issue Type: Improvement
> Components: Storage - Other
> Affects Versions: 1.20.2
> Reporter: James Turton
> Assignee: James Turton
> Priority: Minor
> Fix For: 1.20.3
>
>
> Changes in splunk-sdk-java since 1.9.1.
> {quote}
> h3. Minor Changes
> * Re-fetch logic for instancetype and version fields if not set within
> Service instance to avoid NPE (GitHub PR
> [#202|https://github.com/splunk/splunk-sdk-java/pull/202])
> * Check for local IP as alternative to _localhost_ within HostnameVerifier,
> addressing issue with certain local workflows
> * Added null check for child to handle error when no value is passed for a
> parameter in modular-inputs (Ref issue
> [#198|https://github.com/splunk/splunk-sdk-java/issues/198] & GitHub PR
> [#199|https://github.com/splunk/splunk-sdk-java/pull/199])
> h3. New Features and APIs
> {quote} *
> {quote}Added feature that allows to update ACL properties of an entity
> (GitHub PR [#196|https://github.com/splunk/splunk-sdk-java/pull/196]){quote}
>
> Also removes the execution order dependence in the Splunk unit tests created
> by their expecting a certain number of records in the _audit index. I believe
> this order dependence is behind recent, apparently random CI run failures in
> the Splunk unit tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
