The spring-data-opensearch from opensearch-project

[FEATURE] knn_vector field type is not supported

The org.springframework.data.elasticsearch.annotations.Field has only dense_vector but not knn_vector. It looks we cannot annotate a field as knn_vector on the model through spring-data-opensearch libs.

Manual approval required for workflow run 4448786843: Release spring-data-opensearch version=1.0.1

Please approve or deny the release of spring-data-opensearch TAG: 1.0.1 COMMIT: ec8e589 VERSION : version=1.0.1

Workflow is pending manual review.
URL: https://github.com/opensearch-project/spring-data-opensearch/actions/runs/4448786843

Required approvers: [dblock dlvenable]

Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

[FEATURE]

Is your feature request related to a problem?

I was trying to turn off the sniffer functionality but found it impossible.
I was trying to extend the configuration or import only those I wanted but for some reason OpenSearchRestClientConfigurations is not public which make it difficult/impossible to extend or even import if you want to use only some of the configurations.

What solution would you like?

please make this classes public so that it would be easy to extend.

What alternatives have you considered?

Maybe make the auto configuration more configurable but even then I'd think that this class should be public.

[FEATURE] Support Search (Query) templates

Is your feature request related to a problem?

I would like to use the org.springframework.data.elasticsearch.core.query.SearchTemplateQuery but I get this error when I try to use it:

java.lang.IllegalArgumentException: unhandled Query implementation org.springframework.data.elasticsearch.core.query.SearchTemplateQuery
	at org.opensearch.data.client.orhlc.RequestFactory.getQuery(RequestFactory.java:1174) ~[spring-data-opensearch-1.2.0.jar:na]
	at org.opensearch.data.client.orhlc.RequestFactory.searchRequest(RequestFactory.java:752) ~[spring-data-opensearch-1.2.0.jar:na]
	at org.opensearch.data.client.orhlc.OpenSearchRestTemplate.search(OpenSearchRestTemplate.java:375) ~[spring-data-opensearch-1.2.0.jar:na]
	at org.springframework.data.elasticsearch.core.AbstractElasticsearchTemplate.search(AbstractElasticsearchTemplate.java:492) ~[spring-data-elasticsearch-5.1.2.jar:5.1.2]

What solution would you like?

Support org.springframework.data.elasticsearch.core.query.SearchTemplateQuery in

spring-data-opensearch/spring-data-opensearch/src/main/java/org/opensearch/data/client/orhlc/RequestFactory.java

Line 1174 in b671763

"unhandled Query implementation " + query.getClass().getName());

Do you have any additional context?

Search Templates are way to move the query logic to OpenSearch and make the code cleaner in the microservice side. Moreover this queries are more efficient since they are precompiled.

Example of use of query templates can be seen here: https://github.com/spring-projects/spring-data-elasticsearch/blob/main/src/main/antora/modules/ROOT/pages/elasticsearch/misc.adoc

public class PersonCustomRepositoryImpl implements PersonCustomRepository {

  private final ElasticsearchOperations operations;

  public PersonCustomRepositoryImpl(ElasticsearchOperations operations) {
    this.operations = operations;
  }

  @Override
  public SearchPage<Person> findByFirstNameWithSearchTemplate(String firstName, Pageable pageable) {

    var query = SearchTemplateQuery.builder()                               (1)
      .withId("person-firstname")                                           (2)
      .withParams(
        Map.of(                                                             (3)
          "firstName", firstName,
          "from", pageable.getOffset(),
          "size", pageable.getPageSize()
          )
      )
      .build();

    SearchHits<Person> searchHits = operations.search(query, Person.class); (4)

    return SearchHitSupport.searchPageFor(searchHits, pageable);
  }
}

hoverfly-java-junit5-0.15.0.jar: 3 vulnerabilities (highest severity is: 7.5)

Vulnerable Library - hoverfly-java-junit5-0.15.0.jar

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.squareup.okio/okio/2.8.0/49b64e09d81c0cc84b267edd0c2fd7df5a64c78c/okio-jvm-2.8.0.jar

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Vulnerabilities

CVE	Severity	CVSS	Dependency	Type	Fixed in (hoverfly-java-junit5 version)	Remediation Possible**
CVE-2023-3635	High	7.5	okio-2.8.0.jar	Transitive	N/A*	❌
CVE-2022-24329	Medium	5.3	kotlin-stdlib-1.4.10.jar	Transitive	N/A*	❌
CVE-2020-29582	Medium	5.3	kotlin-stdlib-1.4.10.jar	Transitive	N/A*	❌

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2023-3635

Vulnerable Library - okio-2.8.0.jar

A modern I/O API for Java

Library home page: https://github.com/square/okio/

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.squareup.okio/okio/2.8.0/49b64e09d81c0cc84b267edd0c2fd7df5a64c78c/okio-jvm-2.8.0.jar

Dependency Hierarchy:

hoverfly-java-junit5-0.15.0.jar (Root Library)
- hoverfly-java-0.15.0.jar
  - okhttp-4.9.3.jar
    - ❌ okio-2.8.0.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

GzipSource does not handle an exception that might be raised when parsing a malformed gzip buffer. This may lead to denial of service of the Okio client when handling a crafted GZIP archive, by using the GzipSource class.

Publish Date: 2023-07-12

URL: CVE-2023-3635

CVSS 3 Score Details (7.5)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://www.cve.org/CVERecord?id=CVE-2023-3635

Release Date: 2023-07-12

Fix Resolution: com.squareup.okio:okio-jvm:3.4.0

CVE-2022-24329

Vulnerable Library - kotlin-stdlib-1.4.10.jar

Kotlin Standard Library for JVM

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.4.10/ea29e063d2bbe695be13e9d044dcfb0c7add398e/kotlin-stdlib-1.4.10.jar

Dependency Hierarchy:

hoverfly-java-junit5-0.15.0.jar (Root Library)
- hoverfly-java-0.15.0.jar
  - okhttp-4.9.3.jar
    - ❌ kotlin-stdlib-1.4.10.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

In JetBrains Kotlin before 1.6.0, it was not possible to lock dependencies for Multiplatform Gradle Projects.

Publish Date: 2022-02-25

URL: CVE-2022-24329

CVSS 3 Score Details (5.3)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: Low
- Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-2qp4-g3q3-f92w

Release Date: 2022-02-25

Fix Resolution: org.jetbrains.kotlin:kotlin-stdlib:1.6.0

CVE-2020-29582

Vulnerable Library - kotlin-stdlib-1.4.10.jar

Kotlin Standard Library for JVM

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.4.10/ea29e063d2bbe695be13e9d044dcfb0c7add398e/kotlin-stdlib-1.4.10.jar

Dependency Hierarchy:

hoverfly-java-junit5-0.15.0.jar (Root Library)
- hoverfly-java-0.15.0.jar
  - okhttp-4.9.3.jar
    - ❌ kotlin-stdlib-1.4.10.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

In JetBrains Kotlin before 1.4.21, a vulnerable Java API was used for temporary file and folder creation. An attacker was able to read data from such files and list directories due to insecure permissions.

Publish Date: 2021-02-03

URL: CVE-2020-29582

CVSS 3 Score Details (5.3)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: None
- Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-cqj8-47ch-rvvq

Release Date: 2021-02-03

Fix Resolution: org.jetbrains.kotlin:kotlin-stdlib:1.4.21

[PROPOSAL] Add examples for using spring-data-opensearch w/o Spring Boot

What/Why

What are you proposing?

It would be great to have quick starter examples for showcasing usage spring-data-opensearch w/o Spring Boot.

What problems are you trying to solve?

The reasoning behind it to help people get started as quickly as possible.

What is the developer experience going to be?

The examples should serve as sufficient starting point to integrate spring-data-opensearch into application and service w/o Spring Boot.

Are there any security considerations?

N/A

Are there any breaking changes to the API

N/A

What is the user experience going to be?

N/A

Are there breaking changes to the User Experience?

N/A

Manual approval required for workflow run 4938915225: Release spring-data-opensearch version=1.1.0

Please approve or deny the release of spring-data-opensearch TAG: 1.1.0 COMMIT: 56c4803 VERSION : version=1.1.0

Workflow is pending manual review.
URL: https://github.com/opensearch-project/spring-data-opensearch/actions/runs/4938915225

Required approvers: [dblock dlvenable]

Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

[PROPOSAL] Add support for spring-boot 2.7

What/Why

What are you proposing?

spring-data-opensearch should also add support for spring-boot 2.7. As per the README now spring-boot is compatible only with 3.0 and above.

What problems are you trying to solve?

Upgrading to spring-boot 3.0 has to go through 2.7 as mentioned here. So adding support for spring-boot 2.7 also in spring-data-opensearch will cause earlier adoption.

[BUG] CodeQL build failed

What is the bug?

CodeQL failed in https://github.com/opensearch-project/spring-data-opensearch/actions/runs/3220279221/jobs/5266779787

[PROPOSAL] provide spring AutoConfiguration support

What/Why

What are you proposing?

Provide an AutoConfiguration for spring opensearch library like it is done for elastisearch

What problems are you trying to solve?

Currently the RestClient has to be build from every user and every user has to define its own properties.
This can unified and simplified with this configuration.

What is the developer experience going to be?

This should ease the start of other spring developers with this library.

Are there any security considerations?

No, even if done correctly some basic security configurations can be made here.

[FEATURE] Add @DataOpenSearchTest to support wiring up OpenSearch configurations in tests

Is your feature request related to a problem?

Came out of #64, we could not make @DataElasticsearchTest to work seamlessly with OpenSearch (the changes have to be done in Spring Boot and had been rejected previously).

What solution would you like?

Introduce @DataOpenSearchTest annotation to simplify wiring up wiring up OpenSearch configurations in tests

What alternatives have you considered?

Keep adding annotations manually

Do you have any additional context?

See please #64

[BUG] Nodesniffer doesn't use my configuration

What is the bug?

The Sniffer seems to use a different client than the one that I defined in my bean.
The Sniffer now fails with the error because it doesn't use the HttpRequestInterceptor I defined (see code below)

