Go 1.19 os/exec Error on Executable in Current Directory

[bflad]

Terraform CLI and Provider Versions

N/A and N/A

Use Cases or Problem Statement

Go 1.19 was recently released and one of its minor version changes is to the os/exec package when the executable is found in the current directory. This will now return an error to prevent potentially unexpected or malicious code execution.

Additional information from the updated os/exec documentation:

The functions Command and LookPath look for a program in the directories listed in the current path, following the conventions of the host operating system. Operating systems have for decades included the current directory in this search, sometimes implicitly and sometimes configured explicitly that way by default. Modern practice is that including the current directory is usually unexpected and often leads to security problems.

To avoid those security problems, as of Go 1.19, this package will not resolve a program using an implicit or explicit path entry relative to the current directory. That is, if you run exec.LookPath("go"), it will not successfully return ./go on Unix nor .\go.exe on Windows, no matter how the path is configured. Instead, if the usual path algorithms would result in that answer, these functions return an error err satisfying errors.Is(err, ErrDot).

For example, consider these two program snippets:

...

cmd := exec.Command("prog")
if err := cmd.Run(); err != nil {
	log.Fatal(err)
}

These will not find and run ./prog or .\prog.exe, no matter how the current path is configured.

Code that always wants to run a program from the current directory can be rewritten to say "./prog" instead of "prog".

Just upgrading to Go 1.19 without code changes could introduce regressions for existing Terraform configurations that are dependent on the current directory lookup behavior.

Proposal

Multiple proposals will mention the os/exec package error workaround, which I'll describe up front here:

Code that insists on including results from relative path entries can instead override the error using an errors.Is check:

...

cmd := exec.Command("prog")
if errors.Is(cmd.Err, exec.ErrDot) {
	cmd.Err = nil
}
if err := cmd.Run(); err != nil {
	log.Fatal(err)
}

Proposals should not include the GODEBUG workaround as:

Setting the environment variable GODEBUG=execerrdot=0 disables generation of ErrDot entirely, temporarily restoring the pre-Go 1.19 behavior for programs that are unable to apply more targeted fixes. A future version of Go may remove support for this variable.

Proposal 1

Do nothing in the provider code after Go 1.19 upgrade, note change in CHANGELOG/release notes, and release new minor version. Typically, Go version upgrades are considered as "technical debt" for provider codebases and this change could be treated more as a bug fix in the name of security. This will potentially break existing Terraform configurations that do not update to .//.\ syntax after upgrading the provider, which is not a great practitioner experience.

Proposal 2

Do nothing in the provider code after Go 1.19 upgrade, note change in CHANGELOG/release notes, and release new major version. This will treat the change as a breaking change, but provide practitioners no advanced notice about potential issues in existing configurations. This will signal to practitioners the change may require configuration updates, but could stifle rollout in environments where it is hard to determine if the change will cause issues.

Proposal 3

Update the provider code with the os/exec workaround when performing the Go 1.19 upgrade, release new minor version, and leave workaround in place. This will prevent practitioners from potential configuration updates and will never notify practitioners of the potential security issue. In general, providers should promote a better security posture when possible for practitioners, so this is likely a non-starter.

Proposal 4

Update the provider code with the os/exec workaround when performing the Go 1.19 upgrade, release new minor version, and remove the os/exec workaround when releasing a new major version. This will prevent practitioners from potential configuration updates until a major version release and enables the provider to upgrade its Go version as expected. Practitioners will not be notified of the potential security issue or have advanced notice of the change.

Proposal 5

Similar to proposal 4, but when implementing the os/exec workaround raise a warning diagnostic instead of skipping over the error completely.

How much impact is this issue causing?

Medium

Additional Information

• https://go.dev/doc/go1.19
• https://go.dev/blog/path-security
• https://pkg.go.dev/os/exec

Code of Conduct

• [X] I agree to follow this project's Code of Conduct