commons-configuration:1.10 has vulnerabilities:
https://mvnrepository.com/artifact/commons-configuration/commons-configuration/1.10
to fix the issue upgrade to commons-configuration2:2.12.0
@OlgaMaciaszek
Comment From: OlgaMaciaszek
Hello @ziad-saade, this is a transitive dependency not governed by our project, but brought about by Netflix/Eureka, which is an external project, not maintained by us. Switching to commons-configuration2 conflicts with the [Netflix/Eureka]https://github.com/Netflix/archaius project which is used internally by Netflix/Eureka. Please create an issue in both of those projects and link here to track when it's done.
Comment From: ph33rtehgd
I think we'll have a bit of a problem with Netflix/Eureka in this case, but feel free to correct me if I'm wrong. The way I see the current state of things is like this:
- Spring Netflix relies on Eureka 2.x
- Eureka 2.x, according to its own Wiki, is discontinued and no longer updated. By the looks of it there have been small dependency upgrades and patches accepted over the past few years, but by and large it doesn't appear to be getting substantial updates
EDIT: Removed a bunch of talk about Archaius as I just noticed that the Spring project excludes it, so that's not directly relevant. More thoughts incoming but wanted to remove all of this to not muddy discussion.
Comment From: ph33rtehgd
TLDR: I think we can simply exclude commons-configuration without any ill-effects. This is likely the simplest solution to this issue. Read on to see how I arrived at this conclusion.
I was doing a bit more digging to try and approach this from a slightly different angle as I didn't see any easy way to resolve this issue given that most of the libraries involved are either EOL or barely maintained. I wondered if I could just exclude commons-configuration (and by extension, commons-lang) without any negative repercussions. I did a quick test in my own development environment and removed both commons-configuration and commons-lang from my eureka server and a client app and noticed no apparent issues in starting or operating either service. This was a promising start.
This got me digging further to try and verify if these libraries were being used in some path of the library that may not be immediately be noticable. While doing this I noticed that Spring Netflix specifically excludes Archaius. This effectively means that any piece of the Netflix Eureka library which relies on Archiaus isn't currently being used by Spring Netflix (otherwise you'd hit issues with missing classes). Since Archaius is the primary reason for needing commons-configuration, I went on to see if any Eureka library requires a class from commons-configuration directly. The only class in the 2.x branch that uses commons-configuration is PropertiesInstanceConfig, however Spring Netflix does not seem to use this class at all (which makes sense because it relies on Archaius). Spring Netflix implements it's own EurekaInstanceConfig and EurekaClientConfig classes which side steps all of the classes in Netflix Eureka that rely on Archaius and commons-configuration.
@OlgaMaciaszek When you have time, could you review the above observations and see if you agree?
Comment From: ph33rtehgd
Apologies if I'm getting ahead of myself, but I created a PR to exclude commons-configuration: https://github.com/spring-cloud/spring-cloud-netflix/pull/4468
If this PR is accepted I think it should be merged back into 4.2.x and 4.3.x.