Rebase v3.2.0 #4
Conversation
Other Debezium parts, e.g. `SmtManager` use validation error as a signal for invalida configuration and thus using deprecated option results into the failure.
…n dedicated module
Co-authored-by: roldanbob <23705736+roldanbob@users.noreply.github.com>
![jit-ci[bot]](https://avatars.githubusercontent.com/in/142441?s=60&v=4){kind=small}
There was a problem hiding this comment.
❌ Jit has detected 9 important findings in this PR that you should review.
The findings are detailed below as separate comments.
It’s highly recommended that you fix these security issues before merge.
Repository Risks:
- Database Integration: Connects to a database, often involving sensitive data that must be securely managed.
- Critical Severity Findings: Indicates that the resource has critical severity security findings that need immediate action.
Repository Context:
graph LR
GitHub$Repository_U23_RedisLabs/debezium["GitHub Repository<br/>RedisLabs/debezium"]:::GitHub$Repository
Team_U23_RDI["Team<br/>RDI"]:::Team
DBIntegration_U23_mysql["DBIntegration<br/>mysql"]:::DBIntegration
Team_U23_RDI -- "Owns" --> GitHub$Repository_U23_RedisLabs/debezium
GitHub$Repository_U23_RedisLabs/debezium -- "Is accessible to" --> DBIntegration_U23_mysql
| - name: Build Debezium (Core) | ||
| if: inputs.cache-hit != 'true' | ||
| shell: ${{ inputs.shell }} | ||
| run: > |
There was a problem hiding this comment.
Security control: Static Code Analysis Semgrep Pro
Yaml.Github-Actions.Security.Run-Shell-Injection.Run-Shell-Injection
Using variable interpolation ${{...}} with github context data in a run: step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. github context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with env: to store the data and use the environment variable in the run: script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "yaml.github-actions.security.run-shell-injection.run-shell-injection" in .github/actions/build-debezium-informix/action.yml; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
|
|
||
| - name: Build MongoDB connector (MongoDB ${{ inputs.version-mongo-server }}) | ||
| shell: ${{ inputs.shell }} | ||
| run: > |
There was a problem hiding this comment.
Security control: Static Code Analysis Semgrep Pro
Yaml.Github-Actions.Security.Run-Shell-Injection.Run-Shell-Injection
Using variable interpolation ${{...}} with github context data in a run: step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. github context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with env: to store the data and use the environment variable in the run: script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "yaml.github-actions.security.run-shell-injection.run-shell-injection" in .github/actions/build-debezium-mongodb/action.yml; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| </dependency> | ||
| <dependency> | ||
| <groupId>ch.qos.logback</groupId> | ||
| <artifactId>logback-classic</artifactId> |
There was a problem hiding this comment.
Security control: Software Component Analysis Java
Qos.Ch Logback Vulnerable To Deserialization Of Untrusted Data
QOS.ch Logback before 1.2.0 has a serialization vulnerability affecting the SocketServer and ServerSocketReceiver components. The RemoteStreamAppenderClient class in logback-classic and the SocketNode classes in logback-classic and logback-access allow data to be deserialized over a Java Socket, via an ObjectInputStream, without validating the data beforehand. When data is received from the Socket, to be logged, it is deserialized into Java objects.An attacker can exploit this vulnerability by sending malicious, serialized Java objects over the connection to the Socket, which may result in execution of arbitrary code when those objects are deserialized. Note that although logback-core is implicated by the Logback project here, the Sonatype Security Research team discovered that the vulnerability is actually present in the logback-classic and logback-access components. Versions prior to 1.2.0 are vulnerable, as stated in the advisory.
Is fix available? Yes, this issue was fixed in version 1.2.0
Severity: CRITICAL
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "QOS.ch Logback vulnerable to Deserialization of Untrusted Data" in debezium-ai/debezium-ai-embeddings-voyage-ai/pom.xml; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| </dependency> | ||
| <dependency> | ||
| <groupId>ch.qos.logback</groupId> | ||
| <artifactId>logback-classic</artifactId> |
There was a problem hiding this comment.
Security control: Software Component Analysis Java
Logback Serialization Vulnerability
A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data.
This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html
Is fix available? Yes, this issue was fixed in the following versions: 1.2.13, 1.3.12, 1.4.12
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "logback serialization vulnerability" in debezium-ai/debezium-ai-embeddings-voyage-ai/pom.xml; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| </dependency> | ||
| <dependency> | ||
| <groupId>ch.qos.logback</groupId> | ||
| <artifactId>logback-classic</artifactId> |
There was a problem hiding this comment.
Security control: Software Component Analysis Java
Qos.Ch Logback Vulnerable To Deserialization Of Untrusted Data
QOS.ch Logback before 1.2.0 has a serialization vulnerability affecting the SocketServer and ServerSocketReceiver components. The RemoteStreamAppenderClient class in logback-classic and the SocketNode classes in logback-classic and logback-access allow data to be deserialized over a Java Socket, via an ObjectInputStream, without validating the data beforehand. When data is received from the Socket, to be logged, it is deserialized into Java objects.An attacker can exploit this vulnerability by sending malicious, serialized Java objects over the connection to the Socket, which may result in execution of arbitrary code when those objects are deserialized. Note that although logback-core is implicated by the Logback project here, the Sonatype Security Research team discovered that the vulnerability is actually present in the logback-classic and logback-access components. Versions prior to 1.2.0 are vulnerable, as stated in the advisory.
Is fix available? Yes, this issue was fixed in version 1.2.0
Severity: CRITICAL
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "QOS.ch Logback vulnerable to Deserialization of Untrusted Data" in debezium-ai/debezium-ai-embeddings-hugging-face/pom.xml; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| <dependencies> | ||
| <dependency> | ||
| <groupId>io.quarkus</groupId> | ||
| <artifactId>quarkus-core</artifactId> |
There was a problem hiding this comment.
Security control: Software Component Analysis Java
Quarkus-Core Leaks Local Environment Variables From Quarkus Namespace During Application'S Build
A vulnerability was found in the quarkus-core component. Quarkus captures the local environment variables from the Quarkus namespace during the application's build. Thus, running the resulting application inherits the values captured at build time.
However, some local environment variables may have been set by the developer / CI environment for testing purposes, such as dropping the database during the application startup or trusting all TLS certificates to accept self-signed certificates. If these properties are configured using environment variables or the .env facility, they are captured into the built application. It may lead to dangerous behavior if the application does not override these values.
This behavior only happens for configuration properties from the quarkus.* namespace. So, application-specific properties are not captured.
Is fix available? Yes, this issue was fixed in the following versions: 3.2.12.Final, 3.8.4, 3.9.2
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "quarkus-core leaks local environment variables from Quarkus namespace during application's build" in quarkus-debezium-parent/quarkus-debezium-engine-parent/runtime/pom.xml; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| </dependency> | ||
| <dependency> | ||
| <groupId>ch.qos.logback</groupId> | ||
| <artifactId>logback-classic</artifactId> |
There was a problem hiding this comment.
Security control: Software Component Analysis Java
Logback Serialization Vulnerability
A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data.
This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html
Is fix available? Yes, this issue was fixed in the following versions: 1.2.13, 1.3.12, 1.4.12
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "logback serialization vulnerability" in debezium-ai/debezium-ai-embeddings-hugging-face/pom.xml; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| <dependencies> | ||
| <dependency> | ||
| <groupId>io.quarkus</groupId> | ||
| <artifactId>quarkus-core</artifactId> |
There was a problem hiding this comment.
Security control: Software Component Analysis Java
Quarkus-Core Leaks Local Environment Variables From Quarkus Namespace During Application'S Build
A vulnerability was found in the quarkus-core component. Quarkus captures the local environment variables from the Quarkus namespace during the application's build. Thus, running the resulting application inherits the values captured at build time.
However, some local environment variables may have been set by the developer / CI environment for testing purposes, such as dropping the database during the application startup or trusting all TLS certificates to accept self-signed certificates. If these properties are configured using environment variables or the .env facility, they are captured into the built application. It may lead to dangerous behavior if the application does not override these values.
This behavior only happens for configuration properties from the quarkus.* namespace. So, application-specific properties are not captured.
Is fix available? Yes, this issue was fixed in the following versions: 3.2.12.Final, 3.8.4, 3.9.2
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "quarkus-core leaks local environment variables from Quarkus namespace during application's build" in quarkus-debezium-parent/quarkus-debezium-engine-spi-parent/runtime/pom.xml; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| quarkus.datasource.db-kind=postgresql | ||
| quarkus.datasource.username=native | ||
| quarkus.datasource.password=native | ||
| quarkus.datasource.jdbc.url=jdbc:postgresql://localhost:5432/native |
There was a problem hiding this comment.
Security control: Secret Detection Trufflehog
Jdbc
JDBC (Unverified)
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "JDBC" in quarkus-debezium-parent/quarkus-debezium-postgres-parent/integration-test/src/main/resources/application.properties; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
|
It looks like the current working branch is This way, it would be an actual rebase, and it will be possible to review the changes. Additionally, the latest release in the 3.2 series is v3.2.3.Final. Would it make sense to use it as the base instead? It shouldn't contain any additional breaking changes compared to v3.2.0.Final but may contain bug fixes. |
i was just testing and i will sync additionally with the team on which branch to rebase to |
20 participants
No description provided.