Hi. Snyk has revealed that some deeply nested tran...
# dependency-management
r
Hi. Snyk has revealed that some deeply nested transitive dependencies have CVEs against them. I'd like to specify that gradle choose the greater of the first version without the CVE and whatever version would otherwise be brought in transitively. Is that possible?
j
The dependency constraints API can be used to do something like this
r
To clarify: Current situation:
implementation('a:1.0.0')
brings in b:1.2.3 which has a CVE fixed in b:1.2.12. I would like gradle to use b:1.2.12 Future situation: I upgrade a to 1.1.0 which now brings in b:1.4.1 I would like gradle to use b:1.4.1 Further future situation: I upgrade a to 2.0.0 which now brings in b:2.1.1 I would like gradle to use b:2.1.1 I do not want to have to manage the version of b beyond stating that it must be at least 1.2.12 At present I am using this:
Copy code
dependencies {
  constraints {
    implementation('b:[1.2.12,)') {
      because 'version 12.3 brought in transitively by a:1.0.0 has CVE-2023-XXX'
    }
  }
}
however, that upgrades me immediately to b:2.4.5, and I have no idea if that works with a:1.0.0 I can fix that by using
b:[1.2.12,2.0[
, but I still immediately get upgraded to b:1.7.8, and I don't know if I trust
b
to do semver properly. And if a future version of a needs b:2.x I now need to spot that and fix up my constraint.
v
You almost got it
Just don't use a range
Just say
b:1.2.12
As long as you do not use a strict version, it is just a "requires" like a normal version
r
And then it will lose out to a greater version in another transitive dep?
v
Just without adding the actual dependency, so just upgrading a transitive version if not a newer one is used
r
Thanks so much, the term "constraint" made me think I was fixing the version. Overthinking it.
👌 1
v
Yes, it is like you would have it outside
constraint { ... }
resolution wise
The only difference is, that you do not add the dependency if it is not brought in somehow else
🙏 1