The channel is created with no capacity that it needs receiver when
sending data. Otherwise, the sending-data goroutine will be blocked
forever. For the #6166 pr, the exec command timeout will return and
no receiver for the data. It will cause goroutine leaky.
This commit allocates buffered channel for the command status and closes
the channel after sending. And also use time.Timer with Stop for
performance concern.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Go 1.15.7 contained a security fix for CVE-2021-3115, which allowed arbitrary
code to be executed at build time when using cgo on Windows. This issue also
affects Unix users who have “.” listed explicitly in their PATH and are running
“go get” outside of a module or with module mode disabled.
This issue is not limited to the go command itself, and can also affect binaries
that use `os.Command`, `os.LookPath`, etc.
From the related blogpost (ttps://blog.golang.org/path-security):
> Are your own programs affected?
>
> If you use exec.LookPath or exec.Command in your own programs, you only need to
> be concerned if you (or your users) run your program in a directory with untrusted
> contents. If so, then a subprocess could be started using an executable from dot
> instead of from a system directory. (Again, using an executable from dot happens
> always on Windows and only with uncommon PATH settings on Unix.)
>
> If you are concerned, then we’ve published the more restricted variant of os/exec
> as golang.org/x/sys/execabs. You can use it in your program by simply replacing
This patch replaces all uses of `os/exec` with `golang.org/x/sys/execabs`. While
some uses of `os/exec` should not be problematic (e.g. part of tests), it is
probably good to be consistent, in case code gets moved around.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It was only used in sys/reaper, and after moving it, that package
no longer depends on the `sys` package.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
