Repository navigation
Conversation
Collaborator
|
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
xnox/advisory-improvement-5721
June 13, 2025 12:47
This was referenced Jun 13, 2025
Author
|
Let me propose an alternative. |
xnox
added a commit
to xnox/advisory-database
that referenced
this pull request
Jun 13, 2025
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updates
Comments
The module versions for last broken & first fixed do not match the commit that has fixed this vulnerability.
I did
go getof both commit that fixed this vulnerability, and the one just before.Currently due to this incorrect version data Snyk and Twistlock scanners detect all builds of the project as vulnerable, when it was fixed.
Also see: