-
-
Notifications
You must be signed in to change notification settings - Fork 615
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
G307: gosec starts detecting G307 (CWE-703) even with proposed way to safely handle errors #714
Comments
This looks like a possible false positives, at least until we learn more at securego/gosec#714 Addressing: [/github/workspace/examples/falcon_sensor_download/main.go:104-108] - G307 (CWE-703): Deferring unsafe method "Close" on type "*os.File" (Confidence: HIGH, Severity: MEDIUM) 103: } > 104: defer func() { > 105: if err := file.Close(); err != nil { > 106: fmt.Fprintf(os.Stderr, "Error closing file: %s\n", err) > 107: } > 108: }() 109:
This looks like a possible false positives, at least until we learn more at securego/gosec#714 Addressing: [/github/workspace/examples/falcon_sensor_download/main.go:104-108] - G307 (CWE-703): Deferring unsafe method "Close" on type "*os.File" (Confidence: HIGH, Severity: MEDIUM) 103: } > 104: defer func() { > 105: if err := file.Close(); err != nil { > 106: fmt.Fprintf(os.Stderr, "Error closing file: %s\n", err) > 107: } > 108: }() 109:
This looks like a possible false positives, at least until we learn more at securego/gosec#714 Addressing: [/github/workspace/examples/falcon_sensor_download/main.go:104-108] - G307 (CWE-703): Deferring unsafe method "Close" on type "*os.File" (Confidence: HIGH, Severity: MEDIUM) 103: } > 104: defer func() { > 105: if err := file.Close(); err != nil { > 106: fmt.Fprintf(os.Stderr, "Error closing file: %s\n", err) > 107: } > 108: }() 109:
This looks like a possible false positives, at least until we learn more at securego/gosec#714 Addressing: [/github/workspace/examples/falcon_sensor_download/main.go:104-108] - G307 (CWE-703): Deferring unsafe method "Close" on type "*os.File" (Confidence: HIGH, Severity: MEDIUM) 103: } > 104: defer func() { > 105: if err := file.Close(); err != nil { > 106: fmt.Fprintf(os.Stderr, "Error closing file: %s\n", err) > 107: } > 108: }() 109:
Yes, after updating to Results:
[/Users/koddr/Code/Project/api/platform/cdn/digitalocean_spaces.go:67-72] - G307 (CWE-703): Deferring unsafe method "Close" on type "*os.File" (Confidence: HIGH, Severity: MEDIUM)
66: }
> 67: defer func() {
> 68: if errClose := file.Close(); errClose != nil {
> 69: log.Fatal(errClose.Error())
> 70: return
> 71: }
> 72: }()
73:
Summary:
Gosec : 2.9.1
Files : 29
Lines : 2756
Nosec : 0
Issues : 1 Out of the Version: 2.9.1
Git tag: v2.9.1
Build date: 2021-10-15T09:00:44Z Flag My system: |
Currently gosec is throwing warnings for any defer statement that closes a file (even if the error is handled) due to a bug. Once securego/gosec#714 is fixed and a release has been made this patch can be reverted. Signed-off-by: Sam Whited <sam@samwhited.com>
Currently gosec is throwing warnings for any defer statement that closes a file (even if the error is handled) due to a bug. Once securego/gosec#714 is fixed and a release has been made this patch can be reverted. Signed-off-by: Sam Whited <sam@samwhited.com>
This is how I typically open and close files. It gets flagged even though I thought it was idiomatic. However I am new to Go, so I'm open to being told this is poor coding style.
The More details:
Example source:
Result:
|
I am seeing this as well. I would expect a defer func() to pass gosec without issue, because I am checking the error. This was working before, not sure what version.
|
We hit the same issue, we use the Github Action with the
The error
|
This is not necessarily a false positive: https://www.joeshaw.org/dont-defer-close-on-writable-files/ Though |
The double defer pattern is mentioned in the update at the end of the post.
That's actually the article I learnt about the pattern from.
It is safe when close is idempotent. When code has multiple returns it is
easy to miss adding a close.
Also if you've already found an error, then call close, and get another
error, what should you do? Return both errors? Most code I've seen ignores
the close error in this scenario, and returns the first error.
…On Tue, 16 Nov 2021, 05:54 Piotr Lucinski, ***@***.***> wrote:
This is not necessarily a *false* positive:
https://www.joeshaw.org/dont-defer-close-on-writable-files/
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#714 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAFQFESI4SGMPLW3XWXU3UME3KTANCNFSM5GFRNOQQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Well, but calling just In that article, it's stated it's unclear/not stated in docs whether you actually should safely close the resource multiple times (and even if it's working now, I wouldn't rely on that).
I'd either combine/wrap them both or return only the first one but log any other at the same time. Anyway, I'd say this is not so good for the gosec to be that radical as people are now massively skipping the checks with |
@lootek It is stated in the docs. In fact the docs were specifically updated because of this pattern. See: golang/go#32427
|
thanks @xxgreg , didn't notice that! Then the double-close pattern is even worse ;) |
I guess I already mentioned this #661 (comment) |
@elgohr so essentially we always have to deal with a false positive, even when we're just reading a file or have handled syncing the file as suggested? |
My intention was to discuss this in the PR, before it got merged to avoid this false positive... Now it's merged - I have no idea |
To my point of view a solution would be to revert the change and start again with the initial PR (including the failing false-positive-test) |
Yeah that sounds like it'd be reasonable to me! 😄 |
@elgohr Please feel free to revert the pull request and to provide an updated solution. Thanks |
@elgohr I merged your pull request.
You can reopen it if you want to rework it. |
@ccojocar Please could we get a new release now the PR has been reverted? |
@danieljmt new version released https://github.com/securego/gosec/releases/tag/v2.9.3 |
…atements This is considered unsafe by gosec otherwise. [1] securego/gosec#512 [2] securego/gosec#714 [3] https://www.joeshaw.org/dont-defer-close-on-writable-files/
* Go: Bump github.com/securego/gosec/v2 from 2.14.0 to 2.15.0 Bumps [github.com/securego/gosec/v2](https://github.com/securego/gosec) from 2.14.0 to 2.15.0. - [Release notes](https://github.com/securego/gosec/releases) - [Changelog](https://github.com/securego/gosec/blob/master/.goreleaser.yml) - [Commits](securego/gosec@v2.14.0...v2.15.0) --- updated-dependencies: - dependency-name: github.com/securego/gosec/v2 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> * Make sure to handle error returned by io.Closer.Close() in 'defer' statements This is considered unsafe by gosec otherwise. [1] securego/gosec#512 [2] securego/gosec#714 [3] https://www.joeshaw.org/dont-defer-close-on-writable-files/ --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Armel Soro <asoro@redhat.com>
Summary
gosec v2.9.1 starts detecting
G307 (CWE-703): Deferring unsafe method "Close" on type "*os.File" (Confidence: HIGH, Severity: MEDIUM)
which could have been avoided by following #512 with previous version of gosec.Steps to reproduce the behavior
with v2.8.1
gosec version
Go version (output of 'go version')
Operating system / Environment
Expected behavior
No errors, or solve this error.
Actual behavior
gosec detects G307 (CWE-703).
The text was updated successfully, but these errors were encountered: