2016-05-18 10:43:42 +00:00
|
|
|
// Package subprocess provides helper functions for forking new processes
|
|
|
|
// NOTE: Subject to change, do not rely on this package from outside git-lfs source
|
2016-03-02 15:16:06 +00:00
|
|
|
package subprocess
|
|
|
|
|
|
|
|
import (
|
2017-08-21 10:09:54 +00:00
|
|
|
"bufio"
|
2021-12-14 17:27:28 +00:00
|
|
|
"errors"
|
2016-03-02 15:16:06 +00:00
|
|
|
"fmt"
|
|
|
|
"os"
|
|
|
|
"os/exec"
|
2018-09-14 21:50:09 +00:00
|
|
|
"regexp"
|
2016-03-02 15:16:06 +00:00
|
|
|
"strings"
|
2020-10-02 16:50:06 +00:00
|
|
|
"sync"
|
2016-03-02 15:16:06 +00:00
|
|
|
|
2021-12-14 17:27:28 +00:00
|
|
|
"github.com/git-lfs/git-lfs/v3/tr"
|
2016-05-23 18:02:27 +00:00
|
|
|
"github.com/rubyist/tracerx"
|
2016-03-02 15:16:06 +00:00
|
|
|
)
|
|
|
|
|
2017-08-21 10:09:54 +00:00
|
|
|
// BufferedExec starts up a command and creates a stdin pipe and a buffered
|
|
|
|
// stdout & stderr pipes, wrapped in a BufferedCmd. The stdout buffer will be
|
|
|
|
// of stdoutBufSize bytes.
|
|
|
|
func BufferedExec(name string, args ...string) (*BufferedCmd, error) {
|
subprocess: report errors when finding executables
On Windows, when spawning a process, Go first looks for an
executable file with the correct name in the current directory, and
only if it fails to find one there does it look in the directories
listed in the PATH environment variable. We would prefer not to
replicate this behaviour and instead search only in the directories
in PATH. Therefore, starting with the mitigation of CVE-2020-27955
in commit 74d5f2397f9abe4834bf1fe1fa02fd6c141b77ce, we resolve paths
to executables ourselves rather than rely on Go to do so.
The subprocess.LookPath() function we introduced in that change
is adapted from Go's os/exec package. When it cannot find an
executable in PATH, it returns an empty path string and an
exec.ErrNotFound error. When that happens, we do not detect the
condition and simply set the command path to the empty string.
This can lead to undesirable behaviour in which a bug in the Go
os/exec library causes it to run another executable other than
the one we intended.
When we set the command path to the empty string and then ask to
execute the command, the native Go version of the LookPath() function
for Windows is run with an empty path because filepath.Base() returns
"." when passed the empty string and because we have left the current
working directory also set to an empty string:
https://github.com/golang/go/blob/1724077b789ad92972ab1ac03788389645306cbb/src/os/exec/exec.go#L348-L353
Since the path string does not contain any path separator
characters the current working directory is searched to try to
find a file with a matching name and executable file extension
(e.g., ".exe" or ".com"). To search the current working directory,
the "." directory name is prepended to the given path with
filepath.Join():
https://github.com/golang/go/blob/1724077b789ad92972ab1ac03788389645306cbb/src/os/exec/lp_windows.go#L84
The filepath.Join() function ignores empty arguments, so this
results in an incorrect filename of ".". All potential executable
file extensions from the PATHEXT environment variable (or from a
fixed list if that variable is not defined) are then appended to
this filename, including their leading dot separator characters,
thus producing filenames like "..com" and "..exe":
https://github.com/golang/go/blob/1724077b789ad92972ab1ac03788389645306cbb/src/os/exec/lp_windows.go#L46-L50
Should a file with one of these names exist in the current working
directory, its name will be returned, which means that it will be
executed instead of the command we expected to run. This is
obviously undesirable and presents a risk to users.
(Note that batch files named "..bat" and "..cmd" will also be found
in the same manner, but they will not actually be executed due to an
undocumented feature of the Windows API's family of CreateProcess*()
functions, which are used by Go to spawn processes. When passed an
lpApplicationName argument ending with a ".bat" or ".cmd" extension,
the CreateProcess*() functions appear to instead execute "cmd.exe"
and construct a "/c" command string from the lpCommandLine argument.
The value of that argument is set using the full command line we are
attempting to execute, and as such its first element is the actual
name of the executable we intended to run; therefore, the command
interpreter attempts to run the executable as a batch script and
fails, and the "..bat" or "..cmd" file is effectively ignored.)
To recap, when Git LFS attempts to execute a program on Windows,
if the executable is not found anywhere in PATH but does exist in
the current working directory, then when we call exec.Command()
Go's internal LookPath() function will find the executable and not
set the internal lookPathErr flag:
https://github.com/golang/go/blob/1724077b789ad92972ab1ac03788389645306cbb/src/os/exec/exec.go#L174-L179
Since we do not want to run executables in the current working
directory, we subsequently run our own LookPath() function, which
we use to reset the cmd.Path field. However, when our LookPath()
returns an empty string, we do not detect that and instead set
cmd.Path to that value. Then when we ask Go to run the command,
because lookPathErr is nil, it proceeds, and the empty path causes
it to find and run the first matching file in the working directory
named "..com" or "..exe" (or any similar name with an executable
file extension except for "..bat" and "..cmd").
We can prevent this behaviour by detecting when our LookPath()
function returns an error and propagating it upwards to all
callers of our subprocess.ExecCommand() function. We also add
checks for this error at appropriate points and log or report
the error as necessary.
One particular circumstance of note occurs when a user has a
Cygwin-installed "uname" in their PATH but not "cygpath",
but "cygpath.exe" does exist in their current working directory.
Then we will attempt to execute "cygpath" because we use the
presence of "uname" as an indication that Cygwin is fully installed.
Should a "..exe" or similar file also be present in the working
directory, then it will be executed instead of "cygpath.exe".
As with all other instances where we call subprocess.ExecCommand(),
in tools.translateCygwinPath() we will now check for a returned
error before trying to actually execute "cygpath". Unlike many
of the other cases, though, we do not need to report the error in
this one; instead, we simply return the current path from
translateCygwinPath() instead of canonicalizing it, just as we do
already if the "cygpath" executable fails for some reason.
Finally, we add a new test to t/t-path.sh which checks for the
incorrect execution of a "..exe" binary on Windows when "git.exe"
is not found in PATH but does exist in the current working
directory. This test passes when run with a Git LFS binary that
includes the remediations from this commit, and fails otherwise.
For our "malicious" binary named "..exe" we make use of the
lfstest-badpathcheck test helper we added in a previous commit.
We only run this test on Windows because the underlying bug in
Go is Windows-specific as it depends on path extensions from
PATHEXT being appended to the file name ".".
Co-authored-by: brian m. carlson <bk2204@github.com>
2022-03-29 06:16:16 +00:00
|
|
|
cmd, err := ExecCommand(name, args...)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2017-08-21 10:09:54 +00:00
|
|
|
stdout, err := cmd.StdoutPipe()
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
stderr, err := cmd.StderrPipe()
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
stdin, err := cmd.StdinPipe()
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
if err := cmd.Start(); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
return &BufferedCmd{
|
|
|
|
cmd,
|
|
|
|
stdin,
|
|
|
|
bufio.NewReaderSize(stdout, stdoutBufSize),
|
|
|
|
bufio.NewReaderSize(stderr, stdoutBufSize),
|
|
|
|
}, nil
|
|
|
|
}
|
|
|
|
|
2016-03-02 15:16:06 +00:00
|
|
|
// SimpleExec is a small wrapper around os/exec.Command.
|
|
|
|
func SimpleExec(name string, args ...string) (string, error) {
|
subprocess: report errors when finding executables
On Windows, when spawning a process, Go first looks for an
executable file with the correct name in the current directory, and
only if it fails to find one there does it look in the directories
listed in the PATH environment variable. We would prefer not to
replicate this behaviour and instead search only in the directories
in PATH. Therefore, starting with the mitigation of CVE-2020-27955
in commit 74d5f2397f9abe4834bf1fe1fa02fd6c141b77ce, we resolve paths
to executables ourselves rather than rely on Go to do so.
The subprocess.LookPath() function we introduced in that change
is adapted from Go's os/exec package. When it cannot find an
executable in PATH, it returns an empty path string and an
exec.ErrNotFound error. When that happens, we do not detect the
condition and simply set the command path to the empty string.
This can lead to undesirable behaviour in which a bug in the Go
os/exec library causes it to run another executable other than
the one we intended.
When we set the command path to the empty string and then ask to
execute the command, the native Go version of the LookPath() function
for Windows is run with an empty path because filepath.Base() returns
"." when passed the empty string and because we have left the current
working directory also set to an empty string:
https://github.com/golang/go/blob/1724077b789ad92972ab1ac03788389645306cbb/src/os/exec/exec.go#L348-L353
Since the path string does not contain any path separator
characters the current working directory is searched to try to
find a file with a matching name and executable file extension
(e.g., ".exe" or ".com"). To search the current working directory,
the "." directory name is prepended to the given path with
filepath.Join():
https://github.com/golang/go/blob/1724077b789ad92972ab1ac03788389645306cbb/src/os/exec/lp_windows.go#L84
The filepath.Join() function ignores empty arguments, so this
results in an incorrect filename of ".". All potential executable
file extensions from the PATHEXT environment variable (or from a
fixed list if that variable is not defined) are then appended to
this filename, including their leading dot separator characters,
thus producing filenames like "..com" and "..exe":
https://github.com/golang/go/blob/1724077b789ad92972ab1ac03788389645306cbb/src/os/exec/lp_windows.go#L46-L50
Should a file with one of these names exist in the current working
directory, its name will be returned, which means that it will be
executed instead of the command we expected to run. This is
obviously undesirable and presents a risk to users.
(Note that batch files named "..bat" and "..cmd" will also be found
in the same manner, but they will not actually be executed due to an
undocumented feature of the Windows API's family of CreateProcess*()
functions, which are used by Go to spawn processes. When passed an
lpApplicationName argument ending with a ".bat" or ".cmd" extension,
the CreateProcess*() functions appear to instead execute "cmd.exe"
and construct a "/c" command string from the lpCommandLine argument.
The value of that argument is set using the full command line we are
attempting to execute, and as such its first element is the actual
name of the executable we intended to run; therefore, the command
interpreter attempts to run the executable as a batch script and
fails, and the "..bat" or "..cmd" file is effectively ignored.)
To recap, when Git LFS attempts to execute a program on Windows,
if the executable is not found anywhere in PATH but does exist in
the current working directory, then when we call exec.Command()
Go's internal LookPath() function will find the executable and not
set the internal lookPathErr flag:
https://github.com/golang/go/blob/1724077b789ad92972ab1ac03788389645306cbb/src/os/exec/exec.go#L174-L179
Since we do not want to run executables in the current working
directory, we subsequently run our own LookPath() function, which
we use to reset the cmd.Path field. However, when our LookPath()
returns an empty string, we do not detect that and instead set
cmd.Path to that value. Then when we ask Go to run the command,
because lookPathErr is nil, it proceeds, and the empty path causes
it to find and run the first matching file in the working directory
named "..com" or "..exe" (or any similar name with an executable
file extension except for "..bat" and "..cmd").
We can prevent this behaviour by detecting when our LookPath()
function returns an error and propagating it upwards to all
callers of our subprocess.ExecCommand() function. We also add
checks for this error at appropriate points and log or report
the error as necessary.
One particular circumstance of note occurs when a user has a
Cygwin-installed "uname" in their PATH but not "cygpath",
but "cygpath.exe" does exist in their current working directory.
Then we will attempt to execute "cygpath" because we use the
presence of "uname" as an indication that Cygwin is fully installed.
Should a "..exe" or similar file also be present in the working
directory, then it will be executed instead of "cygpath.exe".
As with all other instances where we call subprocess.ExecCommand(),
in tools.translateCygwinPath() we will now check for a returned
error before trying to actually execute "cygpath". Unlike many
of the other cases, though, we do not need to report the error in
this one; instead, we simply return the current path from
translateCygwinPath() instead of canonicalizing it, just as we do
already if the "cygpath" executable fails for some reason.
Finally, we add a new test to t/t-path.sh which checks for the
incorrect execution of a "..exe" binary on Windows when "git.exe"
is not found in PATH but does exist in the current working
directory. This test passes when run with a Git LFS binary that
includes the remediations from this commit, and fails otherwise.
For our "malicious" binary named "..exe" we make use of the
lfstest-badpathcheck test helper we added in a previous commit.
We only run this test on Windows because the underlying bug in
Go is Windows-specific as it depends on path extensions from
PATHEXT being appended to the file name ".".
Co-authored-by: brian m. carlson <bk2204@github.com>
2022-03-29 06:16:16 +00:00
|
|
|
cmd, err := ExecCommand(name, args...)
|
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
return Output(cmd)
|
2017-10-26 01:46:36 +00:00
|
|
|
}
|
2016-03-02 15:16:06 +00:00
|
|
|
|
2017-10-26 01:46:36 +00:00
|
|
|
func Output(cmd *Cmd) (string, error) {
|
|
|
|
out, err := cmd.Output()
|
2016-04-28 21:12:33 +00:00
|
|
|
|
2016-04-26 23:24:00 +00:00
|
|
|
if exitError, ok := err.(*exec.ExitError); ok {
|
2019-10-31 09:17:26 +00:00
|
|
|
errorOutput := strings.TrimSpace(string(exitError.Stderr))
|
2016-04-26 23:24:00 +00:00
|
|
|
if errorOutput == "" {
|
|
|
|
// some commands might write nothing to stderr but something to stdout in error-conditions, in which case, we'll use that
|
|
|
|
// in the error string
|
2017-10-26 01:46:36 +00:00
|
|
|
errorOutput = strings.TrimSpace(string(out))
|
|
|
|
}
|
|
|
|
|
|
|
|
ran := cmd.Path
|
|
|
|
if len(cmd.Args) > 1 {
|
|
|
|
ran = fmt.Sprintf("%s %s", cmd.Path, quotedArgs(cmd.Args[1:]))
|
2016-04-26 23:24:00 +00:00
|
|
|
}
|
2021-12-14 17:27:28 +00:00
|
|
|
formattedErr := errors.New(tr.Tr.Get("error running %s: '%s' '%s'", ran, errorOutput, strings.TrimSpace(exitError.Error())))
|
2016-04-26 23:24:00 +00:00
|
|
|
|
|
|
|
// return "" as output in error case, for callers that don't care about errors but rely on "" returned, in-case stdout != ""
|
|
|
|
return "", formattedErr
|
2016-03-02 15:16:06 +00:00
|
|
|
}
|
|
|
|
|
2017-10-26 01:46:36 +00:00
|
|
|
return strings.Trim(string(out), " \n"), err
|
|
|
|
}
|
|
|
|
|
2018-09-14 22:28:28 +00:00
|
|
|
var shellWordRe = regexp.MustCompile(`\A[A-Za-z0-9_@/.-]+\z`)
|
2018-09-14 21:50:09 +00:00
|
|
|
|
2018-09-14 22:46:17 +00:00
|
|
|
// ShellQuoteSingle returns a string which is quoted suitably for sh.
|
|
|
|
func ShellQuoteSingle(str string) string {
|
|
|
|
// Quote anything that looks slightly complicated.
|
|
|
|
if shellWordRe.FindStringIndex(str) == nil {
|
|
|
|
return "'" + strings.Replace(str, "'", "'\\''", -1) + "'"
|
|
|
|
}
|
|
|
|
return str
|
|
|
|
}
|
|
|
|
|
2018-09-14 21:50:09 +00:00
|
|
|
// ShellQuote returns a copied string slice where each element is quoted
|
|
|
|
// suitably for sh.
|
|
|
|
func ShellQuote(strs []string) []string {
|
|
|
|
dup := make([]string, 0, len(strs))
|
|
|
|
|
|
|
|
for _, str := range strs {
|
2018-09-14 22:46:17 +00:00
|
|
|
dup = append(dup, ShellQuoteSingle(str))
|
2018-09-14 21:50:09 +00:00
|
|
|
}
|
|
|
|
return dup
|
|
|
|
}
|
|
|
|
|
2018-09-14 22:31:39 +00:00
|
|
|
// FormatForShell takes a command name and an argument string and returns a
|
|
|
|
// command and arguments that pass this command to the shell. Note that neither
|
|
|
|
// the command nor the arguments are quoted. Consider FormatForShellQuoted
|
|
|
|
// instead.
|
|
|
|
func FormatForShell(name string, args string) (string, []string) {
|
|
|
|
return "sh", []string{"-c", name + " " + args}
|
|
|
|
}
|
|
|
|
|
|
|
|
// FormatForShellQuotedArgs takes a command name and an argument string and
|
|
|
|
// returns a command and arguments that pass this command to the shell. The
|
|
|
|
// arguments are escaped, but the name of the command is not.
|
|
|
|
func FormatForShellQuotedArgs(name string, args []string) (string, []string) {
|
|
|
|
return FormatForShell(name, strings.Join(ShellQuote(args), " "))
|
|
|
|
}
|
|
|
|
|
2022-04-20 20:47:35 +00:00
|
|
|
func FormatPercentSequences(pattern string, replacements map[string]string) string {
|
|
|
|
s := new(strings.Builder)
|
|
|
|
state := 0
|
|
|
|
for _, r := range pattern {
|
|
|
|
if state == 0 && r == '%' {
|
|
|
|
state = 1
|
|
|
|
continue
|
|
|
|
} else if state == 1 {
|
|
|
|
state = 0
|
|
|
|
if r == '%' {
|
|
|
|
s.WriteRune('%')
|
|
|
|
} else if val, ok := replacements[string([]rune{r})]; ok {
|
|
|
|
s.WriteString(ShellQuoteSingle(val))
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
s.WriteRune(r)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return s.String()
|
|
|
|
}
|
|
|
|
|
2017-10-26 01:46:36 +00:00
|
|
|
func Trace(name string, args ...string) {
|
|
|
|
tracerx.Printf("exec: %s %s", name, quotedArgs(args))
|
|
|
|
}
|
|
|
|
|
|
|
|
func quotedArgs(args []string) string {
|
|
|
|
if len(args) == 0 {
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
|
|
|
quoted := make([]string, len(args))
|
|
|
|
for i, arg := range args {
|
|
|
|
quoted[i] = fmt.Sprintf("'%s'", arg)
|
|
|
|
}
|
|
|
|
return strings.Join(quoted, " ")
|
2016-03-02 15:16:06 +00:00
|
|
|
}
|
|
|
|
|
Support submodule.recurse = true
Git’s configuration option submodule.recurse makes it more convenient to
use submodules. If set to true, top-level checkouts will recurse into
all submodules. Additionally, Git will pass an environment variable
called GIT_INTERNAL_SUPER_PREFIX to the respective submodule’s path
relative to its parent repository to each child process, including git
lfs filter-process.
In turn, Git LFS spawns a couple of Git processes, for instance, when
checking the minimum required Git version, reading Git configuration
values, or obtaining the object name of a commit with git rev-parse.
In the current implementation, Git LFS would forward the environment
variable GIT_INTERNAL_SUPER_PREFIX to Git unchanged. This is problematic
because the presence of this environment variable will make Git behave
as if the command-line option --super-prefix had been passed to the
respective Git command. However, many commands don’t support the
--super-prefix command-line option. This includes git version, git
config, and git rev-parse. Consequently, these Git processes, as spawned
by Git LFS, would immediately fail with a usage error.
In short, users of submodule.recurse = true would get errors when
working in repositories with at least one Git-LFS-enabled submodule.
This patch fixes the issue by removing the GIT_INTERNAL_SUPER_PREFIX
environment variable from the environment Git LFS passes to Git child
processes.
2020-03-10 00:13:32 +00:00
|
|
|
// An env for an exec.Command without GIT_TRACE and GIT_INTERNAL_SUPER_PREFIX
|
2016-03-02 15:16:06 +00:00
|
|
|
var env []string
|
2020-10-02 16:50:06 +00:00
|
|
|
var envMu sync.Mutex
|
2016-03-02 15:16:06 +00:00
|
|
|
var traceEnv = "GIT_TRACE="
|
|
|
|
|
Support submodule.recurse = true
Git’s configuration option submodule.recurse makes it more convenient to
use submodules. If set to true, top-level checkouts will recurse into
all submodules. Additionally, Git will pass an environment variable
called GIT_INTERNAL_SUPER_PREFIX to the respective submodule’s path
relative to its parent repository to each child process, including git
lfs filter-process.
In turn, Git LFS spawns a couple of Git processes, for instance, when
checking the minimum required Git version, reading Git configuration
values, or obtaining the object name of a commit with git rev-parse.
In the current implementation, Git LFS would forward the environment
variable GIT_INTERNAL_SUPER_PREFIX to Git unchanged. This is problematic
because the presence of this environment variable will make Git behave
as if the command-line option --super-prefix had been passed to the
respective Git command. However, many commands don’t support the
--super-prefix command-line option. This includes git version, git
config, and git rev-parse. Consequently, these Git processes, as spawned
by Git LFS, would immediately fail with a usage error.
In short, users of submodule.recurse = true would get errors when
working in repositories with at least one Git-LFS-enabled submodule.
This patch fixes the issue by removing the GIT_INTERNAL_SUPER_PREFIX
environment variable from the environment Git LFS passes to Git child
processes.
2020-03-10 00:13:32 +00:00
|
|
|
// Don't pass GIT_INTERNAL_SUPER_PREFIX back to Git. Git passes this environment
|
|
|
|
// variable to child processes when submodule.recurse is set to true. However,
|
|
|
|
// passing that environment variable back to Git will cause it to append the
|
|
|
|
// --super-prefix command-line option to every Git call. This is problematic
|
|
|
|
// because many Git commands (including git config and git rev-parse) don't
|
|
|
|
// support --super-prefix and would immediately exit with an error as a result.
|
|
|
|
var superPrefixEnv = "GIT_INTERNAL_SUPER_PREFIX="
|
|
|
|
|
2020-10-02 16:50:06 +00:00
|
|
|
func fetchEnvironment() []string {
|
|
|
|
envMu.Lock()
|
|
|
|
defer envMu.Unlock()
|
|
|
|
|
|
|
|
return fetchEnvironmentInternal()
|
|
|
|
}
|
|
|
|
|
|
|
|
// fetchEnvironmentInternal should only be called from fetchEnvironment or
|
|
|
|
// ResetEnvironment, who will hold the required lock.
|
|
|
|
func fetchEnvironmentInternal() []string {
|
|
|
|
if env != nil {
|
|
|
|
return env
|
|
|
|
}
|
|
|
|
|
2016-03-02 15:16:06 +00:00
|
|
|
realEnv := os.Environ()
|
|
|
|
env = make([]string, 0, len(realEnv))
|
|
|
|
|
|
|
|
for _, kv := range realEnv {
|
Support submodule.recurse = true
Git’s configuration option submodule.recurse makes it more convenient to
use submodules. If set to true, top-level checkouts will recurse into
all submodules. Additionally, Git will pass an environment variable
called GIT_INTERNAL_SUPER_PREFIX to the respective submodule’s path
relative to its parent repository to each child process, including git
lfs filter-process.
In turn, Git LFS spawns a couple of Git processes, for instance, when
checking the minimum required Git version, reading Git configuration
values, or obtaining the object name of a commit with git rev-parse.
In the current implementation, Git LFS would forward the environment
variable GIT_INTERNAL_SUPER_PREFIX to Git unchanged. This is problematic
because the presence of this environment variable will make Git behave
as if the command-line option --super-prefix had been passed to the
respective Git command. However, many commands don’t support the
--super-prefix command-line option. This includes git version, git
config, and git rev-parse. Consequently, these Git processes, as spawned
by Git LFS, would immediately fail with a usage error.
In short, users of submodule.recurse = true would get errors when
working in repositories with at least one Git-LFS-enabled submodule.
This patch fixes the issue by removing the GIT_INTERNAL_SUPER_PREFIX
environment variable from the environment Git LFS passes to Git child
processes.
2020-03-10 00:13:32 +00:00
|
|
|
if strings.HasPrefix(kv, traceEnv) || strings.HasPrefix(kv, superPrefixEnv) {
|
2016-03-02 15:16:06 +00:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
env = append(env, kv)
|
|
|
|
}
|
2020-10-02 16:50:06 +00:00
|
|
|
return env
|
|
|
|
}
|
|
|
|
|
|
|
|
// ResetEnvironment resets the cached environment that's used in subprocess
|
|
|
|
// calls.
|
|
|
|
func ResetEnvironment() {
|
|
|
|
envMu.Lock()
|
|
|
|
defer envMu.Unlock()
|
|
|
|
|
|
|
|
env = nil
|
|
|
|
// Reinitialize the environment settings.
|
|
|
|
fetchEnvironmentInternal()
|
2016-03-02 15:16:06 +00:00
|
|
|
}
|