Dependency management for Netty tcNative is incomplete leading to possible version conflicts

[lfz757077613]

When I create an empty project with springboot2.5.10 and the netty-tcnative-boringssl-static of default version below, it show a version conflict.
I try to find where the 2.0.48 come from, but failed

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.5.10</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>
<dependencies>
    <dependency>
        <groupId>io.netty</groupId>
        <artifactId>netty-tcnative-boringssl-static</artifactId>
    </dependency>
</dependencies>

[snicoll]

Spring Boot does not provide full dependency management for tcnative, see #29816 (comment). 2.0.48.Final comes from what Netty manages in the netty-bom.

You can downgrade to that version by adding <tcnative.version>2.0.48.Final</tcnative.version> temporarily to your pom.xml.

[wilkinsona]

I think this illustrates the need for us to try to make our tcnative dependency management complete in 2.5 and 2.6. IIRC, we anticipated this as a possible problem when discussing #29816 but decided we'd address it if/when someone encountered a problem. I think this issue is just that so we should try to fix it.

[wilkinsona]

The problem appears in our own build with netty-tcnative-boringssl-static and netty-tcnative-classes having mismatched versions.

[patpatpat123]

Just wanted to point out netty-tcnative-classes-2.0.48.Final.jar has CVE-2019-20444

Description

HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that lacks a colon, which might be interpreted as a separate header with an incorrect syntax, or might be interpreted as an "invalid fold."
For more information check out https://lists.debian.org/debian-lts-announce/2020/09/msg00003.html

Currently having a project with SpringBoot 2.6.4 + Latest Jubilee, a run of DependecyCheck

dependency-check --noupdate --disableAssembly --disableCentral --project Checkers --format JSON --scan .

Will flag the project with above CVE-2019-20444

Hope this can help fix that!

[snicoll]

That CVE claims it is fixed as of Netty 4.1.44 and Spring Boot 2.6.4 uses 4.1.75 (#30227). I don't see the relationship with the issue above but, as always, if there is a CVE in a third party dependency that Spring Boot didn't manage to catch in time in the latest release, you can upgrade to is as described in the reference documentation. If you have more questions, please follow up on StackOverflow, as mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.

[patpatpat123]

Hello @snicoll,

Thank you for your comment, it is very helpful.
Also, I can confirm with my project,

Test A, project using 2.6.4, result: the CVE is there.

Test B, project using 2.6.5, no other change, just the one digit bump result: CVE fixed.

Thanks a lot Spring Team!