Skip to content
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

proposal: os/exec: make LookPath not look in dot implicitly on Windows #38736

Closed
dholmesdell opened this issue Apr 29, 2020 · 25 comments
Closed

proposal: os/exec: make LookPath not look in dot implicitly on Windows #38736

dholmesdell opened this issue Apr 29, 2020 · 25 comments

Comments

@dholmesdell
Copy link

@dholmesdell dholmesdell commented Apr 29, 2020

What version of Go are you using (go version)?

$ go version
go version go1.14.1 windows/amd64

Originally noticed with Go 1.8 though.

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\holmed2\AppData\Local\go-build
set GOENV=C:\Users\holmed2\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\holmed2\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\holmed2\AppData\Local\Temp\go-build226326482=/tmp/go-build -gno-record-gcc-switches

What did you do?

Copy “C:\Windows\System32\whoami.exe” to the following program’s directory as “systeminfo.exe” and then run the program:

package main

import (
      "fmt"
      "os"
      "os/exec"
)

func main() {
      os.Setenv("PATH", `C:\Windows\System32`)

      cmd := exec.Command("systeminfo.exe")
      out, err := cmd.CombinedOutput()
      if err != nil {
            panic(err)
      }
      fmt.Println(string(out))
}

What did you expect to see?

The output of C:\Windows\System32\systeminfo.exe

What did you see instead?

The output of ./systeminfo.exe (my username, since it is a copy of whoami.exe)

If the renamed copy of systeminfo.exe is removed from the test program’s directory, then the output of “C:\Windows\System32\systeminfo.exe” is displayed as expected.

Analysis

os/exec/lp_windows.go contains the following:

func LookPath(file string) (string, error) {
…
      if strings.ContainsAny(file, `:\/`) {
            if f, err := findExecutable(file, exts); err == nil {
                  return f, nil
            } else {
                  return "", &Error{file, err}
            }
      }
      if f, err := findExecutable(filepath.Join(".", file), exts); err == nil {
            return f, nil
      }

If the value of ‘file’ is an absolute or relative path, a result is returned. The concern is with a value which is only a name, such as “systeminfo.exe”. One would expect this to search the list of paths found in the PATH environment variable, but before doing so the code explicitly searches the current working directory (“.”). There does not appear to be any means provided to disable this behavior and search only PATH.

I would guess that the intent was to mimic the behavior of the cmd.exe command shell, which searches the current directory first even if it is not specified in PATH. By comparison, the documentation for the Windows CreateProcess API indicates that it does not search PATH at all, but will use the current directory to complete a partial path. (The SearchPath API offers an alternative, though also flawed, option to search the current directory last.)

The problem is that it is not possible to use exec.LookPath, and thus exec.Command, to search the system PATH without searching the current directory. Thus even if diligence is taken to have the program set a secure PATH value, the programmer must be aware of this behavior and avoid using these standard library functions. The documentation of exec.LookPath does not mention the current directory, stating only that it searches “the directories named by the PATH environment variable.”

Suggestions

My preferred recommendation would be to remove the explicit search of “.” (the second if-clause shown above), in order to provide the best level of security and comply with the documentation. A programmer can add “.” to the PATH environment variable value if the behavior is desired, as one would do in a linux/unix program.

If the resulting change in Go behavior/compatibility is not desirable, a workaround could be for exec.LookPath to reference the NoDefaultCurrentDirectoryInExePath environment variable and avoid searching “.” if it is set. This is a workaround which Microsoft apparently added in Vista to disable the behavior in cmd.exe.

cc @FiloSottile

@as
Copy link
Contributor

@as as commented Apr 29, 2020

Disabling this will likely break dockerized windows containers relying on the behavior. Amusingly, creating ping.bat will make cmd.exe run it before the system's ping command, as windows has an extension search list too.

But, if you can copy a file in the same directory as the executable, you can probably rename the original executable (even while its process is running) and replace it with a program that deletes all files on your filesystem next time its executed. The security community treats the filesystem as the wild wild west, but the only way to mitigate hijacking attacks is to properly secure the filesystem in the first place.

Hence, I think Go should not try to solve this problem if LookPath is designed to be compatible with Windows behavior (but NoDefaultCurrentDirectoryInExePath might be a good idea, depending on how it works with modern Windows versions).

@FiloSottile FiloSottile changed the title Unsecure path search in os/exec os/exec: LookPath implicitly searches current directory Apr 29, 2020
@ianlancetaylor ianlancetaylor added this to the Backlog milestone Apr 30, 2020
@aral
Copy link

@aral aral commented Jul 23, 2020

I’d consider this desirable behaviour, if consistent cross-platform.

e.g., Use case:

mkcert uses the following call to find certutil if it is installed:

exec.LookPath("certutil")

I’m going to be bundling pre-built binaries of certutil with future version of Auto Encrypt Localhost. Afaics, with the current behaviour, all I have to do is place the certutil binary and the nss dynamic libraries in the same folder as the mkcert binary. If I had to specify the folder explicitly, I’d most likely have to maintain a fork of mkcert.

@mislav
Copy link

@mislav mislav commented Oct 27, 2020

I would guess that the intent was to mimic the behavior of the cmd.exe command shell, which searches the current directory first even if it is not specified in PATH.

@dholmesdell You are right that this was the motivation for the feature: 2a876be

However, I would argue that this was a bad call, as it was made 9 years ago with little discussion about pros & cons. I don't see why the shell feature of cmd.exe to execute binaries or batch scripts from the local directory was worth propagating in Go, especially since that feature wasn't kept in PowerShell, which is now de-facto standard shell in Windows.

This behavior of LookPath on Windows absolutely goes against the documentation of the LookPath method, and I find it surprising at best and a security vulnerability at worst.

/cc @alexbrainman @rsc for comments

@rsc
Copy link
Contributor

@rsc rsc commented Oct 28, 2020

The behavior we chose matched the behavior of the default Windows shell at the time.
It seems unlikely we could change it now without breaking many Windows programs.

@mislav
Copy link

@mislav mislav commented Oct 29, 2020

@rsc I understand; thank you for chiming in.

Would you be open to a documentation change that points out this behavior on Windows?

@dawidgolunski
Copy link

@dawidgolunski dawidgolunski commented Oct 29, 2020

Hi. As for executing new processes, I thought the Windows standard order (other than cmd that mimics DOS) of searching directories was the one used by the CreateProcessA in win32 API which only searches the current directory as the second option, only if the command was not found in the directory from which the application loaded . See:
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
I think this is what python's subprocess.Pipe() method mimics on Windows for example.

I personally saw it as a vuln and even requested a CVE for this issue but it seems like the agreement here is that it can't be changed in Go itself and programmers must take care of this individually.
What I think would be helpful in this case, in addition to clarifying the documentation, is adding a separate function to GO that only searches the directories declared in PATH without including cwd/. E.g. StrictPath() in the exec package?
This way existing apps won't be broken and programmers can use this function without re-inventing the wheel when needed.
Just an idea. Would this work ? Could this be added?

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 29, 2020

@mislav Documentation changes are fine.

@dawidgolunski As far as I can tell exec.LookPath on Windows does not search the directory from which the application loaded at all. It searches the current directory, then the directories on the environment variable path.

I could imagine a exec.LookPathStrict proposal. Do you want to write one (https://golang.org/s/proposal)? It could perhaps ignore . or any relative directory on the PATH/path.

@dawidgolunski
Copy link

@dawidgolunski dawidgolunski commented Oct 29, 2020

@dawidgolunski As far as I can tell exec.LookPath on Windows does not search the directory from which the application loaded at all. It searches the current directory, then the directories on the environment variable path.

@ianlancetaylor That's right, LookPath function does not do that. I was referring to the CreateProcessA function (processthreadsapi.h) from the Windows API. The Microsoft article I sent in the previous message defines the executable file search order (if the full path was not provided) as follows:

1. The directory from which the application loaded.
2. The current directory for the parent process.
...
6. The directories that are listed in the PATH environment variable.

The step 1 adds a layer of protection as usually installed applications are loaded from directories owned by admin/SYSTEM user which prevents modification as regular users can't add files into them.

I could imagine a exec.LookPathStrict proposal. Do you want to write one (https://golang.org/s/proposal)?

Good name I think. As for the proposal, I'll try to have a go at it when I get a spare minute.

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Oct 31, 2020

@mislav

I refer you to what @rsc said. We made decision based on our knowledge at the time. There was no PowerShell back then. I still do not use PowerShell. Hardly any Windows users use PowerShell.

I also refer you to what @dawidgolunski said. CreateProcess is a good authority here. And CreateProcess puts PATH at number 6 - pretty low.

I am still happy with the decision we made.

I agree that LookPath documentation does not mention current directory. We should fix that.

I am not so keen on adding new LookPath function. How would you explain to people which of two functions to use?

I don't see running executable from current directory as security threat. CreateProcess does that too, so that is OK with me.

Alex

@dholmesdell
Copy link
Author

@dholmesdell dholmesdell commented Nov 2, 2020

Should it matter what each platform does in its shell or library? As LookPath is Go's own library function and not a syscall passthrough, one could reasonably expect it to have the same behavior on any platform.

My main concern is that it is not possible to implement secure and consistent behavior in Go programs without reimplementing part of the library. There might be an argument for exec.Command to behave similarly to CreateProcess. But since the behavior is actually implemented in exec.LookPath, one cannot use it to obtain an explicit path in order to avoid the "convenience" behavior in exec.Command. There seems to be no option to avoid searching "." without reimplementing one's own version of LookPath.

In other words, from my view having an option to use LookPath (or another similar function, though that seems slightly awkward) to search only PATH (without including ".") so that I can use that result with exec.Command myself would satisfy the need.

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Nov 4, 2020

Should it matter what each platform does in its shell or library? As LookPath is Go's own library function and not a syscall passthrough, one could reasonably expect it to have the same behavior on any platform.

I don't think it is reasonable to have the same behaviour on different platforms. os.LookPath should do what platform users expect, not some "rule invented by Go authors". Something that is reasonable on one platform could be bug or security fault on another platform.

Alex

@dawidgolunski
Copy link

@dawidgolunski dawidgolunski commented Nov 6, 2020

@ianlancetaylor I've written the proposal on
#42420
From what I understood, issues can be assigned a Proposal label. Please let me know if this is sufficient.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 6, 2020

Thanks, I converted #42420 into a proposal following the guidelines at https://golang.org/s/proposal.

@mislav
Copy link

@mislav mislav commented Nov 11, 2020

I am not so keen on adding new LookPath function. How would you explain to people which of two functions to use?

@alexbrainman Thank you for adding context and your thoughts.

I agree that adding a new LookPath* function could be generally confusing when the two are viewed side-by-side. However, I also find it entirely reasonable that someone would want a utility to only search in PATH and not the current directory.

I have created the https://github.com/cli/safeexec module to provide such a LookPath implementation for Windows, and I've basically had to copy-paste a non-trivial amount of code from Go's standard library to preserve the parts of LookPath logic that I wanted to keep (iterating over %PATH%, respecting existing file extension, trying extensions from %PATHEXT%) just to avoid the 2 lines of logic that we wanted to avoid.

I was forced to do this because an innocent-looking invocation of exec.Command("git", args...) in our GitHub CLI tool was reported as a potential security vulnerability: GHSA-fqfh-778m-2v32

It looks like the docker-compose CLI tool also wanted to avoid the security issue, and they had to copy-paste the same code from stdlib into a new package: https://github.com/docker/compose-cli/pull/884/files#diff-3f9e9d4a31ba2c4d9ae604425c9cdca77b4e61f39289fdd35a02ca422c0a6a41

So while I can understand your stance on this and the fact that Go wants to keep backwards compatibility whenever possible, Go programs executing on Windows currently do not have any way of easily running a command found in PATH while also respecting PATHEXT. Our options are:

  • Reach for the exec.LookPath function that advertises this functionality, and thus unintentionally expose themselves to unwanted behavior of scanning the current directory;
  • Implement the logic manually, risking introducing bugs re: extension handling;
  • Copy-paste the code from stdlib into an internal module;
  • Use a 3rd-party module like https://github.com/cli/safeexec.

None of these options feel great to me. I believe that Go's standard library should make a PATH-based command dispatch accessible without any side-effect.

@ianlancetaylor Thank you for submitting the proposal! ❤️

@Bob69ckr

This comment was marked as spam.

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Nov 21, 2020

I agree that adding a new LookPath* function could be generally confusing when the two are viewed side-by-side. However, I also find it entirely reasonable that someone would want a utility to only search in PATH and not the current directory.

Agreed.

I have created the https://github.com/cli/safeexec module to provide such a LookPath implementation for Windows,

Wonderful. Looks good.

... and I've basically had to copy-paste a non-trivial amount of code from Go's standard library to preserve the parts of LookPath logic that I wanted to keep (iterating over %PATH%, respecting existing file extension, trying extensions from %PATHEXT%) just to avoid the 2 lines of logic that we wanted to avoid.

I think it is fair price to pay for you to have modified version of exec.LookPath. The alternative would be confused users trying to decide which of two exec.LookPath* to use. Users who need your version of LookPath will find it at github.com/cli/safeexec.

I was forced to do this because an innocent-looking invocation of exec.Command("git", args...) in our GitHub CLI tool was reported as a potential security vulnerability: GHSA-fqfh-778m-2v32

I don't doubt standard exec.LookPath is not suitable for your project. But your scenario is special. Windows binaries are supposed to be installed in a predefined locations (https://en.wikipedia.org/wiki/Program_Files), and not uncontrollably downloaded into current directory. I suspect that Git authors never considered Windows when designing their system.

It looks like the docker-compose CLI tool also wanted to avoid the security issue, and they had to copy-paste the same code from stdlib into a new package: https://github.com/docker/compose-cli/pull/884/files#diff-3f9e9d4a31ba2c4d9ae604425c9cdca77b4e61f39289fdd35a02ca422c0a6a41

I did not look at these links. But I agree, they are similar to your project. They should use the package you created.

None of these options feel great to me.

I disagree. Users who need this functionality should use https://github.com/cli/safeexec. Perhaps over time, Windows will change in this regard, and exec.LookPath will change too. But today most Windows users should use standard Windows rules.

Alex

@iamheartypareja
Copy link

@iamheartypareja iamheartypareja commented Nov 22, 2020

I agree that adding a new LookPath* function could be generally confusing when the two are viewed side-by-side. However, I also find it entirely reasonable that someone would want a utility to only search in PATH and not the current directory.

Agreed.

I have created the https://github.com/cli/safeexec module to provide such a LookPath implementation for Windows,

Wonderful. Looks good.

... and I've basically had to copy-paste a non-trivial amount of code from Go's standard library to preserve the parts of LookPath logic that I wanted to keep (iterating over %PATH%, respecting existing file extension, trying extensions from %PATHEXT%) just to avoid the 2 lines of logic that we wanted to avoid.

I think it is fair price to pay for you to have modified version of exec.LookPath. The alternative would be confused users trying to decide which of two exec.LookPath* to use. Users who need your version of LookPath will find it at github.com/cli/safeexec.

I was forced to do this because an innocent-looking invocation of exec.Command("git", args...) in our GitHub CLI tool was reported as a potential security vulnerability: GHSA-fqfh-778m-2v32

I don't doubt standard exec.LookPath is not suitable for your project. But your scenario is special. Windows binaries are supposed to be installed in a predefined locations (https://en.wikipedia.org/wiki/Program_Files), and not uncontrollably downloaded into current directory. I suspect that Git authors never considered Windows when designing their system.

It looks like the docker-compose CLI tool also wanted to avoid the security issue, and they had to copy-paste the same code from stdlib into a new package: https://github.com/docker/compose-cli/pull/884/files#diff-3f9e9d4a31ba2c4d9ae604425c9cdca77b4e61f39289fdd35a02ca422c0a6a41

I did not look at these links. But I agree, they are similar to your project. They should use the package you created.

None of these options feel great to me.

I disagree. Users who need this functionality should use https://github.com/cli/safeexec. Perhaps over time, Windows will change in this regard, and exec.LookPath will change too. But today most Windows users should use standard Windows rules.

Alex

#38736 (comment)

profclems added a commit to profclems/glab that referenced this issue Nov 26, 2020
I added a work around to the exec.LookPath issue (golang/go#38736) on windows
@rsc rsc changed the title os/exec: LookPath implicitly searches current directory proposal: os/exec: make LookPath not look in dot implicitly on Windows Dec 2, 2020
@rsc
Copy link
Contributor

@rsc rsc commented Dec 2, 2020

We now have three active proposals related to dot in path lookup:

  • #38736, which removes the implicit dot lookup from LookPath on Windows
  • #42420, to add LookPathAbs that doesn't return relative results.
  • #42950, to make exec.Command use LookPathAbs by default (assuming it is added)

Please try to keep comments on these limited to the specific issue they track. Thanks.

@rsc rsc added this to Active in Proposals Dec 2, 2020
@cagedmantis cagedmantis added Proposal and removed Proposal labels Dec 4, 2020
@rsc rsc modified the milestones: Backlog, Proposal Dec 9, 2020
@rsc
Copy link
Contributor

@rsc rsc commented Dec 16, 2020

Looking at this again in the context of the three active proposals. Earlier, I wrote:

The behavior we chose matched the behavior of the default Windows shell at the time.
It seems unlikely we could change it now without breaking many Windows programs.

I don't have any actual evidence that the second line is true, though, and I am starting to wonder whether I am wrong about this.

It seems to me that any Windows programs that depend on the implicit dot in the PATH must necessarily not run on Unix. (On Unix, most users do not have dot in their PATH, so the program would fail for those users.) So the only programs that would break are Windows-only programs. And then further limiting to Windows-only programs that execute other programs. And then further limiting to Windows-only programs that execute other programs when those programs are expected to be found in the current directory. This may in fact end up being very few Windows programs.

Is that actually common? Can anyone speak to that?

bep added a commit to bep/godartsass that referenced this issue Dec 22, 2020
zimbatm added a commit to zimbatm/direnv that referenced this issue Dec 23, 2020
This has potential security issues as the repo could contain a
`bash.exe` that is malicious. It extends the scope of review of the user
beyond the `.envrc`.

Thanks to RyotaK for reporting this issue.

More details at:
* https://legalhackers.com/advisories/Git-LFS-RCE-Exploit-CVE-2020-27955.html
* golang/go#38736
zimbatm added a commit to zimbatm/direnv that referenced this issue Dec 23, 2020
This has potential security issues as the repo could contain a
`bash.exe` that is malicious. It extends the scope of review of the user
beyond the `.envrc`.

Thanks to RyotaK for reporting this issue.

More details at:
* https://legalhackers.com/advisories/Git-LFS-RCE-Exploit-CVE-2020-27955.html
* golang/go#38736
zimbatm added a commit to zimbatm/direnv that referenced this issue Dec 23, 2020
This has potential security issues as the repo could contain a
`bash.exe` that is malicious. It extends the scope of review of the user
beyond the `.envrc`.

Thanks to RyotaK for reporting this issue.

More details at:
* https://legalhackers.com/advisories/Git-LFS-RCE-Exploit-CVE-2020-27955.html
* golang/go#38736
@rsc
Copy link
Contributor

@rsc rsc commented Jan 20, 2021

For anyone following this issue, I think we've figured out a way to avoid surprising or confusing breakages but still correct the behavior. See #43724.

@KalleOlaviNiemitalo
Copy link

@KalleOlaviNiemitalo KalleOlaviNiemitalo commented Jan 24, 2021

If the resulting change in Go behavior/compatibility is not desirable, a workaround could be for exec.LookPath to reference the NoDefaultCurrentDirectoryInExePath environment variable and avoid searching “.” if it is set.

If you decide to use the environment variable, then Microsoft documentation recommends calling NeedCurrentDirectoryForExePathW instead of reading the environment variable directly.

@rsc
Copy link
Contributor

@rsc rsc commented Jan 27, 2021

Given #43724 it seems like we should simplify down and decline this proposal.

@rsc
Copy link
Contributor

@rsc rsc commented Jan 27, 2021

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

@rsc rsc moved this from Active to Likely Decline in Proposals Jan 27, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Feb 3, 2021

No change in consensus, so declined.
— rsc for the proposal review group

@rsc rsc moved this from Likely Decline to Declined in Proposals Feb 3, 2021
@rsc rsc closed this Feb 3, 2021
@tarenshit

This comment was marked as off-topic.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Feb 9, 2021
Changelog:
0.80.0
Enhancements

Templates

  * Regenerate templates a2d146ec @bep
  * tpl/internal/go_templates: Revert formatting 718e09ed @bep
  * Add title parameter to YouTube shortcode 4fc918e0 @azenk

Output

  * Add missing OutputStyle option 428b0b32 @bep

Other

  * Allow Dart Sass transformations to be cached on disk ffbf5e45 @bep
  * Dart Sass only supports expanded and compressed 48994ea7 @bep
  * Update emoji import paths and version 1f7e9f73 @moorereason
  * Add Dart Sass support cea15740 @bep #7380#8102
  * GroupByParamDate now supports datetimes f9f77978 @zerok
  * Skip para test when not on CI a9718f44 @bep #6963
  * Update SECURITY.md f802bb23 @bep
  * Improve LookPath 10ae7c32 @bep
  * create a SECURITY.md ae2d1bd5 @davidsneighbour #8074
  * Show more detail on failed time test 8103188b @moorereason #6963
  * Add images.Overlay filter 3ba147e7 @bep #8057#4595#6731
  * Bump github.com/spf13/cobra from 0.15.0 to 0.20.0 c84ad8db @anthonyfok
  * configure proper link to discourse.gohugo.io (#8020) 4e0acb89
    @davidsneighbour
  * Format code with gofumpt d90e37e0 @bep
  * bump github.com/evanw/esbuild from 0.8.15 to 0.8.17 32471b57 @dependabot
    [bot]
  * Use --baseURL path for live-reload URL 0ad378b0 @sth #6595
  * bump github.com/getkin/kin-openapi from 0.31.0 to 0.32.0 907d9e92
    @dependabot[bot]

Fixes

Templates

  * Fix series detection in opengraph d2d493ab @Humberd
  * Fix substr when length parameter is zero 5862fd2a @moorereason #7993
  * Refactor and fix substr logic 64789fb5 @moorereason #7993

Other

  * Fix Resource.ResourceType so it always returns MIME's main type 81975f84
    @bep #8052
  * hugolib/paths: Fix typo ce96895d @mayocream
  * Fix minor typos 04b89857 @phil-davis
  * Fix BenchmarkMergeByLanguage 21fa1e86 @bep #7914
  * Fix RelURL and AbsURL when path starts with language aebfe156
    @ivan-meridianbanc-com

0.79.1:
Hugo depends on Go's os/exec for certain features, e.g. for rendering of Pandoc
documents if these binaries are found in the system %PATH% on Windows. However,
if a malicious file with the same name (exe or bat) was found in the current
working directory at the time of running hugo, the malicious command would be
invoked instead of the system one.

Windows users who ran hugo inside untrusted Hugo sites was affected.

The origin of this issue comes from Go, see golang/go#38736

We have fixed this in Hugo by using a patched version of exec.LookPath from
https://github.com/cli/safeexec (thanks to @mislav for the implementation).

Thanks to @Ry0taK for the bug report.

0.79.0:
Hugo 0.79.0 is a small, but useful release. You can now set custom .Params in
your menu configuration, and you can now also override deeply nested
snake_cased configuration variables with OS environment variables. Other than
that we have refreshed all the core upstream dependencies. A special thanks to
@alecthomas (some new Chroma lexers and fixes) and @evanw (ESBuild).

This release represents 33 contributions by 8 contributors to the main Hugo
code base. @bep leads the Hugo development with a significant amount of
contributions, but also a big shoutout @AdamKorcz, and @davidejones for their
ongoing contributions. And a big thanks to @digitalcraftsman for his relentless
work on keeping the themes site in pristine condition and to @davidsneighbour,
@coliff and @kaushalmodi for all the great work on the documentation site.

Many have also been busy writing and fixing the documentation in hugoDocs,
which has received 13 contributions by 11 contributors. A special thanks to
@Valac01, @bep, @mhansen, and @chanjarster for their work on the documentation
site.

Enhancements

Templates

  * Add more layout lookup tests 34061706 @moorereason #7964

Other

  * bump gopkg.in/yaml.v2 from 2.3.0 to 2.4.0 17e0bbe8 @dependabot[bot]
  * Allow setting the delimiter used for setting config via OS env, e.g. HUGO_
    7e223b3b @bep #7829
  * Update to github.com/evanw/esbuild 0.8.11 to 0.8.14 8a6e7060 @bep #7986
  * bump github.com/google/go-cmp from 0.5.2 to 0.5.3 6f7633df @dependabot[bot]
  * Remove unneeded meta tag from blog example a546059a @coliff
  * bump github.com/getkin/kin-openapi from 0.30.0 to 0.31.0 b5d906e3
    @dependabot[bot]
  * Regen docshelper fd70bdaf @bep
  * Add menu params 8f5c9a74 @davidejones #7951
  * Preserve url set in frontmatter without sanitizing e4fcb672 @satotake #6007
  * Add file deleted by accident 18c13adc @bep #7972
  * Regenerate docshelper" 20a35374 @bep #7972
  * Regenerate docshelper caf16c20 @bep
  * Update to Chroma v0.8.2 b298c06e @bep #7970
  * bump github.com/evanw/esbuild from 0.8.8 to 0.8.11 55e290af @dependabot
    [bot]
  * bump github.com/getkin/kin-openapi from 0.26.0 to 0.30.0 506a190a
    @dependabot[bot]
  * bump github.com/evanw/esbuild from 0.8.6 to 0.8.8 fc81de64 @dependabot[bot]
  * Let ESBuild handle all imports from node_modules 78f227b6 @bep #7948
  * bump github.com/evanw/esbuild from 0.8.5 to 0.8.6 5e03f644 @dependabot[bot]
  * bump github.com/evanw/esbuild from 0.8.4 to 0.8.5 a92ef20f @dependabot[bot]
  * bump github.com/getkin/kin-openapi from 0.22.1 to 0.26.0 0d54a844
    @dependabot[bot]
  * Update GH docs to say "main" as default branch 943f3c93 @maco
  * Updated year in header 4f20bf29 @AdamKorcz
  * Added first fuzzer 4c613d5d @AdamKorcz
  * bump github.com/frankban/quicktest from 1.11.1 to 1.11.2 82a182e5
    @dependabot[bot]
  * bump golang.org/x/text from 0.3.3 to 0.3.4 dfc662b2 @dependabot[bot]
  * bump github.com/evanw/esbuild from 0.8.3 to 0.8.4 2f0917cc @dependabot[bot]
  * Disable NPM test on Travis on Windows 3437174c @bep
  * Install nodejs on Windows f66302ca @bep
  * Remove external source map option 944150ba @bep #7932

Fixes

Other

  * Fix memory usage in writeStats d162bbd7 @bep #7945
  * Fix server rebuild issue with partials referenced from render hooks
    e442cf30 @bep #7990
  * Misc fixes bf2837a3 @bep #7924#7923
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Declined
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
24 participants