Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get go stdlib version from go.mod #704

Merged
merged 6 commits into from
Dec 27, 2023
Merged

Conversation

hogo6002
Copy link
Contributor

Fix #679

@codecov-commenter
Copy link

codecov-commenter commented Dec 11, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (439e5c5) 78.62% compared to head (4e5d209) 78.70%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #704      +/-   ##
==========================================
+ Coverage   78.62%   78.70%   +0.07%     
==========================================
  Files          85       84       -1     
  Lines        6055     6047       -8     
==========================================
- Hits         4761     4759       -2     
+ Misses       1088     1085       -3     
+ Partials      206      203       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@another-rex another-rex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@hogo6002 hogo6002 enabled auto-merge (squash) December 27, 2023 05:27
@hogo6002 hogo6002 merged commit dd30864 into google:main Dec 27, 2023
11 checks passed
another-rex added a commit that referenced this pull request Jan 10, 2024
While the change made in #704 is the ideal solution, it only works for
people using go 1.21 or later. Adding a patch version to go.mod will
cause go1.20 or earlier to fail to build. Since 1.20 is still fully
supported and is still the default version for many workflows, this
causes too many breakages for users to be acceptable.

There's a few alternative fixes:  

- Assume latest patch version (This PR)
- This means osv-scanner is no longer checking whether a project is
updating to the latest patch version to resolve vulnerabilities, but
will still catch users using an out of support go minor version that has
no patch available.
- Remove stdlib vulnerability check entirely / move stdlib vuln check
behind a experimental flag
- Add a way to hint to osv-scanner the go version (e.g. .go-version
file, or a comment in the go.mod file specifically for osv-scanner to
check).

I am leaning towards assuming the latest patch as a fix in the mean time
until go1.22 releases (at which point 1.20 will no longer be supported),
and less people will be using 1.20, and perhaps reintroducing the patch
version check.

---

This implementation also means when a stdlib vulnerability is found, the
version that is printed will be 1.xx.99, which is not quite accurate.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

golang stdlib scan inconsistency for fresh go toolchain versions: bare metal vs docker
5 participants