[GHSA-274v-mgcv-cm8j] Argo CD GitOps Engine does not scrub secret values from patch errors #5689
Conversation
|
Hi there @jannfis! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository. This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory |
github-actions
bot
changed the base branch from
main
to
kbsteere/advisory-improvement-5689
|
Hi @kbsteere, thank you for bringing this to our attention. Unfortunately, there is no good solution to this issue. While, yes, the pseudo-version, Since Go pseudo-versions don’t indicate their originating branch, it can appear that these affected version ranges overlap. For scanners or consumers to interpret these correctly, they’d need to resolve which branch a given commit belongs to in the upstream repository. So, if we updated the advisory with the correct pseudo-version ranges, we do not believe it would fix your scanner problem. As scanners are likely to primarily use the timestamp portion for ordering of the versions, we could choose to select the version with the earliest timestamp but that would mean that some affected version would not be detect. Similarly, if we chose to use the latest timestamp version, people who are not affected will receive alerts. @jannfis what do you think is the best solution? |
The https://github.com/argoproj/gitops-engine/branches/all is in a tricky situration w.r.t. version ranges for this vulnerability. release-0.7 branch is obsolete and has the last tagged releases of 0.7.1, 0.7.2, 0.7.3. Active development branches started off 0.7.0 and branch to master ans argo-cd specific version stream. All of them use 0.7.1-DATE-COMMIT pseudoversions. Document that v0.7.1, v0.7.2, v0.7.3 tags are vulnerable. Document that v0.7.1-DATE-COMMIT pseudoversions are vulnerable up to the 2025-01-29 pseudoversion, as that is higher than all obsolete (unmaintained & vulnerable) and matches the just before commit that resolves this CVE in all the remediated branches and all future branches off master. The webform didn't let me construct such version constraints, thus please ensure this is manually verified to be a valid syntax to capture that v0.7.1, v0.7.2, v0.7.3 tags are vulnerable, and that within pseudoversions between v0.7.1 and v0.7.2 there is an affected range of when CVE got remediated across all branches. The approach here tries to use the pseudoversions, and the fact that unremediated branches are stale way prior to 2025-01-29, and that remediation was cherrypicked on the same date with the same commit date, but different git hashes. Thus using pseudoversions to declare a very tight pseudoversion range without any commit from any branch being missdetected as either false positive or false negative. Also see: - github#5689 - github#5721 - argoproj/gitops-engine#736 - golang/vulndb#3760
|
@JonathanLEvans I agree with your assessment though I think some scanners handle this correctly it definitely wouldn't be consistent. I think the correct way to resolve this is to generate tags a new versions of v0.7.4 and update the go.mod in each of those versions to reference the new version. This way it's very clear that any version <= 0.7.3 is vulnerable which means that all scanners work correctly and there is a clear fixed version in 0.7.4. @jannfis my colleague also posted a proposed solution the versioning, argoproj/gitops-engine#736 , though I think it would have to be standard semantic versioning since I think golang would truncate the last digit which would in affect be v0.7.4 as I stated above. |
|
I am updating the advisory the solution from here that hopefully will work for everyone. |
advisory-database
bot
merged commit 52db7b5
into
kbsteere/advisory-improvement-5689
|
Hi @kbsteere! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future! |
Updates
Comments
Details in vulnerability are causing confusion and false positives with scanners. Updated information to be specific about what is affected and fixed and provided commits for each version that has been addressed.