This message was deleted.

In case it matters, this is with Gradle 8.1.1

IIRC, you need to give Gradle some valid version to resolve to. It can't just infer what next version to use. Trust me, I wish it could.

You want something like the below; simply rejecting invalid versions won’t do it.

classpath("org.apache.logging.log4j:log4j-core") {
                version {
                    strictly("[2.17.2, 3[")
                    prefer("2.17.2")
                }
                because("CVE-2021-44228: Log4j vulnerable to remote code execution")
            }

yes, two dimensions here: actually constraining to expected versions, separately from how dependabot ‘guesses’ at what versions are actually in use.

Yes. But fixing the constraint problem, for this exact use case, with Gradle was one of the things I wanted to fix while I was at Gradle. But I'm not there anymore

I thought the dependencies of my dependencies were effectively "requires". For example, I believe

com.expediagroup:graphql-kotlin-server:6.5.3

(transitively) depends on

com.graphql-java:graphql-java:20.3

, which I thought was the same as requiring 20.3 or greater.

no. it’s a suggestion at best. through constraints, conflict resolution, other transitive dependencies, metadata rules, etc Gradle will pick a version to use, which may differ from the starting point.

However, the set of "valid" versions that can actually be picked from, IIRC, will only come from the pool of versions that have been explicitly declared as being present by either a direct dependency, or a transitive. It won't look outside that set

or a constraint that specifies a version range / prefers.

@Louis Jacomet or @Daz DeBoer would be good resources here

This works:

version {
                    strictly("[2.17.2, 3[")
                    prefer("2.17.2")
                }

Does it? I thought it had to be a

require

to work properly. Glad to see that

prefer

is an option

the strictly bounds the range, within that prefer selects a version (well, as a starting point - if other deps say used 2.17.3 that would override)

Does "prefer" say to not add the dependency if nothing else is asking for it?

the constraint won’t kick in if nothing is using those coordinates.

Ok, I've changed my constraints to:

constraints {
    api("com.graphql-java:graphql-java") {
        version {
            strictly("[20.4,)")
            prefer("20.4")
        }
        because("CVE-2023-2976")
    }
}

and this seems to work!

I should probably go update that proposal to use the same strategy as the Log4Shell solution