Resolve open vulnerabilities in Conductor #3884
Conversation
|
@v1r3n here is another batch of CVE's resolved for you. |
| @@ -1,42 +1,42 @@ | |||
| { | |||
| "annotationProcessor": { | |||
| "org.springframework.boot:spring-boot-configuration-processor": { | |||
| "locked": "2.7.16" | |||
| "locked": "2.7.18" | |||
| } | |||
There was a problem hiding this comment.
Great job on these btw - but I have already been targetting these in #3855
As well as the entire upgrade to Spring 3.
We had to have a fork of Netflix Conductor - with Spring 3 ( literally the PR above - copy paste ) - and we are already using that in prod with no problem at all.
I think we should probably push for the change that will give us more bang for our buck, and will move Conductor further in the security space (as Spring 2 is EOL and new versions of libraries are no longer compatible with Spring 2)
There was a problem hiding this comment.
Thank you! Im definitely interested in those changes as well. My usage of Conductor requires that we maintain 0 CVEs at all times to remain compliant with very stringent security standards where we deploy it in production. For that reason I have had to make these fixes in our local mirror of the Conductor codebase and in the interest of trying to not diverge from the main branch I opened this PR. I’ll leave it up to you guys to decide what to do with it.
There was a problem hiding this comment.
I can't agree more with you - as we have the same requirements.
On saying that - Spring 2 has announced their end of life on the 24th of November, many libraries have started causing problems with newer versions ( all javax vs jakarta, etc ) - which means that we will have to migrate regardless, and that new versions with vulnerabilities will not be able to patched - making conductor unsafe software - in less than 1 year.
There was a problem hiding this comment.
We’re also in the process of moving everything over to Spring 3 for the same reason. One of the security requirements for us is we cannot use any EOL libraries. This also meant we had to completely delete the elastic search module from our mirror and turn off ES indexing. Even having the jar packaged but not used is unacceptable for some reason. The 6.x elasticsearch versions were EOL a year ago at this point. So really this PR was just a stop gap to allow us to continue to run Conductor in production. You have my full support for the Spring 3 work you have started on so thanks for that.
There was a problem hiding this comment.
IMO, we can make Conductor 3.15.x live on SpringBoot 2.x for a period of time, while making 3.16.x for SpringBoot 3..
Per my understanding, the SB 3 has breakage changes, so it need some time to stabilize the changes.
There was a problem hiding this comment.
No, I haven't looked into SB 3 yet. @LuisLainez
There was a problem hiding this comment.
@meggarr The PR has been open for some weeks now and it passes all tests - we have also had to fork from this branch an add to Atlassian services, because of vulnerabilities that require fixing (like Spring2 End Of Life) - and it's working fine in production for us. IMO I don't think we'll get a lot more signal on things that may not go as we expect until we release.
Pull Request type
[*] Build related changes (Please run ./gradlew generateLock saveLock to refresh dependencies)
Changes in this PR
Updates to resolve the following CVE's in Conductor