OpenMetadata/common/pom.xml
sonika-shah 6c30d82f4c
fix(security): pin libthrift, provided jsonschema2pojo, bump azure-kv/sjm/reactor-netty, exclude netty-epoll (#28010)
* 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>
2026-05-11 14:08:26 +05:30

158 lines
5.2 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<!--
~ Copyright 2021 Collate
~ Licensed under the Apache License, Version 2.0 (the "License");
~ you may not use this file except in compliance with the License.
~ You may obtain a copy of the License at
~ http://www.apache.org/licenses/LICENSE-2.0
~ Unless required by applicable law or agreed to in writing, software
~ distributed under the License is distributed on an "AS IS" BASIS,
~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
~ See the License for the specific language governing permissions and
~ limitations under the License.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>platform</artifactId>
<groupId>org.open-metadata</groupId>
<version>1.12.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<properties>
<dropwizard.swagger.version>2.1.4-1</dropwizard.swagger.version>
</properties>
<artifactId>common</artifactId>
<name>OpenMetadata Common</name>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<!-- Required dependency for @Slf4j annotation -->
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
</dependency>
<!--test dependencies-->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>${org.junit.jupiter.version}</version>
<scope>test</scope>
</dependency>
<!-- Build-time only (used by jsonschema2pojo-maven-plugin in openmetadata-spec).
<scope>provided</scope> keeps it on compile classpath but excludes it (and all
transitives — including Jackson 3.x: GHSA-2m67-wjpj-xhg9, CVE-2026-29062,
GHSA-72hv-8253-57qq) from runtime / dist packaging. -->
<dependency>
<groupId>org.jsonschema2pojo</groupId>
<artifactId>jsonschema2pojo-core</artifactId>
<version>${jsonschema2pojo.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.18.0</version>
</dependency>
<dependency>
<groupId>io.dropwizard</groupId>
<artifactId>dropwizard-jersey</artifactId>
<version>${dropwizard.version}</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
</exclusion>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.17.1</version>
</dependency>
</dependencies>
<profiles>
<profile>
<id>release</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>${maven-source-plugin.version}</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>${maven-javadoc-plugin.version}</version>
<configuration>
<doclint>none</doclint>
</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
<configuration>
<gpgArguments>
<arg>--pinentry-mode</arg>
<arg>loopback</arg>
</gpgArguments>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<build>
<plugins>
<plugin>
<groupId>com.theoryinpractise</groupId>
<artifactId>googleformatter-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>