-
Notifications
You must be signed in to change notification settings - Fork 67
fix: trivy binary check fallback #1154
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
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 32 files with indirect coverage changes 🚀 New features to boost your workflow:
|
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.
LGTM thanks!
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.
Few comments
pkg/scanners/trivy/types.go
Outdated
|
||
// currentExecutingLookPath is a variable that points to exec.LookPath by default, | ||
// but can be overridden for testing purposes. | ||
var currentExecutingLookPath = exec.LookPath |
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.
It's a little weird to have this as a global variable here. Why not just use exec.LookPath
in the findTrivyExecutable
function?
Instead of overriding the lookup function for testing, why not create a t.TempDir()
, create some executable files in it, and maniuplate PATH
by using os.Setenv
?
|
||
cliArgs := s.config.cliArgs(refs[i]) | ||
cmd := exec.Command(trivyCommandName, cliArgs...) | ||
cmd := exec.Command(s.trivyPath, cliArgs...) // nolint:gosec // G204: Subprocess launched with variable |
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.
Can you make the initScanner
function create a symlink at /trivy
to the path where trivy was found? That way we don't have to disable a security lint.
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.
good point, this might be why we used /trivy
path instead of relying on PATH
. However, will this break read only root file system pod security?
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.
On second thought, we can change /trivy
to trivy
in the call to exec.Command
and it will be located in the PATH
automatically
Thanks to Mo for the fresh perspective :)
d122771
to
52c653d
Compare
Signed-off-by: Sertac Ozercan <[email protected]>
Signed-off-by: Sertac Ozercan <[email protected]>
Signed-off-by: Sertac Ozercan <[email protected]>
Signed-off-by: Sertac Ozercan <[email protected]>
Signed-off-by: Sertac Ozercan <[email protected]>
This reverts commit eebe5b9. Signed-off-by: Sertac Ozercan <[email protected]>
Signed-off-by: Sertac Ozercan <[email protected]>
What this PR does / why we need it:
This isn't something that affects the official builds from GHCR since container builds always copies trivy to
/trivy
.If the project is rebuilt and the binary is not placed in root dir, this causes issues since eraser expects trivy to be in root. This PR enables fallback to
PATH
. If not found inPATH
, it will provide an error.Which issue(s) this PR fixes (optional, using
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when the PR gets merged):Fixes #1149 #1150
Special notes for your reviewer: