Reputation: 2621
We are currently facing a little conundrum with Spring Boot that's actually not a rare situation:
Spring Security OAuth2 Client has a critical vulnerability that our production systems might be vulnerable to; the vulnerability is fixed in the latest patch release of Spring Security. Naturally, we want to update our production systems ASAP, but this means we need to override the Spring Boot (Gradle) dependency management system if we don't want to wait until the next Spring Boot patch release.
I know that this can be done quite easily, in this case e.g. by setting something like this in gradle.properties
:
spring-security-oauth2-client.version=5.7.5
The problem with this is that this dependency is now pinned to a specific version; I need to remember to remove this property as soon as a Spring Boot patch release is available. This means extra coordination effort because we need to document this in our backlog, and even with good documentation on our part there is a risk that we forget to do it, which means the dependency will eventually be outdated - which is the exact opposite of what we wanted to achieve in the first place.
What I'd rather do is specify a minimum version of the dependency, that gets ignored if it is older than what the Spring Boot dependency management plugin's default version.
Can this be done? Or is there a better strategy to handle a situation like this?
Upvotes: 1
Views: 267
Reputation: 1190
This is possible using gradle's dynamic versions.
For instance, you can have:
dependencies {
implementation 'org.springframework.security:spring-security-oauth2-client:5.+'
}
But keep in mind that dynamic versions add nondeterminism to your build and can introduce unexpected behaviour changes to the system.
Using dynamic versions in a build bears the risk of potentially breaking it. As soon as a new version of the dependency is released that contains an incompatible API change your source code might stop compiling.
Upvotes: 1