oscerd opened a new pull request, #3055:
URL: https://github.com/apache/camel-kamelets/pull/3055
Closes #3054, raised by the weekly catalog dependency scan for
GHSA-gx6c-pv62-9mcf (CVE-2026-3293) against the pinned `snowflake-jdbc:3.24.2`.
## No 3.x clears it
189 affected versions, the highest being `4.0.1`. The newest 3.x on Central,
`3.28.0`, is still affected; `4.1.0` onwards are clean. So this is a major
version move, not a patch bump.
## 4.x moved the class both Kamelets used
`net.snowflake.client.jdbc` now contains only `SnowflakeDriver`.
`SnowflakeBasicDataSource`, which both templates instantiated, moved to an
internal package, and the public DataSource is an **interface** produced by a
factory:
```yaml
- name: dsBean
type:
"#class:net.snowflake.client.api.datasource.SnowflakeDataSourceFactory"
factoryMethod: "createDataSource"
properties:
user: '{{username}}'
password: '{{password}}'
url: 'jdbc:snowflake://{{instanceUrl}}'
databaseName: '{{?databaseName}}'
```
All four properties exist on the new interface, so the configuration surface
is unchanged for users.
## The version belongs in pom.xml, not the Kamelet
Worth recording, because it is easy to get wrong: the `groovy-maven-plugin`
execution at `process-resources` rewrites the `mvn:` coordinates in `kamelets/`
from the `version.*` properties in the root pom. I edited the YAML first and
the next build silently put `3.24.2` back. The canonical change is:
```xml
<version.net.snowflake.snowflake-jdbc>4.3.4</version.net.snowflake.snowflake-jdbc>
```
and the build propagates it to both Kamelets and to the catalog SBOM.
This also refines something I wrote on #3050. I said these pinned versions
are invisible to Dependabot because they live in Kamelet YAML. Eleven of the
seventeen are actually pom properties — but *orphan* properties, referenced by
no `<dependency>` declaration and consumed only by that groovy script, so
Dependabot does not update them either. Dependabot has never touched one. The
conclusion stands; the mechanism I described did not.
## Verified
- A route instantiating `snowflake-sink` against 4.3.4 starts cleanly:
`Routes startup (total:1 started:1 kamelets:1)`. The same route against the old
bean type fails with `ClassNotFoundException:
net.snowflake.client.jdbc.SnowflakeBasicDataSource`, which is how I confirmed
the class is genuinely gone rather than relocated in a way `#class:` would
still find.
- The catalog dependency scan now exits `0`: no advisories against the 17
pinned artifacts, none against the 115 Camel components.
- `mvn clean install` green.
- 4.3.4 still ships Java 8 bytecode, so the Java 17 baseline is unaffected.
## Not verified
**An actual connection to Snowflake.** There are no Citrus tests for these
Kamelets and exercising them needs a real account, so what is checked here is
the wiring and bean creation, not the round trip. Someone with an account
should sanity-check a real query before this is relied on — in particular
whether `url` alone still suffices in 4.x or whether `account` is now expected,
since the 4.x examples set it explicitly.
---
_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]