2023-02-13T16:04:57.755+01:00 ERROR 47226 --- [nt_sniffer[T#1]] org.opensearch.client.sniff.Sniffer      : error while sniffing nodes

org.opensearch.client.ResponseException: method [GET], host [https://xxx.amazonaws.com], URI [/_nodes/http?timeout=1000ms], status line [HTTP/1.1 403 Forbidden]
{"Message":"User: anonymous is not authorized to perform: es:ESHttpGet because no resource-based policy allows the es:ESHttpGet action"}

But queries with the OpenSearchRestTemplate are working

How can one reproduce the bug?

create a RestHighLevelClient Bean with an Aws4Signer and an HttpRequestInteceptor

What is the expected behavior?

The Sniffer should work when the client works

Do you have any additional context?

My configuraiton:

@Configuration
@RequiredArgsConstructor
public class OpenSearchConfig extends AbstractOpenSearchConfiguration {

    private static final String SERVICE_NAME = "es";

    @Value("${opensearch.uris}")
    private String endpoint;

    @Value("${aws.region}")
    private String region;

    private final AwsCredentialsProvider credentialsProvider;

    @Override
    @Bean
    public RestHighLevelClient opensearchClient() {
        Aws4Signer signer = Aws4Signer.create();
        HttpRequestInterceptor interceptor = new AwsRequestSigningApacheInterceptor(SERVICE_NAME, signer,
                credentialsProvider, region);

        RestClientBuilder restClientBuilder = RestClient.builder(HttpHost.create(endpoint))
                .setHttpClientConfigCallback(hacb -> hacb.addInterceptorLast(interceptor));

        return new RestHighLevelClient(restClientBuilder);
    }

    @Bean
    public OpenSearchRestTemplate openSearchRestTemplate(RestHighLevelClient client) {
        return new OpenSearchRestTemplate(client);
    }
}

Maven dependency:

        <dependency>
            <groupId>org.opensearch.client</groupId>
            <artifactId>spring-data-opensearch-starter</artifactId>
            <version>1.0.0</version>
        </dependency>

wiremock-jre8-2.35.1.jar: 7 vulnerabilities (highest severity is: 10.0) - autoclosed

Vulnerable Library - wiremock-jre8-2.35.1.jar

A web service test double for all occasions

Library home page: http://wiremock.org

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.github.tomakehurst/wiremock-jre8/2.35.1/d113bd22219a3c8670d7d190dd7d454a8ec603b0/wiremock-jre8-2.35.1.jar

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Vulnerabilities

CVE	Severity	CVSS	Dependency	Type	Fixed in (wiremock-jre8 version)	Remediation Possible**
CVE-2023-39967	Critical	10.0	wiremock-jre8-2.35.1.jar	Direct	N/A	❌
CVE-2023-1370	High	7.5	detected in multiple dependencies	Transitive	N/A*	❌
CVE-2023-24998	High	7.5	commons-fileupload-1.4.jar	Transitive	N/A*	❌
CVE-2023-2976	High	7.1	guava-31.1-jre.jar	Transitive	N/A*	❌
CVE-2023-26049	Medium	5.3	detected in multiple dependencies	Transitive	N/A*	❌
CVE-2023-26048	Medium	5.3	jetty-server-9.4.49.v20220914.jar	Transitive	N/A*	❌
WS-2023-0236	Low	3.9	jetty-xml-9.4.49.v20220914.jar	Transitive	N/A*	❌

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2023-39967

Vulnerable Library - wiremock-jre8-2.35.1.jar

A web service test double for all occasions

Library home page: http://wiremock.org

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.github.tomakehurst/wiremock-jre8/2.35.1/d113bd22219a3c8670d7d190dd7d454a8ec603b0/wiremock-jre8-2.35.1.jar

Dependency Hierarchy:

❌ wiremock-jre8-2.35.1.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

WireMock is a tool for mocking HTTP services. When certain request URLs like “@127.0.0.1:1234" are used in WireMock Studio configuration fields, the request might be forwarded to an arbitrary service reachable from WireMock’s instance. There are 3 identified potential attack vectors: via “TestRequester” functionality, webhooks and the proxy mode. As we can control HTTP Method, HTTP Headers, HTTP Data, it allows sending requests with the default level of credentials for the WireMock instance. The vendor has discontinued the affected Wiremock studio product and there will be no fix. Users are advised to find alternatives.

Publish Date: 2023-09-06

URL: CVE-2023-39967

CVSS 3 Score Details (10.0)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Changed
Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- Availability Impact: High

For more information on CVSS3 Scores, click here.

CVE-2023-1370

Vulnerable Libraries - json-smart-2.4.8.jar, json-smart-2.4.7.jar

json-smart-2.4.8.jar

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

Library home page: https://urielch.github.io/

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/net.minidev/json-smart/2.4.8/7c62f5f72ab05eb54d40e2abf0360a2fe9ea477f/json-smart-2.4.8.jar

Dependency Hierarchy:

wiremock-jre8-2.35.1.jar (Root Library)
- ❌ json-smart-2.4.8.jar (Vulnerable Library)

json-smart-2.4.7.jar

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

Library home page: https://urielch.github.io/

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/net.minidev/json-smart/2.4.7/8d7f4c1530c07c54930935f3da85f48b83b3c109/json-smart-2.4.7.jar

Dependency Hierarchy:

wiremock-jre8-2.35.1.jar (Root Library)
- json-path-2.7.0.jar
  - ❌ json-smart-2.4.7.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Json-smart is a performance focused, JSON processor lib. When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the code does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause a stack exhaustion (stack overflow) and crash the software.

Publish Date: 2023-03-22

URL: CVE-2023-1370

CVSS 3 Score Details (7.5)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://research.jfrog.com/vulnerabilities/stack-exhaustion-in-json-smart-leads-to-denial-of-service-when-parsing-malformed-json-xray-427633/

Release Date: 2023-03-22

Fix Resolution: net.minidev:json-smart:2.4.9

CVE-2023-24998

Vulnerable Library - commons-fileupload-1.4.jar

The Apache Commons FileUpload component provides a simple yet flexible means of adding support for multipart file upload functionality to servlets and web applications.

Library home page: http://commons.apache.org/proper/commons-fileupload/

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/commons-fileupload/commons-fileupload/1.4/f95188e3d372e20e7328706c37ef366e5d7859b0/commons-fileupload-1.4.jar

Dependency Hierarchy:

wiremock-jre8-2.35.1.jar (Root Library)
- ❌ commons-fileupload-1.4.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads.

Note that, like all of the file upload limits, the
new configuration option (FileUploadBase#setFileCountMax) is not
enabled by default and must be explicitly configured.

Publish Date: 2023-02-20

URL: CVE-2023-24998

CVSS 3 Score Details (7.5)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://tomcat.apache.org/security-10.html

Release Date: 2023-02-20

Fix Resolution: commons-fileupload:commons-fileupload:1.5;org.apache.tomcat:tomcat-coyote:8.5.85,9.0.71,10.1.5,11.0.0-M3;org.apache.tomcat.embed:tomcat-embed-core:8.5.85,9.0.71,10.1.5,11.0.0-M3;org.apache.tomcat:tomcat-util:8.5.85,9.0.71,10.1.5,11.0.0-M3;org.apache.tomcat:tomcat-catalina:8.5.85,9.0.71,10.1.5,11.0.0-M3

CVE-2023-2976

Vulnerable Library - guava-31.1-jre.jar

Guava is a suite of core and expanded libraries that include utility classes, Google's collections, I/O classes, and much more.

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.google.guava/guava/31.1-jre/60458f877d055d0c9114d9e1a2efb737b4bc282c/guava-31.1-jre.jar

Dependency Hierarchy:

wiremock-jre8-2.35.1.jar (Root Library)
- ❌ guava-31.1-jre.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Use of Java's default temporary directory for file creation in FileBackedOutputStream in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.

Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.

Mend Note: Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.

Publish Date: 2023-06-14

URL: CVE-2023-2976

CVSS 3 Score Details (7.1)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Local
- Attack Complexity: Low
- Privileges Required: Low
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-7g45-4rm6-3mm3

Release Date: 2023-06-14

Fix Resolution: com.google.guava:guava:32.0.1-android,32.0.1-jre

CVE-2023-26049

Vulnerable Libraries - jetty-http-9.4.49.v20220914.jar, jetty-server-9.4.49.v20220914.jar

jetty-http-9.4.49.v20220914.jar

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-http/9.4.49.v20220914/ef1e3bde212115eb4bb0740aaf79029b624d4e30/jetty-http-9.4.49.v20220914.jar

Dependency Hierarchy:

wiremock-jre8-2.35.1.jar (Root Library)
- jetty-servlets-9.4.49.v20220914.jar
  - ❌ jetty-http-9.4.49.v20220914.jar (Vulnerable Library)

jetty-server-9.4.49.v20220914.jar

The core jetty server artifact.

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.4.49.v20220914/502f99eed028139e71a4afebefa291ace12b9c1c/jetty-server-9.4.49.v20220914.jar

Dependency Hierarchy:

wiremock-jre8-2.35.1.jar (Root Library)
- ❌ jetty-server-9.4.49.v20220914.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with " (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d" will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.

Publish Date: 2023-04-18

URL: CVE-2023-26049

CVSS 3 Score Details (5.3)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: None
- Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-p26g-97m4-6q7c

Release Date: 2023-04-18

Fix Resolution: org.eclipse.jetty:jetty-http:9.4.51.v20230217,10.0.14,11.0.14, org.eclipse.jetty:jetty-runner:9.4.51.v20230217,10.0.14,11.0.14, org.eclipse.jetty:jetty-server:9.4.51.v20230217,10.0.14,11.0.14

CVE-2023-26048

Vulnerable Library - jetty-server-9.4.49.v20220914.jar

The core jetty server artifact.

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.4.49.v20220914/502f99eed028139e71a4afebefa291ace12b9c1c/jetty-server-9.4.49.v20220914.jar

Dependency Hierarchy:

wiremock-jre8-2.35.1.jar (Root Library)
- ❌ jetty-server-9.4.49.v20220914.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with @MultipartConfig) that call HttpServletRequest.getParameter() or HttpServletRequest.getParts() may cause OutOfMemoryError when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of fileSizeThreshold=0 which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw OutOfMemoryError. However, the server may be able to recover after the OutOfMemoryError and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter maxRequestSize which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).

Publish Date: 2023-04-18

URL: CVE-2023-26048

CVSS 3 Score Details (5.3)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-qw69-rqj8-6qw8

Release Date: 2023-04-18

Fix Resolution: org.eclipse.jetty:jetty-server:9.4.51.v20230217,10.0.14,11.0.14;org.eclipse.jetty:jetty-runner:9.4.51.v20230217,10.0.14,11.0.14

WS-2023-0236

Vulnerable Library - jetty-xml-9.4.49.v20220914.jar

The jetty xml utilities.

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-xml/9.4.49.v20220914/34e602eae6dd2fe54a00ec77fc98c5e77737906b/jetty-xml-9.4.49.v20220914.jar

Dependency Hierarchy:

wiremock-jre8-2.35.1.jar (Root Library)
- jetty-bom-9.4.49.v20220914.pom
  - ❌ jetty-xml-9.4.49.v20220914.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

XmlParser is vulnerable to XML external entity (XXE) vulnerability.
XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit this vulnerability in order to achieve SSRF or cause a denial of service. One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the WAR includes a malicious web.xml. The vulnerability is patched in versions 10.0.16, 11.0.16, and 12.0.0.

Publish Date: 2023-07-10

URL: WS-2023-0236

CVSS 3 Score Details (3.9)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Local
- Attack Complexity: High
- Privileges Required: High
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-58qw-p7qm-5rvh

Release Date: 2023-07-10

Fix Resolution: org.eclipse.jetty:jetty-xml:10.0.16,11.0.16,12.0.0

[FEATURE] Migrate from Apache Maven to Gradle

Is your feature request related to a problem?

The project currently is using Apache Maven as a build tool (due to the fact that the original project https://github.com/spring-projects/spring-data-elasticsearch is also based on Apache Maven), but the OpenSearch project porfolio is using Gradle.

What solution would you like?

Migrate from Apache Maven to Gradle as a build tool

What alternatives have you considered?

Keep Apache Maven

Do you have any additional context?

N/A

[FEATURE] migration guide from spring-data-elasticsearch to spring-data-opensearch

Is your feature request related to a problem?

all users were so far stuck on spring-data-elasticsearch (incompatible with OpenSearch 2.x) and will now want to switch to spring-data-opensearch (once available).

What solution would you like?

please provide a clear step-by-step migration guide on how to migrate an existing project from spring-data-elasticsearch to spring-data-opensearch.
if it is supported (cf. also #12) also mention how a project can support both Elasticsearch and OpenSearch in parallel (only ES 7.10.2 & older; maybe even all 7.x and maybe there's even a way for a project to support OpenSearch & ES 8.x in parallel, e.g. by picking the library at runtime?)

What alternatives have you considered?

everyone can figure it out on their own, leading to greater variation in how it's implemented and lots of questions around it.

Do you have any additional context?

n/a

[FEATURE] Support for Opensearch PointInTime

Is your feature request related to a problem?

The latest release branch of Opensearch (2.4.x) introduced support for point-in-time search.

What solution would you like?

Implement the point in time API to be in line with the latest features provided by Opensearch

What alternatives have you considered?

Only support the Scroll API

Do you have any additional context?

None

spring-boot-starter-web-3.1.1.jar: 1 vulnerabilities (highest severity is: 6.1)

Vulnerable Library - spring-boot-starter-web-3.1.1.jar

Path to dependency file: /spring-data-opensearch-examples/spring-boot-gradle/build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-core/10.1.10/7423236b34aa78d6f36592b2aa294d7c8469f219/tomcat-embed-core-10.1.10.jar

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Vulnerabilities

CVE	Severity	CVSS	Dependency	Type	Fixed in (spring-boot-starter-web version)	Remediation Possible**
CVE-2023-41080	Medium	6.1	tomcat-embed-core-10.1.10.jar	Transitive	3.1.4	✅

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2023-41080

Vulnerable Library - tomcat-embed-core-10.1.10.jar

Core Tomcat implementation

Library home page: https://tomcat.apache.org/

Path to dependency file: /spring-data-opensearch-examples/spring-boot-gradle/build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-core/10.1.10/7423236b34aa78d6f36592b2aa294d7c8469f219/tomcat-embed-core-10.1.10.jar

Dependency Hierarchy:

spring-boot-starter-web-3.1.1.jar (Root Library)
- spring-boot-starter-tomcat-3.1.1.jar
  - ❌ tomcat-embed-core-10.1.10.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in FORM authentication feature Apache Tomcat.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.0.12, from 9.0.0-M1 through 9.0.79 and from 8.5.0 through 8.5.92.

The vulnerability is limited to the ROOT (default) web application.

Publish Date: 2023-08-25

URL: CVE-2023-41080

CVSS 3 Score Details (6.1)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Changed
Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://lists.apache.org/thread/71wvwprtx2j2m54fovq9zr7gbm2wow2f

Release Date: 2023-08-25

Fix Resolution (org.apache.tomcat.embed:tomcat-embed-core): 10.1.13

Direct dependency fix Resolution (org.springframework.boot:spring-boot-starter-web): 3.1.4

⛑️ Automatic Remediation will be attempted for this issue.

⛑️Automatic Remediation will be attempted for this issue.

[PROPOSAL] Restart version from 0.1.0

What/Why

What are you proposing?

Coming from #1 (comment), restart version from 0.1.0.

What users have asked for this feature?

In #1 we started version at 5.x to continue the spring-data-elasticsearch release train. I'd prefer it if we started with semver with possibly 0.1.0 until we get a stable 1.0. This is because upstream dependencies are different (Elasticsearch vs. OpenSearch) and we will need to be potentially breaking backwards compatibility separately, thus will want to major version increment independently from spring-data-elasticsearch.

What problems are you trying to solve?

Independent semver for spring-data-opensearch.

Manual approval required for workflow run 4929560104: Release spring-data-opensearch version=1.1.0

Please approve or deny the release of spring-data-opensearch TAG: 1.1.0 COMMIT: 56c4803 VERSION : version=1.1.0

Workflow is pending manual review.
URL: https://github.com/opensearch-project/spring-data-opensearch/actions/runs/4929560104

Required approvers: [dblock dlvenable]

Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

[FEATURE] Reactive Client for OpenSearch

Hi OpenSearch Team,

I see that Reactive classes from Spring Data Elasticsearch are missing, like DefaultReactiveElasticsearchClient:
https://github.com/spring-projects/spring-data-elasticsearch/tree/main/src/main/java/org/springframework/data/elasticsearch/client/erhlc

https://github.com/opensearch-project/spring-data-opensearch/tree/main/spring-data-opensearch/src/main/java/org/opensearch/data/client/orhlc

How can I use Spring WebFlux with OpenSearch?

Thanks.

[FEATURE] Clarify README.md compatibility matrix

Is your feature request related to a problem?

The README.md does not explain whether it is possible or how to connect with Amazon Managed Service or Serverless. This may not work today.

What solution would you like?

Modify the README to clarify whether the client can connect to Amazon Managed Service or Serverless. If it is not possible, open another issue to track that work.

Do you have any additional context?

Connection to those services works in the opensearch-java client. This issue proposes swapping out the high-level rest client for the opensearch-java client: #19

Manual approval required for workflow run 5381789898: Release spring-data-opensearch version=1.2.0

Please approve or deny the release of spring-data-opensearch TAG: v1.2.0 COMMIT: 425d179 VERSION : version=1.2.0

Workflow is pending manual review.
URL: https://github.com/opensearch-project/spring-data-opensearch/actions/runs/5381789898

Required approvers: [dblock dlvenable]

Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

[FEATURE] Support synonyms in seperate txt-file

Is your feature request related to a problem?

I need to add a filter to my settings with a long list of synonyms. Ideally, I would like to store this in a separate synonyms.txt file, and reference it like this:

"synonym_filter": { "type": "synonym", "synonyms_path": "synonyms.txt" }

But then I get this error:
{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"IOException while reading synonyms_path_path: /usr/share/opensearch/config/synonyms.txt"}],"type":"illegal_argument_exception","reason":"IOException while reading synonyms_path_path: /usr/share/opensearch/config/synonyms.txt","caused_by":{"type":"no_such_file_exception","reason":"/usr/share/opensearch/config/synonyms.txt"}},"status":400}

What solution would you like?

Look for the referenced synonyms.txt file in my resources folder, and not in /usr/share/opensearch/config.

What alternatives have you considered?

The alternative is to have the list of synonyms directly in the filter definition, but this will bloat my settings.json substantially.

[FEATURE] Add integration tests across the compatibility matrix

Is your feature request related to a problem?

We document the following compatibility matrix, https://github.com/opensearch-project/spring-data-opensearch#compatibility-matrix. But does it really work?

What solution would you like?

Add integration tests that boot OpenSearch containers and test this project against it.

[PROPOSAL] Build with Gradle

What/Why

What are you proposing?

Use a Gradle build for this project.

What users have asked for this feature?

As a developer in the OpenSearch project, I'm familiar with Gradle builds.

What problems are you trying to solve?

Make it easier for developers from OpenSearch to start contributing.

Alteratives

Include a Maven Wrapper
Remove the Spring parent POM since this is an OpenSearch project, not a Spring project.

[QUESTION] Any available release?

I wonder if is there any release / snapshot that can be testes?
I checked here but did not find anything https://aws.oss.sonatype.org/content/repositories/snapshots/org/opensearch/client/

[BUG] Cannot use this

What is the bug?

Import fails:

implementation("org.opensearch:spring-data-opensearch-starter")

How can one reproduce the bug?

create kotlin-gradle project and add:

implementation("org.opensearch:spring-data-opensearch-starter")

But i get same issue with pom

What is the expected behavior?

A clear and concise description of what you expected to happen.

What is your host/environment?

Operating system, version.

Do you have any screenshots?

If applicable, add screenshots to help explain your problem.

Do you have any additional context?

Add any other context about the problem.

[PROPOSAL] Publish -SNAPSHOT builds to Maven

What/Why

What are you proposing?

Publish -SNAPSHOTs to maven.

What users have asked for this feature?

Everyone who wants to test drive daily builds.

Manual approval required for workflow run 4938915225: Release spring-data-opensearch version=1.1.0

Please approve or deny the release of spring-data-opensearch TAG: 1.1.0 COMMIT: 56c4803 VERSION : version=1.1.0

Workflow is pending manual review.
URL: https://github.com/opensearch-project/spring-data-opensearch/actions/runs/4938915225

Required approvers: [dblock dlvenable]

Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

[BUG] Not support SpringBoot version 2.7.X

What is the bug?

Got the following errors in SpringBoot startup when using it with SpringBoot 2.7.X

2023-01-30 10:28:10.782 INFO 30405 --- [ main] c.e.o.OpenSearchClientPocApplication : No active profile set, falling back to 1 default profile: "default"
2023-01-30 10:28:11.240 INFO 30405 --- [ main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data Elasticsearch repositories in DEFAULT mode.
2023-01-30 10:28:11.329 ERROR 30405 --- [ main] o.s.b.d.LoggingFailureAnalysisReporter :

APPLICATION FAILED TO START

Description:

An attempt was made to call a method that does not exist. The attempt was made from the following location:

org.springframework.data.elasticsearch.repository.config.ElasticsearchRepositoryConfigExtension.getModulePrefix(ElasticsearchRepositoryConfigExtension.java:64)

The following method did not exist:

'java.lang.String org.springframework.data.elasticsearch.repository.config.ElasticsearchRepositoryConfigExtension.getModuleIdentifier()'

The calling method's class, org.springframework.data.elasticsearch.repository.config.ElasticsearchRepositoryConfigExtension, was loaded from the following location:

jar:file:/Users/kewei/.gradle/caches/modules-2/files-2.1/org.springframework.data/spring-data-elasticsearch/5.0.0/86f7d0d3ac9be7d3dfef1b37a0850852c8c1d9e8/spring-data-elasticsearch-5.0.0.jar!/org/springframework/data/elasticsearch/repository/config/ElasticsearchRepositoryConfigExtension.class

The called method's class, org.springframework.data.elasticsearch.repository.config.ElasticsearchRepositoryConfigExtension, is available from the following locations:

jar:file:/Users/kewei/.gradle/caches/modules-2/files-2.1/org.springframework.data/spring-data-elasticsearch/5.0.0/86f7d0d3ac9be7d3dfef1b37a0850852c8c1d9e8/spring-data-elasticsearch-5.0.0.jar!/org/springframework/data/elasticsearch/repository/config/ElasticsearchRepositoryConfigExtension.class

The called method's class hierarchy was loaded from the following locations:

org.springframework.data.elasticsearch.repository.config.ElasticsearchRepositoryConfigExtension: file:/Users/kewei/.gradle/caches/modules-2/files-2.1/org.springframework.data/spring-data-elasticsearch/5.0.0/86f7d0d3ac9be7d3dfef1b37a0850852c8c1d9e8/spring-data-elasticsearch-5.0.0.jar
org.springframework.data.repository.config.RepositoryConfigurationExtensionSupport: file:/Users/kewei/.gradle/caches/modules-2/files-2.1/org.springframework.data/spring-data-commons/2.7.2/9547d1234cb380234066aef60129bb2ddfdc6347/spring-data-commons-2.7.2.jar

Action:

Correct the classpath of your application so that it contains a single, compatible version of org.springframework.data.elasticsearch.repository.config.ElasticsearchRepositoryConfigExtension

Process finished with exit code 1

How can one reproduce the bug?

Steps to reproduce the behavior.
Use the following build.gradle
plugins {
id 'java'
id 'org.springframework.boot' version '2.7.2'
id 'io.spring.dependency-management' version '1.1.0'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '17'

repositories {
mavenCentral()
}

dependencies {
implementation("org.springframework.boot:spring-boot-starter-jetty")
implementation("org.springframework.boot:spring-boot-starter-web")

implementation 'org.springframework.boot:spring-boot-starter'
implementation "org.opensearch.client:spring-data-opensearch:0.1.0"
implementation 'org.springframework.data:spring-data-elasticsearch:5.0.0'
testImplementation 'org.springframework.boot:spring-boot-starter-test'

}

tasks.named('test') {
useJUnitPlatform()
}

What is the expected behavior?

A clear and concise description of what you expected to happen.
The SpringBoot app should start without any errors.

What is your host/environment?

Operating system, version.
MacOs Monterey version 12.6

Do you have any screenshots?

If applicable, add screenshots to help explain your problem.
No

Do you have any additional context?

Add any other context about the problem.
It works well with SpringBoot version 3.0.0

[PROPOSAL] Release v1.

What/Why

What are you proposing?

Release v1.

What users have asked for this feature?

All users that want OpenSearch integration for spring-data.

Any remaining open questions?

Please add your +1 if you're interested in a release.

[BUG] Compatibility with Spring Boot 3.1.0 and spring-data-elasticsearch 3.1.0

When upgrading our Spring Boot Projects to Spring Boot 3.1.0 there occurred an IllegalAccessException in
spring-data-opensearch/src/main/java/org/opensearch/data/client/orhlc/NativeSearchQueryBuilder.java
on field indicesOptions. This is because in spring-data-elasticsearch 5.1.0 this field became private in the base class BaseQueryBuilder.

spring-data-opensearch itself depends on spring-data-elasticsearch 5.0.5, where the problem does not occur yet. But when a Spring Boot app includes spring-data-opensearch as dependency, then Spring Boot's spring-boot-dependencies parent declares spring-data-elasticsearch 5.1.0 as managed dependency, overriding the dependency version:
https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/3.1.0/spring-boot-dependencies-3.1.0.pom

The only valid workaround that works for us is explicitly declaring spring-data-elasticsearch 5.0.5 as dependency in every project (which is pretty cumbersome).

Here is an article about the general problem we have and several possible workarounds: https://spring.io/blog/2016/04/13/overriding-dependency-versions-with-spring-boot

The long term solution would probably be to change the Code of NativeSearchQueryBuilder to avoid the IllegalAccessException.

[BUG] Leftover references to Elasticsearch

What is the bug?

We have a ton of Elasticsearch references in code, https://github.com/opensearch-project/spring-data-opensearch/search?q=Elasticsearch. What's the plan to deprecate those in favor of OpenSearch?

What is the expected behavior?

All "elasticsearch" becomes "opensearch".

[FEATURE] Add `opensearch-java` client support

Is your feature request related to a problem?

The only supported client at the moment is RHLC, we should also add opensearch-java support.

What solution would you like?

Support opensearch-java

What alternatives have you considered?

Keep only RHLC

Do you have any additional context?

N/A

testcontainers-1.18.0.jar: 1 vulnerabilities (highest severity is: 5.5)

Vulnerable Library - testcontainers-1.18.0.jar

Path to dependency file: /spring-data-opensearch-examples/spring-boot-gradle/build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-compress/1.22/691a8b4e6cf4248c3bc72c8b719337d5cb7359fa/commons-compress-1.22.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-compress/1.22/691a8b4e6cf4248c3bc72c8b719337d5cb7359fa/commons-compress-1.22.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-compress/1.22/691a8b4e6cf4248c3bc72c8b719337d5cb7359fa/commons-compress-1.22.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-compress/1.22/691a8b4e6cf4248c3bc72c8b719337d5cb7359fa/commons-compress-1.22.jar

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Vulnerabilities

CVE	Severity	CVSS	Dependency	Type	Fixed in (testcontainers version)	Remediation Possible**
CVE-2023-42503	Medium	5.5	commons-compress-1.22.jar	Transitive	N/A*	❌

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2023-42503

Vulnerable Library - commons-compress-1.22.jar

Apache Commons Compress software defines an API for working with compression and archive formats. These include: bzip2, gzip, pack200, lzma, xz, Snappy, traditional Unix Compress, DEFLATE, DEFLATE64, LZ4, Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z, arj.

Library home page: https://commons.apache.org/proper/commons-compress/

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-compress/1.22/691a8b4e6cf4248c3bc72c8b719337d5cb7359fa/commons-compress-1.22.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-compress/1.22/691a8b4e6cf4248c3bc72c8b719337d5cb7359fa/commons-compress-1.22.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-compress/1.22/691a8b4e6cf4248c3bc72c8b719337d5cb7359fa/commons-compress-1.22.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-compress/1.22/691a8b4e6cf4248c3bc72c8b719337d5cb7359fa/commons-compress-1.22.jar

Dependency Hierarchy:

testcontainers-1.18.0.jar (Root Library)
- ❌ commons-compress-1.22.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0.

Users are recommended to upgrade to version 1.24.0, which fixes the issue.

A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption.

In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 1). The format for the PAX extended headers carrying this data consists of two numbers separated by a period 2, indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values.

Parsing of these numbers uses the BigDecimal 3 class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 4). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 5.

Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted.

Publish Date: 2023-09-14

URL: CVE-2023-42503

CVSS 3 Score Details (5.5)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Local
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://lists.apache.org/thread/5xwcyr600mn074vgxq92tjssrchmc93c

Release Date: 2023-09-14

Fix Resolution: org.apache.commons:commons-compress:1.24.0

wiremock-jre8-2.35.0.jar: 8 vulnerabilities (highest severity is: 10.0) - autoclosed

Vulnerable Library - wiremock-jre8-2.35.0.jar

A web service test double for all occasions

Library home page: http://wiremock.org

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.github.tomakehurst/wiremock-jre8/2.35.0/b48db2f8b752359ce6017a0251c49bcf378b7b62/wiremock-jre8-2.35.0.jar

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Vulnerabilities

CVE	Severity	CVSS	Dependency	Type	Fixed in (wiremock-jre8 version)	Remediation Possible**
CVE-2023-39967	Critical	10.0	wiremock-jre8-2.35.0.jar	Direct	N/A	❌
CVE-2023-1370	High	7.5	detected in multiple dependencies	Transitive	N/A*	❌
CVE-2023-24998	High	7.5	commons-fileupload-1.4.jar	Transitive	N/A*	❌
CVE-2023-2976	High	7.1	guava-31.1-jre.jar	Transitive	N/A*	❌
CVE-2023-41329	Medium	6.6	wiremock-jre8-2.35.0.jar	Direct	2.35.1	✅
CVE-2023-26049	Medium	5.3	detected in multiple dependencies	Transitive	N/A*	❌
CVE-2023-26048	Medium	5.3	jetty-server-9.4.49.v20220914.jar	Transitive	N/A*	❌
WS-2023-0236	Low	3.9	jetty-xml-9.4.49.v20220914.jar	Transitive	N/A*	❌

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2023-39967

Vulnerable Library - wiremock-jre8-2.35.0.jar

A web service test double for all occasions

Library home page: http://wiremock.org

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.github.tomakehurst/wiremock-jre8/2.35.0/b48db2f8b752359ce6017a0251c49bcf378b7b62/wiremock-jre8-2.35.0.jar

Dependency Hierarchy:

❌ wiremock-jre8-2.35.0.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

WireMock is a tool for mocking HTTP services. When certain request URLs like “@127.0.0.1:1234" are used in WireMock Studio configuration fields, the request might be forwarded to an arbitrary service reachable from WireMock’s instance. There are 3 identified potential attack vectors: via “TestRequester” functionality, webhooks and the proxy mode. As we can control HTTP Method, HTTP Headers, HTTP Data, it allows sending requests with the default level of credentials for the WireMock instance. The vendor has discontinued the affected Wiremock studio product and there will be no fix. Users are advised to find alternatives.

Publish Date: 2023-09-06

URL: CVE-2023-39967

CVSS 3 Score Details (10.0)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Changed
Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- Availability Impact: High

For more information on CVSS3 Scores, click here.

CVE-2023-1370

Vulnerable Libraries - json-smart-2.4.8.jar, json-smart-2.4.7.jar

json-smart-2.4.8.jar

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

Library home page: https://urielch.github.io/

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/net.minidev/json-smart/2.4.8/7c62f5f72ab05eb54d40e2abf0360a2fe9ea477f/json-smart-2.4.8.jar

Dependency Hierarchy:

wiremock-jre8-2.35.0.jar (Root Library)
- ❌ json-smart-2.4.8.jar (Vulnerable Library)

json-smart-2.4.7.jar

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

Library home page: https://urielch.github.io/

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/net.minidev/json-smart/2.4.7/8d7f4c1530c07c54930935f3da85f48b83b3c109/json-smart-2.4.7.jar

Dependency Hierarchy:

wiremock-jre8-2.35.0.jar (Root Library)
- json-path-2.7.0.jar
  - ❌ json-smart-2.4.7.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Json-smart is a performance focused, JSON processor lib. When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the code does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause a stack exhaustion (stack overflow) and crash the software.

Publish Date: 2023-03-22

URL: CVE-2023-1370

CVSS 3 Score Details (7.5)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://research.jfrog.com/vulnerabilities/stack-exhaustion-in-json-smart-leads-to-denial-of-service-when-parsing-malformed-json-xray-427633/

Release Date: 2023-03-22

Fix Resolution: net.minidev:json-smart:2.4.9

CVE-2023-24998

Vulnerable Library - commons-fileupload-1.4.jar

The Apache Commons FileUpload component provides a simple yet flexible means of adding support for multipart file upload functionality to servlets and web applications.

Library home page: http://commons.apache.org/proper/commons-fileupload/

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/commons-fileupload/commons-fileupload/1.4/f95188e3d372e20e7328706c37ef366e5d7859b0/commons-fileupload-1.4.jar

Dependency Hierarchy:

wiremock-jre8-2.35.0.jar (Root Library)
- ❌ commons-fileupload-1.4.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads.

Note that, like all of the file upload limits, the
new configuration option (FileUploadBase#setFileCountMax) is not
enabled by default and must be explicitly configured.

Publish Date: 2023-02-20

URL: CVE-2023-24998

CVSS 3 Score Details (7.5)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://tomcat.apache.org/security-10.html

Release Date: 2023-02-20

Fix Resolution: commons-fileupload:commons-fileupload:1.5;org.apache.tomcat:tomcat-coyote:8.5.85,9.0.71,10.1.5,11.0.0-M3;org.apache.tomcat.embed:tomcat-embed-core:8.5.85,9.0.71,10.1.5,11.0.0-M3;org.apache.tomcat:tomcat-util:8.5.85,9.0.71,10.1.5,11.0.0-M3;org.apache.tomcat:tomcat-catalina:8.5.85,9.0.71,10.1.5,11.0.0-M3

CVE-2023-2976

Vulnerable Library - guava-31.1-jre.jar

Guava is a suite of core and expanded libraries that include utility classes, Google's collections, I/O classes, and much more.

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.google.guava/guava/31.1-jre/60458f877d055d0c9114d9e1a2efb737b4bc282c/guava-31.1-jre.jar

Dependency Hierarchy:

wiremock-jre8-2.35.0.jar (Root Library)
- ❌ guava-31.1-jre.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Use of Java's default temporary directory for file creation in FileBackedOutputStream in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.

Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.

Mend Note: Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.

Publish Date: 2023-06-14

URL: CVE-2023-2976

CVSS 3 Score Details (7.1)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Local
- Attack Complexity: Low
- Privileges Required: Low
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-7g45-4rm6-3mm3

Release Date: 2023-06-14

Fix Resolution: com.google.guava:guava:32.0.1-android,32.0.1-jre

CVE-2023-41329

Vulnerable Library - wiremock-jre8-2.35.0.jar

A web service test double for all occasions

Library home page: http://wiremock.org

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.github.tomakehurst/wiremock-jre8/2.35.0/b48db2f8b752359ce6017a0251c49bcf378b7b62/wiremock-jre8-2.35.0.jar

Dependency Hierarchy:

❌ wiremock-jre8-2.35.0.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

WireMock is a tool for mocking HTTP services. The proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in Preventing proxying to and recording from specific target addresses. These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions. The root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact. This issue has been addressed in version 2.35.1 of wiremock-jre8 and wiremock-jre8-standalone, version 3.0.3 of wiremock and wiremock-standalone, version 2.6.1 of the python version of wiremock, and versions 2.35.1-1 and 3.0.3-1 of the wiremock/wiremock Docker container. Users are advised to upgrade. Users unable to upgrade should either configure firewall rules to define the list of permitted destinations or to configure WireMock to use IP addresses instead of the domain names.

Publish Date: 2023-09-06

URL: CVE-2023-41329

CVSS 3 Score Details (6.6)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: High
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-pmxq-pj47-j8j4

Release Date: 2023-09-06

Fix Resolution: 2.35.1

⛑️ Automatic Remediation will be attempted for this issue.

CVE-2023-26049

Vulnerable Libraries - jetty-http-9.4.49.v20220914.jar, jetty-server-9.4.49.v20220914.jar

jetty-http-9.4.49.v20220914.jar

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-http/9.4.49.v20220914/ef1e3bde212115eb4bb0740aaf79029b624d4e30/jetty-http-9.4.49.v20220914.jar

Dependency Hierarchy:

wiremock-jre8-2.35.0.jar (Root Library)
- jetty-servlets-9.4.49.v20220914.jar
  - ❌ jetty-http-9.4.49.v20220914.jar (Vulnerable Library)

jetty-server-9.4.49.v20220914.jar

The core jetty server artifact.

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.4.49.v20220914/502f99eed028139e71a4afebefa291ace12b9c1c/jetty-server-9.4.49.v20220914.jar

Dependency Hierarchy:

wiremock-jre8-2.35.0.jar (Root Library)
- ❌ jetty-server-9.4.49.v20220914.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with " (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d" will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.

Publish Date: 2023-04-18

URL: CVE-2023-26049

CVSS 3 Score Details (5.3)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: None
- Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-p26g-97m4-6q7c

Release Date: 2023-04-18

Fix Resolution: org.eclipse.jetty:jetty-http:9.4.51.v20230217,10.0.14,11.0.14, org.eclipse.jetty:jetty-runner:9.4.51.v20230217,10.0.14,11.0.14, org.eclipse.jetty:jetty-server:9.4.51.v20230217,10.0.14,11.0.14

CVE-2023-26048

Vulnerable Library - jetty-server-9.4.49.v20220914.jar

The core jetty server artifact.

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.4.49.v20220914/502f99eed028139e71a4afebefa291ace12b9c1c/jetty-server-9.4.49.v20220914.jar

Dependency Hierarchy:

wiremock-jre8-2.35.0.jar (Root Library)
- ❌ jetty-server-9.4.49.v20220914.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with @MultipartConfig) that call HttpServletRequest.getParameter() or HttpServletRequest.getParts() may cause OutOfMemoryError when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of fileSizeThreshold=0 which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw OutOfMemoryError. However, the server may be able to recover after the OutOfMemoryError and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter maxRequestSize which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).

Publish Date: 2023-04-18

URL: CVE-2023-26048

CVSS 3 Score Details (5.3)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-qw69-rqj8-6qw8

Release Date: 2023-04-18

Fix Resolution: org.eclipse.jetty:jetty-server:9.4.51.v20230217,10.0.14,11.0.14;org.eclipse.jetty:jetty-runner:9.4.51.v20230217,10.0.14,11.0.14

WS-2023-0236

Vulnerable Library - jetty-xml-9.4.49.v20220914.jar

The jetty xml utilities.

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-xml/9.4.49.v20220914/34e602eae6dd2fe54a00ec77fc98c5e77737906b/jetty-xml-9.4.49.v20220914.jar

Dependency Hierarchy:

wiremock-jre8-2.35.0.jar (Root Library)
- jetty-webapp-9.4.49.v20220914.jar
  - ❌ jetty-xml-9.4.49.v20220914.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

XmlParser is vulnerable to XML external entity (XXE) vulnerability.
XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit this vulnerability in order to achieve SSRF or cause a denial of service. One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the WAR includes a malicious web.xml. The vulnerability is patched in versions 10.0.16, 11.0.16, and 12.0.0.

Publish Date: 2023-07-10

URL: WS-2023-0236

CVSS 3 Score Details (3.9)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Local
- Attack Complexity: High
- Privileges Required: High
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-58qw-p7qm-5rvh

