oscerd commented on issue #3054:
URL:
https://github.com/apache/camel-kamelets/issues/3054#issuecomment-5756981135
Looked into what fixing this would take. **It is not a version bump, and I
would not apply one blind.**
## No 3.x is clean
The advisory lists 189 affected versions. The highest affected is `4.0.1`,
and `4.1.0` onwards are clean:
```
3.24.2 -> GHSA-gx6c-pv62-9mcf (what we pin)
3.28.0 -> GHSA-gx6c-pv62-9mcf (newest 3.x on Central)
4.0.1 -> GHSA-gx6c-pv62-9mcf
4.1.0 -> clean
4.3.4 -> clean (current release)
```
So staying on 3.x is not an option; the fix is a major version move.
## 4.x moves the class both Kamelets depend on
`snowflake-sink` and `snowflake-source` create their DataSource bean like
this:
```yaml
- name: dsBean
type: "#class:net.snowflake.client.jdbc.SnowflakeBasicDataSource"
properties:
user: '{{username}}'
password: '{{password}}'
url: 'jdbc:snowflake://{{instanceUrl}}'
databaseName: '{{?databaseName}}'
```
In 4.3.4 that class **is not there**. The 4.x line is a deliberate API
restructuring:
- `net/snowflake/client/jdbc/` now contains exactly one public class,
`SnowflakeDriver`
- the public DataSource is
`net.snowflake.client.api.datasource.SnowflakeDataSource`, and it is an
**interface**, so `#class:` cannot instantiate it
- instances come from
`net.snowflake.client.api.datasource.SnowflakeDataSourceFactory`
- the old `SnowflakeBasicDataSource` still exists, but as
`net.snowflake.client.internal.api.implementation.datasource.SnowflakeBasicDataSource`,
which is explicitly internal
The setters the templates rely on (`setUser`, `setPassword`, `setUrl`,
`setDatabaseName`) do survive on the new interface, so the shape of the
configuration is unchanged. What changes is how the bean is obtained, and no
Kamelet in this catalog currently creates a bean through a factory method.
The Java baseline is not a problem: 4.3.4 still ships Java 8 bytecode.
## Why I stopped rather than pushing a change
A bump to 4.x would need the bean block reworked in two Kamelets, and
**there are no Citrus tests for snowflake** — verifying it needs a real
Snowflake account, which is not something CI has. Shipping an untested rewrite
of both Kamelets to chase this particular advisory looks like a poor trade:
`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L` — local, no confidentiality
or integrity impact, availability only, and it goes through
`SdkProxyRoutePlanner`, so it is reachable only where a proxy is configured.
## Options, for someone who can test this
1. Rework both Kamelets onto `SnowflakeDataSourceFactory` and bump to 4.3.4.
Correct, and needs an account to verify.
2. Leave the pin and record the decision, given the severity and the
reachability. The scanner will keep reporting it, which is arguably the right
outcome for a known-and-accepted risk.
3. Add the advisory to `camel-kamelets-sbom.vex.json` as
not-affected-with-justification, if the proxy path is genuinely unreachable for
these Kamelets. That is what the VEX file next to the SBOM is for, and it would
stop the weekly noise without hiding anything.
I have not assigned this to myself; option 1 wants hands that can run
against Snowflake.
---
_Claude Code on behalf of Andrea Cosentino_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
