With exec.Cmd, how do you keep a loaded secret out of the child process's environment?

## The default is inheritance `os/exec` describes `Cmd.Env` as the environment of the process: if it is nil, the new process uses the current process's environment. That single sentence is the whole trap. A pattern this leaf cares about — a small entrypoint binary that authenticates, fetches or decrypts credentials and then starts the real application — will, if you write the obvious `exec.Command(...).Run()`, pass every credential the entrypoint loaded into the child's environment. The child may be a third-party binary, a shell script, a language runtime that prints its environment on startup, or something whose crash handler attaches the environment to a report. Nothing in your code says "give it the database password", and that is exactly why it survives review. ## Making the child's environment explicit `Cmd.Environ()` returns a copy of the environment the command would run with as currently configured, which is the right starting point for a filter: ```go cmd := exec.Command("/usr/local/bin/app") keep := make([]string, 0, 16) for _, kv := range cmd.Environ() { if strings.HasPrefix(kv, "DB_PASSWORD=") { continue } keep = append(keep, kv) } cmd.Env = keep ``` A stricter version is an allowlist: start from an empty slice and add the handful of variables the child genuinely needs (`PATH`, `HOME`, `TZ`, its own configuration), so a new secret added to the parent's environment next quarter is excluded by default rather than by remembering to extend a denylist. If you replace the process outright rather than forking, the same discipline applies — `syscall.Exec` takes the environment as an explicit argument, so there is no inheritance to forget. ## Three adjacent mistakes **Moving it to argv.** `exec.Command(bin, "--token", tok)` looks like it avoids the environment, and it is worse: command lines are readable by other processes on the same host and are captured by process accounting, audit logs and monitoring agents. Neither argv nor the environment is a private channel. **Trusting os.Unsetenv to erase it.** `os.Unsetenv("DB_PASSWORD")` removes the key from the copy of the environment Go maintains, so later `os.Getenv` and `os.Environ` calls — and children spawned afterwards — do not see it. It does not rewrite the block the kernel recorded when this process was executed, which on Linux remains visible through `/proc/<pid>/environ` to a process running as the same user. Unsetting is a tidy-up, not an erasure, and the value is still a `string` in your heap either way. **Passing it on stdin without thinking about the failure path.** Handing the secret over a pipe (`cmd.Stdin`, or an extra file descriptor via `cmd.ExtraFiles`) is a genuinely better channel than the environment, because it is point-to-point and leaves no ambient copy. Just make sure the child actually consumes it, and that a child that exits early does not leave the parent blocked on a write. ## The shape to argue for The arrangement that holds up in a postmortem is: the secret is delivered as a file with restrictive permissions; the process reads it with `os.ReadFile` into a `[]byte` at startup; the environment carries only the *path*; anything the process launches gets an explicitly constructed environment; and the value itself is a named type whose `String` method masks it so a struct dumped into an error cannot spill it. Each of those closes a different diagnostic path — the environment dump, the inherited child, the crash report — and the reason to do all four is that the one you skip is the one that appears in the incident. When you are the person writing that postmortem, the question you will be asked is not "was the secret encrypted" but "how many processes and how many files could see it, and who decided that". An explicit `cmd.Env` is a one-line answer to a large part of it.