/ go Public

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

Closed
opened this issue Apr 29, 2020 · 31 comments
Closed

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

opened this issue Apr 29, 2020 · 31 comments
Labels
Projects
Milestone

$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.

### 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).

added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows labels Apr 29, 2020
added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. Security labels Apr 29, 2020
removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 29, 2020
changed the title Unsecure path search in os/exec os/exec: LookPath implicitly searches current directory Apr 29, 2020
added this to the Backlog milestone Apr 30, 2020

### 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 commented Oct 27, 2020 • edited

 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 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 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 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 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 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 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 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 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

mentioned this issue Nov 5, 2020
mentioned this issue Nov 6, 2020

### 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 commented Nov 6, 2020

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

### mislav commented Nov 11, 2020 • edited

 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! ❤️

### 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 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)

added a commit to profclems/glab that referenced this issue Nov 26, 2020
 Ensure only \$PATH is searched when switching to external commands 
 51c3e7d 
I added a work around to the exec.LookPath issue (golang/go#38736) on windows
mentioned this issue Nov 26, 2020
mentioned this issue Dec 2, 2020
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
added a commit to zimbatm/direnv that referenced this issue Dec 23, 2020
 lp: stop looking in . on Windows 
 1dcb094 
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:
* golang/go#38736
added a commit to zimbatm/direnv that referenced this issue Dec 23, 2020
 lp: stop looking in . on Windows 
 ec2eb71 
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:
* golang/go#38736
mentioned this issue Dec 27, 2020
mentioned this issue Dec 30, 2020
mentioned this issue Jan 19, 2021

### 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 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.

mentioned this issue Jan 27, 2021

### rsc commented Jan 27, 2021

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

### rsc commented Jan 27, 2021

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

moved this from Active to Likely Decline in Proposals (old) Jan 27, 2021

### rsc commented Feb 3, 2021

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

moved this from Likely Decline to Declined in Proposals (old) Feb 3, 2021
closed this as completed Feb 3, 2021

### This comment has been minimized.

pushed a commit to NetBSD/pkgsrc that referenced this issue Feb 9, 2021
 hugo: Update to 0.80.0 
 bb9710d 
Changelog:
0.80.0
Enhancements

Templates

* Regenerate templates a2d146ec @bep
* tpl/internal/go_templates: Revert formatting 718e09ed @bep

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
* 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]
* 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
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
* Preserve url set in frontmatter without sanitizing e4fcb672 @satotake #6007
* 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
* 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
pushed a commit to TritonDataCenter/pkgsrc that referenced this issue May 12, 2021
 hugo: Update to 0.80.0 
 3f31df9 
Changelog:
0.80.0
Enhancements

Templates

* Regenerate templates a2d146ec @bep
* tpl/internal/go_templates: Revert formatting 718e09ed @bep

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
* 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]
* 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
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
* Preserve url set in frontmatter without sanitizing e4fcb672 @satotake #6007
* 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
* 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
mentioned this issue May 19, 2021
mentioned this issue May 29, 2021
deleted a comment Feb 14, 2022

### This comment was marked as spam.

mentioned this issue Jun 19, 2022

### bcmills commented Jul 8, 2022

 Proposal #43947 was accepted and implemented for this instead.

closed this as not planned Won't fix, can't repro, duplicate, stale Jul 8, 2022
locked as resolved and limited conversation to collaborators Jul 8, 2022