icmd: replace all usages of os/exec with golang.org/x/sys/execabs #218
Conversation
thaJeztah
force-pushed
the
secure_exec
branch
2 times, most recently
from
0bc7e7e
to
762f31e
Compare
|
https://blog.golang.org/path-security is interesting! #219 should fix the test-windows job. This is marked as a draft, but it seems to be working. Anything left to do? |
Project now started to do releases; this one was related to a security issue on Windows, replacing all usages of os/exec with golang.org/x/sys/execabs. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Nope! I just rebased to get rid of the other commits (well, doesn't really change, but it's confusing on GitHub otherwise); moving it out of draft |
|
Blogpost is indeed interesting; I was aware of similar things with dll's on Windows, but guess this one is a typical case of "common knowledge that we forgot about"; thought it wouldn't hurt to follow their recommendations (IMO, |
|
oops, sorry, looks like I pushed too many times, and you're out of credits 😬, hope that's only "for the day", and not for the rest of the month 😅
|
Following the changes in Go, and golang.org/x/tools themselves, this change ensures that packages using exec.LookPath or exec.Command to find or run binaries do not accidentally run programs from the current directory when they mean to run programs from the system PATH instead. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go.mod: golang.org/x/tools v0.1.0
Project now started to do releases; this one was related to a
security issue on Windows, replacing all usages of os/exec with
golang.org/x/sys/execabs.
icmd: replace all usages of os/exec with golang.org/x/sys/execabs
Following the changes in Go, and golang.org/x/tools themselves, this change
ensures that packages using exec.LookPath or exec.Command to find or run
binaries do not accidentally run programs from the current directory when
they mean to run programs from the system PATH instead.