mirror of
https://github.com/open-metadata/OpenMetadata
synced 2026-05-24 09:39:11 +00:00
6c30d82f4c
* fix(security): pin libthrift 0.23.0 and exclude Jackson 3.x from jsonschema2pojo-core
- Pin org.apache.thrift:libthrift to 0.23.0 in dependencyManagement.
apache-jena-libs:4.10.0 transitively pulls libthrift:0.19.0 which is
vulnerable to CVE-2026-43869 (fixed in 0.23.0).
- Exclude tools.jackson.core:jackson-core and jackson-databind from
jsonschema2pojo-core in common/pom.xml. jsonschema2pojo-core 1.3.x
switched its internal Jackson to 3.x; the existing exclusion only
covered the legacy com.fasterxml.jackson.core groupId, so 3.0.2 jars
were leaking into the runtime classpath despite our annotator code
using Jackson 2.x exclusively. Removes exposure to:
- GHSA-2m67-wjpj-xhg9
- CVE-2026-29062
- GHSA-72hv-8253-57qq (3.x line)
* chore(security): bump azure-security-keyvault-secrets and simple-java-mail to fix transitive CVEs
- com.azure:azure-security-keyvault-secrets 4.10.0 → 4.10.7
4.10.7 declares azure-core-http-netty 1.16.4, which uses
reactor-netty-http 1.2.16. Replaces the second source path of
reactor-netty-http 1.0.48 in the OM standalone dist.
Fixes CVE-2025-22227 (the azure-kv path).
- org.simplejavamail:simple-java-mail 8.12.2 → 8.12.6
Hygiene bump (4 patch versions). Note: simple-java-mail 8.12.6's
master pom still pins angus-mail to 2.0.3, so the actual angus-mail
fix for CVE-2025-7962 still relies on OM's existing
<angus-mail.version>2.0.4</angus-mail.version> dep-management entry,
which already wins for OM standalone (verified: openmetadata-1.12.7
dist already ships angus-mail-2.0.4.jar).
* fix(security): switch libthrift fix from version-pin to exclusion; expand reasoning comments
libthrift (CVE-2026-43869):
Replace the dependencyManagement pin to 0.23.0 with an explicit <exclusion>
on apache-jena-libs. OM's source tree has zero org.apache.thrift imports and
no references to RDF Thrift binary serialization (RDF_THRIFT, ThriftConvert,
RDFFormat.*THRIFT) — the only consumer of libthrift in our dep tree is Jena's
optional RDF Thrift I/O code path, which OM never exercises.
libthrift 0.23.0 was published 2026-05-08 and no Jena release yet ships it
(Jena 6.0.0 and 5.6.0 still ship libthrift 0.22.0, also vulnerable). Pinning
would force a Jena-uncertified libthrift onto code Jena tests with 0.22.0;
excluding the unused JAR is cleaner and self-cleaning when Jena bumps.
Lucene/Solr (also in this dep tree) already excludes libthrift for the same
reason — confirmed via lucene-solr-grandparent pom.
Jackson 3.x exclusion: expanded the comment in common/pom.xml to record the
upstream state (jsonschema2pojo-core 1.3.3 still pins jackson3.version=3.0.2)
and the verification that build succeeds with the exclusion.
* fix(security): mark jsonschema2pojo-core as <optional> instead of maintaining per-dep exclusion list
Per Copilot review on PR #28010 (line 66 of common/pom.xml): jsonschema2pojo-core
is build-time only — the annotator classes that reference it (PasswordAnnotator,
MaskedAnnotator, etc.) are invoked exclusively by the jsonschema2pojo-maven-plugin
at code-gen time, never on the runtime classpath of any deployed service.
Switch from a growing list of <exclusion> entries (which only caught the deps
known at the time each entry was added) to <optional>true</optional>. This stops
jsonschema2pojo-core AND every transitive dep it pulls — current and future —
from propagating to downstream consumers' runtime classpath.
Effect on the GHSA-2m67-wjpj-xhg9 / CVE-2026-29062 / GHSA-72hv-8253-57qq fix:
the jackson-core-3.0.2 / jackson-databind-3.0.2 jars (groupId tools.jackson.core)
no longer leak into the dist via this path. Verified:
$ mvn -pl openmetadata-service dependency:tree -Dincludes='tools.jackson.core:*,org.jsonschema2pojo:*'
(empty)
$ mvn -pl openmetadata-spec -am install -DskipTests
BUILD SUCCESS (annotator code-gen still works — jsonschema2pojo-maven-plugin
pulls jsonschema2pojo-core via its own <dependencies> block,
and adds common.jar there too via openmetadata-spec/pom.xml)
* fix(security): revert libthrift exclusion → pin to 0.23.0; Jena statically references TException
The exclusion broke RDF tests:
RdfInferenceConfigurationTest, RdfPropertyMapperTest,
SparqlBuilderNestedFieldsTest, SqlToSparqlTranslatorTest
fail with `Could not initialize class org.apache.jena.rdf.model.ModelFactory`
and `org/apache/thrift/TException` (NoClassDefFoundError).
Even though OM never calls RDF Thrift I/O directly, several Jena classes
(ModelFactory, PrefixMappingImpl, etc.) statically reference
org.apache.thrift.TException at class-init time. Removing libthrift fails
class loading on the very first use of any Jena Model.
The grep for `org.apache.thrift` in OM source missed this because the
references are in Jena's own bytecode, not OM's source.
Reverting the exclusion. Pinning libthrift to 0.23.0 in dependencyManagement
remains the only available fix:
- No Jena release ships the fix (latest 6.0.0 still uses 0.22.0;
libthrift 0.23.0 was published 2026-05-08).
- Exclusion breaks the build (above).
- Pinning forces the fixed version onto Jena's classpath; libthrift
maintains backwards-compatible binary protocol semantics, so Jena's
runtime usage continues to work. CI will validate.
In-pom comment expanded to record this discovery so the trade-off doesn't
get re-litigated next round.
* chore: shorten security comments in poms
* fix(security): exclude netty-transport-native-epoll from azure-core-http-netty
GHSA-rwm7-x88c-3g2p / CVE-2026-42577 (AWS Inspector reports HIGH). The bug is
in netty 4.2.x epoll; we ship 4.1.x. The advisory's machine-readable
vulnerable_version_range is < 4.2.13.Final (overly broad), which causes
scanners to flag 4.1.x even though the buggy code path was never in 4.1.
Bumping our netty to 4.2.13.Final is blocked by Azure SDK / gRPC / AWS SDK /
reactor-netty all targeting 4.1.x. Instead, exclude the Linux native binding
JAR (the only thing in our tree that is named io.netty:netty-transport-native-epoll)
so the flagged artifact stops shipping in the dist. Netty's standard pattern is
to call Epoll.isAvailable() and fall back to NioEventLoopGroup when the native
binding is absent — the exact same code path already used on macOS/Windows
deployments. netty-transport-classes-epoll (the Java classes, required by
reactor-netty/lettuce/AWS-netty-nio-client bytecode references) stays.
Verified:
mvn -pl openmetadata-service -am dependency:tree \
-Dincludes='io.netty:netty-transport-native-epoll'
-> empty (was: 4.1.133.Final-linux-x86_64)
* fix(security): align reactor-netty-http dep-mgmt pin to 1.2.16
Per Copilot review on PR #28010 (line 19): the bump of azure-kv to 4.10.7 was
described as bringing reactor-netty-http 1.2.16, but the existing dep-mgmt pin
to 1.2.14 was overriding the transitive (mvn dependency:tree confirmed 1.2.14
was the actual resolved version).
Bump the pin 1.2.14 → 1.2.16 to match what azure-core-http-netty 1.16.4 ships
transitively. Both are above the CVE-2025-22227 fix line (≥ 1.2.8), so this is
a pin-alignment cleanup, not a security delta.
* fix(security): switch jsonschema2pojo-core from <optional> to <scope>provided</scope>
Semantically more correct for a build-time-only dep. The annotator classes
(PasswordAnnotator, MaskedAnnotator, etc.) are invoked only by
jsonschema2pojo-maven-plugin at code-gen time in its own classloader; the
runtime classpath of any deployed service never needs jsonschema2pojo-core.
<scope>provided</scope> says exactly that:
- on compile + test classpath (so annotators compile)
- excluded from runtime / dist packaging by default
- not propagated to downstream consumers
Same scanner outcome as <optional>true</optional> — Jackson 3.x JARs still
don't ship in the dist — but cleaner expression of intent. CVE coverage
unchanged: GHSA-2m67-wjpj-xhg9, CVE-2026-29062, GHSA-72hv-8253-57qq.
Verified:
mvn -pl openmetadata-spec -am install -DskipTests → BUILD SUCCESS
mvn -pl openmetadata-service dependency:tree -Dincludes='tools.jackson.core:*,org.jsonschema2pojo:*' → empty
* fix(security): switch netty-epoll exclusion from dep-mgmt to per-direct-dep
Per Copilot review on PR #28010: the previous parent-pom dep-management entry
for azure-core-http-netty with <exclusion> on netty-transport-native-epoll
did work (verified via mvn dependency:tree — exclusion DOES propagate to
transitive resolution in dep-mgmt), but Copilot raised a concern that pinning
azure-core-http-netty to 1.16.4 would block future Azure SDK bumps if a newer
SDK requires a higher azure-core-http-netty.
Same refactor as already applied to ai-platform PR #669. Remove the parent
dep-mgmt entry; apply per-direct-dep <exclusions> on the 3 azure-* deps that
transitively bring azure-core-http-netty in openmetadata-service:
- azure-security-keyvault-secrets
- azure-identity
- azure-storage-blob
Exclusion now travels with whatever azure-core-http-netty version each SDK
chooses; SDK bumps are no longer blocked by a hardcoded version.
Verified: mvn -pl openmetadata-service dependency:tree -Dincludes='io.netty:netty-transport-native-epoll'
returns empty.
* fix(security): extend netty-epoll exclusion to azure-identity-extensions
Per gitar-bot review on PR #28010: add the netty-transport-native-epoll
<exclusion> to azure-identity-extensions for consistency with the 3 other
azure-* direct deps in openmetadata-service/pom.xml that already have it
(azure-security-keyvault-secrets, azure-identity, azure-storage-blob).
Defensive: today's resolution is already clean because Maven's
nearest-definition rule picks the directly-declared azure-identity:1.15.2
(with our exclusion) over the transitive azure-identity:1.7.1 brought by
azure-identity-extensions:1.0.0. Adding the exclusion here protects against
a future refactor that removes the direct azure-identity declaration.
Verified: mvn -pl openmetadata-service dependency:tree -Dincludes='io.netty:netty-transport-native-epoll'
still returns empty.
---------
Co-authored-by: Shailesh Parmar <shailesh.parmar.webdev@gmail.com>
|
||
|---|---|---|
| .. | ||
| src | ||
| lombok.config | ||
| pom.xml | ||