Comment From: msmsimondean

As I've flagged in https://github.com/spring-projects/spring-boot/issues/26031#issue-856157193, Netty 4.1.63.Final fixes a medium severity vulnerability in Netty. Sorry to ask, but do you if there's a timescale for releasing this vulnerability fix for Spring Boot? Thanks!

Comment From: wilkinsona

All release dates are available on the milestone page and 2.4.5 is currently scheduled for 15 April.

Please note, however, that you don't need a Spring Boot release to use Netty 4.1.63. You can use Spring Boot 2.4.4 and the netty.version property in your pom.xml or build.gradle file to override the version of Netty that's used.

Comment From: msmsimondean

Thanks @wilkinsona for the milestone info and technique. I think setting a netty.version property works for Maven but not Gradle. I'm using Gradle and I don't think it has the same concept (not really). I think I'd need to explicity override the version of the relevant Netty dependencies, either with a line per dependency or with some slightly fancy Gradle config/code.

Comment From: msmsimondean

@wilkinsona the following removed the vulnerability for me with a Gradle build. Would it be worth adding a note to the new issue template to say that security vulnerabilities in dependencies can be temporarily resolved by overriding the version(s) that Spring Boot brings in? Thanks

// TODO: This code block should be removed after upgrading Spring Boot to a version higher than 2.4.4
configurations.all {
    resolutionStrategy.eachDependency { DependencyResolveDetails details ->
        def vulnerableNettyVersion = '4.1.60.Final'

        if (details.requested.group == 'io.netty' && details.requested.version == vulnerableNettyVersion) {
            details.useVersion  '4.1.63.Final'
            details.because "Netty $vulnerableNettyVersion contains vulnerability https://github.com/netty/netty/security/advisories/GHSA-f256-j965-7f32"
        }
    }
}

Comment From: scottfrederick

I think setting a netty.version property works for Maven but not Gradle. I'm using Gradle and I don't think it has the same concept (not really).

Did the approach shown in the Gradle plugin documentation not work as expected in your case?

Comment From: msmsimondean

@scottfrederick that's the case, it didn't work. Thanks for your link! Based on that knowledge, I realise why the netty.version property approach didn't work (I did give it a go first) and actually couldn't work for me. I'm using Gradle's platform feature (see https://docs.gradle.org/current/userguide/platforms.html#sub:bom_import) rather than Spring's Dependency Management plugin for Gradle, and this is a feature specific to Spring's Dependency Management plugin for Gradle. I think the Gradle Platform feature was introduced in Gradle 5 (https://gradle.org/whats-new/gradle-5/).

There was a specific reason I had to switch from a) Spring's Dependency Management plugin for Gradle to b) Gradle's Platform feature. I think it was something to do with having both i) a Spring Boot based web service and ii) a Java libaray I needed to publish to Maven repo, in the same codebase. I couldn't get both Gradle projects/modules working in the same codebase, both using Spring's Dependency Management plugin for Gradle. Whereas it worked perfectly with Gradle's Platform feature. I've found no issues using Gradle's built-in platform feature. Gradle bill it as Platform definitions, aka Maven BOM dependencies are natively supported, allowing importing things like the Spring Boot platform definition without using an external plugin (https://gradle.org/whats-new/gradle-5/). I presume more people will use Gradle's platform feature going forward? Thanks!

Comment From: msmsimondean

An advantage of the Gradle block I've put above is that it only takes affect when Spring Boot tries to pull in Netty version 4.1.60.Final. As soon as you upgrade Spring Boot, the code block no longer takes effect, as the if statement won't evaluate to true. The obvious disadvantage is that it's a huge block of Groovy code...

Comment From: msmsimondean

I think it was something to do with having both i) a Spring Boot based web service and ii) a Java libaray I needed to publish to Maven repo, in the same codebase. I couldn't get both Gradle projects/modules working in the same codebase, both using Spring's Dependency Management plugin for Gradle. Whereas it worked perfectly with Gradle's Platform feature.

I remember more details now. When I used the Spring Dependency Management plugin with my Gradle module that is published as a JAR to a Maven repo, the pom.xml for the library had Spring dependencies with missing version numbers. The dependencies had a groupId and an artifactId but no version.