Release Date: 2023-07-10

Fix Resolution: org.eclipse.jetty:jetty-xml:10.0.16,11.0.16,12.0.0

⛑️Automatic Remediation will be attempted for this issue.

[BUG] Can not import jar to spring-boot app

What is the bug?

I am trying to add dependency to my app and it doesnt work. Also i don;t see any versions released anywhere.

How can one reproduce the bug?

add implementation ("org.opensearch:spring-data-opensearch") to your gradle.build

ERROR: backend:test: Could not find org.opensearch:spring-data-opensearch:.
Required by:
project :

how can i use this library?

[BUG] Upgrade Springboot 3.0.5 to 3.1.0 results in NoSuchMethodError (IndexedObjectInformation)

What is the bug?

I upgraded to Springboot 3.1.0 from 3.0.5 with Opensearch client 1.0.1 and now it results in the following error:

java.lang.NoSuchMethodError: 'org.springframework.data.elasticsearch.core.IndexedObjectInformation org.springframework.data.elasticsearch.core.IndexedObjectInformation.of(java.lang.String, java.lang.Long, java.lang.Long, java.lang.Long)'
	at org.opensearch.data.client.orhlc.OpenSearchRestTemplate.lambda$checkForBulkOperationFailure$12(OpenSearchRestTemplate.java:337)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
	at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:992)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
	at org.opensearch.data.client.orhlc.OpenSearchRestTemplate.checkForBulkOperationFailure(OpenSearchRestTemplate.java:346)
	at org.opensearch.data.client.orhlc.OpenSearchRestTemplate.doBulkOperation(OpenSearchRestTemplate.java:291)
	at org.springframework.data.elasticsearch.core.AbstractElasticsearchTemplate.bulkOperation(AbstractElasticsearchTemplate.java:356)
	at org.springframework.data.elasticsearch.core.AbstractElasticsearchTemplate.bulkIndex(AbstractElasticsearchTemplate.java:340)
	at org.springframework.data.elasticsearch.core.DocumentOperations.bulkIndex(DocumentOperations.java:185)
	at org.springframework.data.elasticsearch.core.AbstractElasticsearchTemplate.save(AbstractElasticsearchTemplate.java:237)

I am using spring-data-opensearch-starter:1.0.1

I use a ElasticsearchRepository and call saveAll

This is fine with Spring boot 3.0.5

[FEATURE] Reactive version of the clients

Is your feature request related to a problem?

Hi there, and apologies if it is too early/it's not on your roadmap/ has already been discussed elsewhere and I have missed it.
First of all thanks for all the hard work, I have been eagerly following your work on spring-data-opensearch and already started looking into how this library evolves. We are currently using an older version of Opensearch (1.2.4) alongside the spring-data-elasticsearch library. While playing around with the the merged code, I noticed that there are no equivalents of the reactive versions of the client/configuration. Is this something that you plan to add?

What solution would you like?

Support reactive version of the clients

What alternatives have you considered?

N/A

Do you have any additional context?

N/A

[Refactor] XContent from common to core namespace

XContent namespace refactor from common -> core is going to be merged to opensearch/2.x which will break the 2.x build. This issue is for refactoring XContent imports from the common to core namespace after the core namespace change is merged.

Depends on opensearch-project/OpenSearch#6470

hoverfly-java-junit5-0.14.4.jar: 3 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - hoverfly-java-junit5-0.14.4.jar

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.squareup.okio/okio/2.8.0/49b64e09d81c0cc84b267edd0c2fd7df5a64c78c/okio-jvm-2.8.0.jar

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Vulnerabilities

CVE	Severity	CVSS	Dependency	Type	Fixed in (hoverfly-java-junit5 version)	Remediation Possible**
CVE-2023-3635	High	7.5	okio-2.8.0.jar	Transitive	N/A*	❌
CVE-2022-24329	Medium	5.3	kotlin-stdlib-1.4.10.jar	Transitive	N/A*	❌
CVE-2020-29582	Medium	5.3	kotlin-stdlib-1.4.10.jar	Transitive	N/A*	❌

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2023-3635

Vulnerable Library - okio-2.8.0.jar

A modern I/O API for Java

Library home page: https://github.com/square/okio/

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.squareup.okio/okio/2.8.0/49b64e09d81c0cc84b267edd0c2fd7df5a64c78c/okio-jvm-2.8.0.jar

Dependency Hierarchy:

hoverfly-java-junit5-0.14.4.jar (Root Library)
- hoverfly-java-0.14.4.jar
  - okhttp-4.9.3.jar
    - ❌ okio-2.8.0.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

GzipSource does not handle an exception that might be raised when parsing a malformed gzip buffer. This may lead to denial of service of the Okio client when handling a crafted GZIP archive, by using the GzipSource class.

Publish Date: 2023-07-12

URL: CVE-2023-3635

CVSS 3 Score Details (7.5)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://www.cve.org/CVERecord?id=CVE-2023-3635

Release Date: 2023-07-12

Fix Resolution: com.squareup.okio:okio-jvm:3.4.0

CVE-2022-24329

Vulnerable Library - kotlin-stdlib-1.4.10.jar

Kotlin Standard Library for JVM

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.4.10/ea29e063d2bbe695be13e9d044dcfb0c7add398e/kotlin-stdlib-1.4.10.jar

Dependency Hierarchy:

hoverfly-java-junit5-0.14.4.jar (Root Library)
- hoverfly-java-0.14.4.jar
  - okhttp-4.9.3.jar
    - ❌ kotlin-stdlib-1.4.10.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

In JetBrains Kotlin before 1.6.0, it was not possible to lock dependencies for Multiplatform Gradle Projects.

Publish Date: 2022-02-25

URL: CVE-2022-24329

CVSS 3 Score Details (5.3)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: Low
- Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-2qp4-g3q3-f92w

Release Date: 2022-02-25

Fix Resolution: org.jetbrains.kotlin:kotlin-stdlib:1.6.0

CVE-2020-29582

Vulnerable Library - kotlin-stdlib-1.4.10.jar

Kotlin Standard Library for JVM

Path to dependency file: /build.gradle.kts

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.4.10/ea29e063d2bbe695be13e9d044dcfb0c7add398e/kotlin-stdlib-1.4.10.jar

Dependency Hierarchy:

hoverfly-java-junit5-0.14.4.jar (Root Library)
- hoverfly-java-0.14.4.jar
  - okhttp-4.9.3.jar
    - ❌ kotlin-stdlib-1.4.10.jar (Vulnerable Library)

Found in HEAD commit: 93f238407acbaff2e9420d809abd20c002226565

Found in base branch: main

Vulnerability Details

In JetBrains Kotlin before 1.4.21, a vulnerable Java API was used for temporary file and folder creation. An attacker was able to read data from such files and list directories due to insecure permissions.

Publish Date: 2021-02-03

URL: CVE-2020-29582

CVSS 3 Score Details (5.3)

Base Score Metrics:

Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: None
- Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-cqj8-47ch-rvvq

Release Date: 2021-02-03

Fix Resolution: org.jetbrains.kotlin:kotlin-stdlib:1.4.21

[FEATURE] Support composable index templates

Is your feature request related to a problem?

As far as I can tell, the spring-data-opensearch library currently only supports the deprecated _template api. It would be great to be able to integrate with the new _index_template api, which also has support for composable index templates, instead of having to use a deprecated api.

What solution would you like?

Implement methods which use the new _index_template api.

org.opensearch.client.sniff.Sniffer : error while sniffing nodes

What is the bug?

org.opensearch.client.sniff.Sniffer : error while sniffing nodes
java.net.ConnectException: Connection refused
at org.opensearch.client.RestClient.extractAndWrapCause(RestClient.java:953) ~[opensearch-rest-client-2.6.0.jar:2.6.0]
at org.opensearch.client.RestClient.performRequest(RestClient.java:332) ~[opensearch-rest-client-2.6.0.jar:2.6.0]
at org.opensearch.client.RestClient.performRequest(RestClient.java:320) ~[opensearch-rest-client-2.6.0.jar:2.6.0]
at org.opensearch.client.sniff.OpenSearchNodesSniffer.sniff(OpenSearchNodesSniffer.java:121) ~[opensearch-rest-client-sniffer-2.5.0.jar:2.5.0]
at org.opensearch.client.sniff.Sniffer.sniff(Sniffer.java:223) ~[opensearch-rest-client-sniffer-2.5.0.jar:2.5.0]
at org.opensearch.client.sniff.Sniffer$Task.run(Sniffer.java:154) ~[opensearch-rest-client-sniffer-2.5.0.jar:2.5.0]

Spring Data 1.0.1 brings in the opensearch-rest-client-sniffer-2.5.0 dependency and the above error is reported repeatedly.

What is the expected behavior?

Tried to disable sniffer as explained in https://stackoverflow.com/questions/73056569/how-do-i-stop-hibernate-search-from-sniffing-the-nodes-of-a-non-existent-local-e
Added exclusion for OpenSearchRestHighLevelClientAutoConfiguration and OpenSearchDataAutoConfiguration

None of the above helped and the exception is repeated.
The config is connecting to a cluster of 3 nodes. (All functionality is working. Able to connect to OpenSearch, persist and retrieve records.)

What is your host/environment?

Redhat 8
Java 17
Spring Data OpenSearch - 1.0.1

Do you have any additional context?

Connecting to OpenSearch 2.6.0 cluster.

[FEATURE] Add in actuator health indicator

I'm not sure if this should be a feature request for this project or the spring boot actuator project since the elasticsearch indicator is provided by that project. Raising here since the spring-data-elasticsearch project is a spring project, whereas spring-data-opensearch is not, hopefully this is the right place!

Is your feature request related to a problem?

If our application is unable to connect to opensearch then we can see lots of errors in the logs such as

2023-05-17 13:16:26.135 ERROR 1862 --- [nt_sniffer[T#1]] org.opensearch.client.sniff.Sniffer      : error while sniffing nodes |

however the application does start up and the /actuator/health endpoint shows that all is healthy status is UP. This is incorrect since the application is certainly not healthy if it can't connect to opensearch.

What solution would you like?

It would therefore be good to have a health indicator that is automatically included to indicate whether we can connect to opensearch. Note that the elasticsearch health indicator actually calls the /_cluster/health endpoint, which goes beyond checking whether we can connect to the cluster and actually lets us know the state of the cluster. If this is a relatively cheap operation then this sounds fine, otherwise some sort of ping would normally be preferable.

What alternatives have you considered?

We could write our own health indicator, but it feels like there should be something out of the box.

[BUG]

What is the bug?

We are currently trying to migrate the spring boot application from elasticsearch to opensearch and using the dependency of "spring-data-opensearch".

We are getting an error regarding the VersionType class when we run the application.

This is caused from the entity classes that has @document defined in them which uses the org.springframework.data.elasticsearch.annotations.Document which is internally using VersionType class from "org.elasticsearch.index.VersionType". Which is the root cause of the issue as 'index' folder is not found in the elasticsearch dependency.

How can one reproduce the bug?

Use the spring boot parent version 2.5.13 and java version 11.
With maven dependency of "spring-data-opensearch" / 'spring-data-opensearch-starter".

Your application should have a entity file with @document annotation. When you run the application you will see the error with VersionType class

What is the expected behavior?

Migration from elasticsearch to opensearch should not cause any issues and the transaction must be seemless

What is your host/environment?

_macOSVentura 13.2.1

Do you have any additional context?

_This issue is caused when migrating the elasticsearch to opensearch

[FEATURE] Implement IndexTemplate related methods in RestIndexTemplate

Is your feature request related to a problem?

Since version 5.1 of spring-data-elasticsearch, various methods from IndexOperation interface have been added and a few other have been marked as deprecated. For instance to check if a template exist, deprecated method is existsTemplate while methods existsComponentTemplate and existsIndexTemplate have been added.
Unfortunately when trying to remove any deprecated call from my project code relying on this, I got a UnsupportedOperationException. Indeed inside RestIndexTemplate (from spring-data-opensearch) there are 8 methods throwing UnsupportedOperationException("not implemented"); all related to index and component template CRUD.

What solution would you like?

I'd like that the new component and index template related methods were implemented so that I can use them and not relying on deprecated API in my project (which triggers warning in my CI that I can't solve yet).

What alternatives have you considered?

I keep relying on the deprecated API, but then when spring-data-elasticsearch will remove the deprecated methods from the interface (in 5.2 for instance).

Do you have any additional context?

The elastic search specific implementation from spring-data-elasticsearch is (in release 5.1.4) at the same status, methods not implemented.

Baseline MAINTAINERS, CODEOWNERS, and external collaborator permissions

Follow opensearch-project/.github#125 to baseline MAINTAINERS, CODEOWNERS, and external collaborator permissions.

Close this issue when:

1. MAINTAINERS.md has the correct list of project maintainers.
2. CODEOWNERS exists and has the correct list of aliases.
3. Repo permissions only contain individual aliases as collaborators with maintain rights, admin, and triage teams.
4. All other teams are removed from repo permissions.

If this repo's permissions was already baselined, please confirm the above when closing this issue.

[PROPOSAL] Change Maven groupId

The groupId is currently set to org.opensearch which is the top-level for OpenSearch. I suggest we have a sub-groupId. I'd probably recommend org.opensearch.client to have it sit with other Java clients. But, perhaps org.opensearch.spring is appropriate.

[FEATURE] Update REST client used in OpenSearchRestTemplate

Is your feature request related to a problem?

The client used in org.opensearch.data.client.orhlc.OpenSearchRestTemplate, org.opensearch.client.RestHighLevelClient, has been deprecated in Elasticsearch since v7.15. The OpenSearch documentation also considers it deprecated.

What solution would you like?

The OpenSearchRestTemplate should use the Java client org.opensearch.client.opensearch.OpenSearchClient instead.

What alternatives have you considered?

Continuing to use the deprecated client runs the risk of breakage through its removal.

Do you have any additional context?

No

[PROPOSAL] Add CHANGELOG

What/Why

What are you proposing?

Add CHANGELOG enforced with a GHA.

What users have asked for this feature?

I'd like every PR to come with an entry in CHANGELOG so we know what's changing with every release without having to manually collect release notes. See opensearch-project/OpenSearch#1868 for more details.

opensearch-project / spring-data-opensearch Goto Github PK

spring-data-opensearch's People

Contributors

Stargazers

Watchers

Forkers

spring-data-opensearch's Issues

Is your feature request related to a problem?

What solution would you like?

What alternatives have you considered?

Is your feature request related to a problem?

What solution would you like?

Do you have any additional context?

Vulnerabilities

Details

Vulnerable Library - okio-2.8.0.jar

Vulnerability Details

CVSS 3 Score Details (7.5)

Suggested Fix

Vulnerable Library - kotlin-stdlib-1.4.10.jar

Vulnerability Details

CVSS 3 Score Details (5.3)

Suggested Fix

Vulnerable Library - kotlin-stdlib-1.4.10.jar

Vulnerability Details

CVSS 3 Score Details (5.3)

Suggested Fix

What/Why

What are you proposing?

What problems are you trying to solve?

What is the developer experience going to be?

Are there any security considerations?

Are there any breaking changes to the API

What is the user experience going to be?

Are there breaking changes to the User Experience?

What/Why

What are you proposing?

What problems are you trying to solve?

What is the bug?

What/Why

What are you proposing?

What problems are you trying to solve?

What is the developer experience going to be?

Are there any security considerations?

Is your feature request related to a problem?

What solution would you like?

What alternatives have you considered?

Do you have any additional context?

What is the bug?

How can one reproduce the bug?

What is the expected behavior?

Do you have any additional context?

Vulnerabilities

Details

Vulnerable Library - wiremock-jre8-2.35.1.jar

Vulnerability Details

CVSS 3 Score Details (10.0)

Vulnerable Libraries - json-smart-2.4.8.jar, json-smart-2.4.7.jar

json-smart-2.4.8.jar

json-smart-2.4.7.jar

Vulnerability Details

CVSS 3 Score Details (7.5)

Suggested Fix

Vulnerable Library - commons-fileupload-1.4.jar

Vulnerability Details

CVSS 3 Score Details (7.5)

Suggested Fix

Vulnerable Library - guava-31.1-jre.jar

Vulnerability Details

CVSS 3 Score Details (7.1)

Suggested Fix

Vulnerable Libraries - jetty-http-9.4.49.v20220914.jar, jetty-server-9.4.49.v20220914.jar

jetty-http-9.4.49.v20220914.jar

jetty-server-9.4.49.v20220914.jar

Vulnerability Details

CVSS 3 Score Details (5.3)

Suggested Fix

Vulnerable Library - jetty-server-9.4.49.v20220914.jar

Vulnerability Details

CVSS 3 Score Details (5.3)