Improve GHSA-274v-mgcv-cm8j #5723
Conversation
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
github-actions
bot
changed the base branch from
main
to
xnox/advisory-improvement-5723
|
@JonathanLEvans @jannfis could you please review and test this? This should remove all false positives from all the remediated builds of argo-cd. |
|
Note if such ranges are not allowed, can also have this advisory to be between 0 and 0.7.1-date pseudo version as fixed. And create a different advisory stating that 0.7.2 & 0.7.3 are vulnerable. |
|
Great point about the shared timestamp. I don't want use a version with out the commit hash since it would not be a proper Go version. However, I can select the version with the lowest commit hash and it should avoid both false positives and negatives. So, the fix pseudo-versions are:
Does this work for you? |
Yes that works! and is very precise! |
|
@JonathanLEvans pushed an update here for your convenience, or recreate similar elsehow. Still don't know if two ranges like presented here will work, or if we need to split/clone this GHSA into a separate one to mark the ancient forks of 0.7.2 & 0.7.3 as vulnerable. |
advisory-database
bot
merged commit 6058272
into
github:xnox/advisory-improvement-5723
|
Hi @xnox! 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! |
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: