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

reduce logging severity for non-Go binaries #983

Merged
merged 1 commit into from May 3, 2022

Conversation

luhring
Copy link
Contributor

@luhring luhring commented May 3, 2022

This is intended to be a temporary fix to the problem of excessive WARN logging when the Go binary cataloger encounters a non-Go binary.

Examples of noisy logging:

[0011]  WARN golang cataloger: failed to read buildinfo (file="/usr/lib/python3.9/site-packages/orjson.libs/libgcc_s-eedded4b.so.1"): EOF
[0012]  WARN golang cataloger: failed to read buildinfo (file=".vscode-test/vscode-1.48.1/Visual Studio Code.app/Contents/Resources/app/out/vs/platform/files/node/watcher/win32/CodeHelper.exe"): unrecognized file format

It should be noted that this change reduces the prominence of legitimate issues parsing real Go binaries. But from my experience, those cases seem to be in the minority, and what's been happening more often is that we're hitting non-Go binaries and then printing warnings to the user, when ideally we wouldn't be.

Fixes #978

Signed-off-by: Dan Luhring <dan+github@luhrings.com>
// But right now it's catching too many cases where the reader IS NOT a Go binary at all.
// It'd be great to see how we can get those cases to be detected and handled above before we get to
// this point in execution.
log.Infof("golang cataloger: unable to read buildinfo (file=%q): %v", filename, err)
Copy link
Contributor

Choose a reason for hiding this comment

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

@luhring just so I'm clear - you still think this should show up in its current state when a user passes -v?

Any consideration for going down to debug for -vv because of how many cases are being caught?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good question. I think this is a notable occurrence, so my personal opinion would be to have it show up w/ -v. I also think that ideally we move this back to WARN (so it shows up even without -v) — but only once we've solved the issue if this conditional branch being hit more correctly and less often.

I don't have a strong opinion on this, though. I see this as a temporary solution. I defer to you on this!

@spiffcs spiffcs changed the title Reduce logging severity for non-Go binaries reduce logging severity for non-Go binaries May 3, 2022
@spiffcs spiffcs merged commit 37927b8 into anchore:main May 3, 2022
@luhring luhring deleted the go-bin-logging-reduction branch May 3, 2022 13:40
rigzba21 pushed a commit to rigzba21/syft that referenced this pull request May 5, 2022
Signed-off-by: rigzba21 <jonathan.velando01@gmail.com>
spiffcs added a commit that referenced this pull request May 6, 2022
* main:
  feat: add initial dotnet-support (#951)
  unblock timeout for power-user select CLI tests (#985)
  golang cataloger - main module version as is (#986)
  Fix `github-json` output option (#967)
  read Go main module version as is - (devel) (#981)
  reduce logging severity for non-Go binaries (#983)
  golang.org/x/crypto upgrade (#979)
GijsCalis pushed a commit to GijsCalis/syft that referenced this pull request Feb 19, 2024
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.

WARN golang cataloger: failed to read buildinfo
2 participants