Side note: Windows has multiple ways of resolving application paths. The one that os/exec had implemented before 1.15.7 is the one implemented by cmd.exe (and most CLI tools), not the one recommended for GUI tools which involves more than PATH. Just to say that os/exec has never been the only right way to launch commands on Windows.

Sounds reasonable.
/cc @alexbrainman @zx2c4

Huh, interesting rabbit hole here. One thing I noticed is that CreateProcess itself will handle path resolution if you pass it a non-absolute executable name as argv[0] and NULL as the actual executable path name:

from https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa

As an aside from the specific proposal here, this makes me wonder if instead of having exec.Command use LookPath, it should instead use that behavior of CreateProcess, and then we always do what windows does.

With regards to NeedCurrentDirectoryForExePath, here's what kernelbase.dll is doing on Windows 10, translated from the x86 into Go:

if strings.Index(exePath, `\`) != -1 { return true }
_, ok := os.Environ()["NoDefaultCurrentDirectoryInExePath"]
return !ok

So when you write:

Note that this proposal is different from just looking at the existence of a NoDefaultCurrentDirectoryInExePath environment variable because the function doesn't just look in the process environment variables but might also look in registry settings.

I'm not sure that this is actually true. Are there other versions of Windows you think I should look at?

use [the] behavior of CreateProcess and ... always do what windows does

Is it just me or does this sound really reckless? This entire proposal arose exactly from the necessity to mitigate the risk of malicious code execution that may lurk in a current working directory (#38736, #42420, #42950 and #43724). The fact that Microsoft did stupid sh...tuff (and still does, and have been doing for ages), really does not mean we or anyone else should ape them in that, ever (again). Convenience should not take precedence over security.

I hadn't seen #43724. I was thinking that Go wouldn't want a behavior change, and would want to keep os/exec using the defaults of whatever operating system and environment it's using. But it looks like #43724 changes that. So this issue here, I suppose, becomes one of "how can we tell when Windows is going to do something bad?" And I take it that @dolmen's suggestion is to use NeedCurrentDirectoryForExePath() instead of checking the NoDefaultCurrentDirectoryInExePath environment variable. But in reversing the former, I saw that it's basically the same as the latter.

In summary:

Except for the error in #43724, LookPath aims to match Windows cmd.exe.
If Windows has been configured to not add "." to the PATH implicitly,
then this proposal is for LookPath to respect that configuration setting
(which turns out to be an environment variable).

This seems unobjectionable. There was some discussion above arising from confusion about what exactly is being proposed, but that seems to have been resolved.

Does anyone object to this proposal?

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Change https://golang.org/cl/381374 mentions this issue: os/exec: return error when PATH lookup would use current directory

@rsc wrote:

then this proposal is for LookPath to respect that configuration setting (which turns out to be an environment variable).

This is not what this proposal is about because the case where the configuration setting is in the registry and not in the environment is not handled.

This proposal is about using NeedCurrentDirectoryForExePathW to ensure that however the system setting is defined it is respected.

So CL381374 is not a correct implementation of this proposal because it only uses the environment variable.

The above CL broke x/sys/execabs (and its users in the wild, who may or may not ever update), since it expects to find a lookPathErr field, but the CL removes it in favor of an exported Err.

Change https://go.dev/cl/403058 mentions this issue: Revert "os/exec: return error when PATH lookup would use current directory"

Change https://go.dev/cl/403694 mentions this issue: os/exec: in Command, update cmd.Path even if LookPath returns an error

This appears to be done. Please comment if you disagree.