-
Notifications
You must be signed in to change notification settings - Fork 577
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
Less verbose logging in Golang Cataloger #904
Less verbose logging in Golang Cataloger #904
Conversation
Signed-off-by: Jonas Galvão Xavier <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @jonasagx — thanks for the attention to the log noisiness. I'm not sure about this particular change, and I've added a comment. Curious for your thoughts!
@@ -33,7 +33,7 @@ func scanFile(reader unionReader, filename string) ([]*debug.BuildInfo, []string | |||
for _, r := range readers { | |||
bi, err := buildinfo.Read(r) | |||
if err != nil { | |||
log.Warnf("golang cataloger: scanning file %s: %v", filename, err) | |||
log.Debugf("golang cataloger: scanning file %s: %v", filename, err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So my opinion is that this should be a WARN
log entry. If Syft knows for sure that it missed an opportunity to scan and surface a piece of the software, that's noteworthy (the same idea that's culminated in #518). For example, it might be that the scanned Go binaries has no known vulnerabilities... except in the section that Syft missed. It's important to have a way to signal to the user the difference between "Everything is fine ✅ " and "Everything that we scanned is fine, but we weren't able to scan everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If Syft knows for sure that it missed an opportunity to scan and surface a piece of the software, that's noteworthy (the same idea that's culminated in #518). For example, it might be that the scanned Go binaries has no known vulnerabilities... except in the section that Syft missed. It's important to have a way to signal to the user the difference between "Everything is fine ✅ " and "Everything that we scanned is fine, but we weren't able to scan everything.
⚠️ "
100% agree.
However, in this case this is a little bit grey. The golang cataloger selects candidate files based on MIME type (get all executables). There is no distinction of the binary being analyzed being a go-compiled binary (we don't know if it should be). Defaulting to warning here seems wrong since it seems to imply that we were expecting that all inputs are go-compiled binaries (which is not true).
That being said, I also agree that we don't want to not report up skipping a file that was intended to be analyzed by the golang cataloger but was not. We should show warnings for these cases.
Given the above context, we should probably default to having this being a debug
(though it does really seem like it should be warning at a first glance).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could check the error? If it is a "not a go executable" error, ignore it (no log) but any other error we show as a warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, in this case this is a little bit grey. The golang cataloger selects candidate files based on MIME type (get all executables). There is no distinction of the binary being analyzed being a go-compiled binary (we don't know if it should be). Defaulting to warning here seems wrong since it seems to imply that we were expecting that all inputs are go-compiled binaries (which is not true).
That being said, I also agree that we don't want to not report up skipping a file that was intended to be analyzed by the golang cataloger but was not. We should show warnings for these cases.
This part resonates! I hesitate to default to debug
regardless — but I do like the idea of distinguishing between two scenarios here. Your last suggestion makes a lot of sense to me! 🙌
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of debug not a go executable
and warn on any other error. My design north here is: how would things look like once we add more binary catalogers? In this future scenario log messages of the type not a X executable
are more noise than information, but we are not there yet.
Signed-off-by: Jonas Galvão Xavier <[email protected]>
|
||
// errNotGoExe is returned when a given executable file is valid but does | ||
// not contain Go build information. | ||
errNotGoExe = errors.New("not a Go executable") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this will work since this is a different error instance than the actual error being raised. Does the stdlib expose this error to use directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed a change 22bd9fc that makes the behavior consistent with #904 (comment) (warn only when there is an error and it is not from a "not go executable" error... so removed the debug case).
Since the stdlib does not export this error variable we cannot use it with errors.Is
or errors.As
(any error will match). The check I put in is brittle, but functional.
Based on an earlier discussion, it sounds like this might be better suited as data exported by Syft instead of any sort of log warnings at all? |
My thinking is that one solution doesn't negate the value of the other. For now, logged warnings are a nice short-term achievement, consistent with much of the other cataloging code. |
Signed-off-by: Alex Goodman <[email protected]>
9d26515
to
22bd9fc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
// binary, we should not show warnings/logs in this case. | ||
return nil, nil | ||
} | ||
// in this case we could not read the or parse the file, but not explicitly because it is not a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but not explicitly because it is not a go-compiled binary (though it still might be)
nit: this phrasing is just a little difficult to parse, I think because of having "but not ... not ... though ...". If we can think of a more direct way to say this, I think that'd help (still thinking 🤔 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something like "We don't know if this is a Go binary, but we weren't able to read it, so we should alert the user."?
(I'm still making sure I understand the intent of this comment, so let me know if I'm off-base!)
* Less verbose logging in Golang Cataloger Signed-off-by: Jonas Galvão Xavier <[email protected]> * debug for known gray errors Signed-off-by: Jonas Galvão Xavier <[email protected]> * only show warnings when a binary is not a go executable Signed-off-by: Alex Goodman <[email protected]> Co-authored-by: Alex Goodman <[email protected]>
Before
After
Signed-off-by: Jonas Galvão Xavier [email protected]