As a system admin, I want dependency (library, package, image, configuration) updates for security and bug fixes for WRES 6.25 #67
Comments
|
Proposed Library updates: |
|
After the changes: |
|
I was having a lot of trouble with the vulnerability scan.. I added the token to my jeremylong/DependencyCheck#6816 (comment) Increasing the |
|
Vulnerability Scan: |
|
Redhat upgraded to |
|
Redis upgraded to |
|
RabbitMQ upgraded to |
|
ActiveMQ upgraded to |
ArvinEsmailzadeh
added a commit
that referenced
this issue
Aug 20, 2024
fixes #67 Dependency and dockerfile upgrades for deployment
|
Arvin, I think there are at least two mistakes in recent commits. First, you have not upgraded artemis consistently. The |
|
I completely missed taking out the API key... oops.. and Artemis upgraded it on the Docker files but missed it in gradle. Let me fix these. Sorry about that. |
|
New Library updates: |
|
New vulnerability scanner: |
|
Another thing, Arvin. I see you reported the vulnerability scan above, but I cannot see any follow up. When performing a scan, it needs to be followed up so that each reported CVE is either explained as will not fix (e.g., a false positive), cannot fix (e.g., no fix available) or it needs to be fixed. |
|
Also, the build is in an endlessly looped/failing state because you have not checked whether the upgrade to Artemis 2.36 actually works locally before pushing. You should not push without the build succeeding locally. Apparently, the upgrade to Artemis 2.36 does not work, which is not very surprising because the upgrade to 2.35 also did not work. I think you will need to cancel the build and back out this upgrade to Artemis 2.36. |
|
I have cancelled the failing workflows. |
|
I have unchecked the items that need to be repeated. |
|
James, We have a bit of a problem regarding Artemis in the Dockerfile. So the place we are pulling it from no longer has version So we currently have 2 options.
Arvin |
Thanks. Note that (1) is not an option because, when you deploy to cowres, it will break in exactly the same way it breaks the wres build. It's just that we don't exercise our docker deployment until the software has been deployed on a cowres machine. The only difference between the core artifact and the cowres deployment w/r to Artemis is where and how the broker is started. For the cowres deployment, a broker instance is started separately. For the core software, a broker instance is started by the core software and embedded within the same process. Otherwise, there is no difference, so the problem exists either way. |
|
I think these are the two options:
|
|
Let me start with (1) to see whether it can be addressed reasonably quickly, but I reserve the option of (2) if it isn't a quick-ish fix. Option (2) will require a temporary update to the broker dockerfile to pull from the archive space. |
|
Sounds good, James. Thank you! Arvin |
|
Fixed #69 and merged the PR. You should be able to proceed by merging master into your branch and then addressing the CVEs. I retained the updated Artemis in the dockerfile and now in the core artifact too, so that step is done. |
|
Awesome so before I move forward with the rest of the deployment, the CVE's need to be addressed. So let me start taking a look. Arvin |
|
Ok so here are the CVEs All of them besides the two below were there previously and are known about and cannot be fixed as of right now. jfreechart vulns are disputed and no update available. https://nvd.nist.gov/vuln/detail/CVE-2023-52070 Let me try to find the jodd ones. |
I think they are mostly the same as earlier releases, either false positives or disputed or no updates. But these ones look new: I mean, new to us. They are not new CVEs. Would check where these (presumably) transitive deps have suddenly been introduced from and then see if there are updates available... |
|
Updates to transitive deps require a slightly different approach, as you will see in our Note the two steps, first exclude, then include (later version). |
|
But first you need to discover where these jodd deps come from, what imports them. Gradle dependencyInsight or similar should help with that, or just create a full dependency graph and search for jodd to see what brings it in. |
|
Looks like its a transitive dependency of |
|
Not sure about that slanted line, I reckon it's a transitive dep of redisson only. Also, note that snakeyaml appears in a ton of places, so that dep would appear elsewhere in that case, not just the tasker... |
|
You're right I think the slanted line means last line of the transitive dependencies for the top level one. |
|
Looks like there are no version upgrades for Arvin |
|
|
Well, according to the CVE: https://nvd.nist.gov/vuln/detail/CVE-2022-29631 In other words, 5.* won't help, but there should be a 6.2.1 or higher that will... https://github.com/oblac/jodd-http The issue seems to be |
|
If core 5.3.0 brings in http 6.2.1 or later, I would go with that. |
|
Oh, but jodd bean too. So you will probably need to remove jodd http from redis and bring in the latest, 6.3.0... |
|
Oh, wait a second. I think these are false positives. There is no dependency of beans or core on http, right? So this is just the checking tool getting confused with jodd deps that have version < 6.21. In other words, a false positive. I would double check to see whether that has been reported to the checking tool devs, but it's probably a fp... edit: in other words, we have no dependency or transitive dependency on jodd-http, but the checking tool sees other jodd dependencies with versions < 6.21 and gets confused, throwing a fp. The cve is exclusively about jodd http. |
|
So I just tried a bunch of different things just to see if I can get rid of the CVE so what I did was I excluded |
|
So in that case are we good to move on to the next steps of deployment? |
|
As long as our dependency graph shows no dependency on jodd http, then there is no issue. Please confirm that our dependency graph does not show jodd http. As above, I think it's a false positive whereby the owasp dependency check tool is being triggered on any jodd dependency < 6.21, even though the cve is for jod http only (and we appear not to depend on it). |
|
James, I confirmed that we do not have jodd http in our dependency tree. Arvin |
|
Good to go, then. |
|
Remember to remove the api key from the |
ArvinEsmailzadeh
added a commit
that referenced
this issue
Aug 21, 2024
fixes #67 Fixed dependency upgrades
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: