In Go 1.16 or higher, the `io/ioutil` has been deprecated and the
`ioutil.ReadFile` function now calls `os.ReadFile`.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* Add G307 sample code.
The sample should reflect a defered close that leads to data loss.
Due to IDE auto-complete people tend at least log errors, but not
really care about handling.
* Add more G307 sample code. Propose a way to implement
* Remove unused code. Add example that should not return an error but does
* Remove test for synced closed file for now.
Will add this later
Co-authored-by: Cosmin Cojocar <cosmin.cojocar@gmx.ch>
* fix: add variable assignment checking as part of MinVersion
* fix: add more code to allow assignment with const
* fix: rework the code and add more test cases for MinVersion
* fix: format linting issue using gofumpt
Both MinVersion and MaxVersion of crypto/tls.Config are uint16, so the
int16 fields of rules.insecureConfigTLS are too small. GetInt()
interprets integer literals as fitting within 64-bits, so simplify
things by using int64.
In go 1.16 the `ioutil` package was deprecated and
the functions should be replaced by their equivalents
in either `io` or `os` packages. This means,
that `ioutil.WriteFile` should be replaced by
`os.WriteFile` instead. To account for this change
and to detect incorrect permissions also for `os.WriteFile`
I changed `filePermissions` rule slightly to allows
specifying multiple packages that can contain given
function and that we should check. This workaround
can be removed after a sufficient time has passed
and after it is decided that checking `os.WriteFile`
is enough.
Fixes: https://github.com/securego/gosec/issues/576
Made also the rule to not report an issue when encountering function
scoped variable which terminate in a basic literal such as a string.
Signed-off-by: Cosmin Cojocar <cosmin.cojocar@gmx.ch>
Currently, rule G204 warns you about every single use of the
functions syscall.Exec, os.exec.CommandContext and os.Exec.Command.
This can create false positives and it's not accurate because you can
use those functions with perfectly secure arguments like hardcoded
strings for example.
With this change, G204 will warn you in 3 cases when passing arguments
to a function which starts a new process the arguments:
1) are variables initialized by calling another function
2) are functions
3) are command-line arguments or environmental variables
Closes: https://github.com/securego/gosec/issues/338
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
The big#Int.Exp used to be vulnerable in older versions of Go, but in the
meantime has been fixed (https://github.com/golang/go/issues/15184).
Signed-off-by: Cosmin Cojocar <cosmin.cojocar@gmx.ch>
