Patching Vulns

[FlawzyByte]

1/ Patched vuln num: GHSA-vmq6-5m68-f53m
Solution: Upgrading logback from 1.4.11 to 1.4.12

[FlawzyByte]

Vuln num: GHSA-pr98-23f8-jwxv
GHSA-6v67-2wr5-gvf4
GHSA-qqpg-mvqg-649v
combined require logback to be set to 1.5.25 atleast.

[FlawzyByte]

Through upgrading Logback to 1.5.25 and Vert.x to 4.5.27, which also brings transitive Netty to 4.1.133.Final and Jackson Core to 2.18.6, resolving the flagged dependency CVEs.

[subhramit]

LGTM

[subhramit]

Since this is a patch, I'm wondering if we should bump this to 3.4.1 as well and re-use the property below (like it was being done before) instead of hardcoding differently at two places.
What do you think?
Why I'm not sure is if the initial engineers had the rationale that the apis-common and apis-bom version would be tied hand-in-hand, but there's a solid argument against it - because that would cause more coupled changes, in case we add more patches in future and bump it to a version for which apis-bom doesn't exist.

I say good to go.

[FlawzyByte]

I guess we should, to maintain consistency and coherence for next devs,
Otherwise, yes apis-common and apis-bom are tightly coupled because Maven’s version has merged rules for apis-common, supplies versions some deps rely on entirely, and defines the shared dependency contract the rest of the APIS stack expects.
We can separate them (creating isolation layers for further convience) by either dropping the BOM import or keep the BOM import at parent level (apis main maybe?)
Yeah, I'll be waiting on your answer x_x

[subhramit]

Hmm this brings the question why then APIS is not a monolith/monorepo... (if we are to couple versions so strongly)

[subhramit]

I say lets let this in - better to make progress rather than introduce more maintenance overhead.

[axmsoftware]

@FlawzyByte could you use properties for versions? For example:${project.version}
3.4.1
This looks like regression. Could we have one place to adjust versions of importance that need to be consistent between components and a pattern for the ones that stay fix and are only component specific? Thanks!

[FlawzyByte]

The original setup kept apis-common and the stack (apis-bom) on 3.0.0.
apis-bom 3.4.1 now manages apis-common as ${project.version} => 3.4.1; that BOM bump
(including Akarsh’s Nov 6, 2025 change)

hyphae/apis-bom@40a40a0
hyphae/apis-bom@0b31eee

wasn’t something the initial team had done
@AkarshSahlot Quick question on the Nov 6, 2025 BOM bump to 3.4.1: apis-bom now manages apis-common as ${project.version} => 3.4.1, while apis-common is still 3.0.0.
Was the intent to release apis-common to 3.4.1 too?

So this repo is still apis-common 3.0.0 while the BOM line assumes 3.4.1.

The simplest solution is to align and release apis-common 3.4.1 to maintain ${project.version} property approach.

[FlawzyByte]

Also dependabot has upgraded vertx to 5.0.7
hyphae/apis-bom@b435385
while I just patched this repo with 4.5.27 to mitigate vulnerabilities, should I upgrade it too?
thanks!