exec-env/exec-file signal handling might be broken

Hey folks,

We've encountered some issues after we started using exec-file for our software. For example, py.test being run with exec-file inside a docker container would terminate on sigterm immediately, whereas normally it prints test failures first, which is quite annoying.

I'm sorry that I can't provide a minimal reproducing case as we just started exporting secrets before running our process "naked", which solved those problems for us, but after looking through the sources my theory to why that's happening is as follows:

• docker starts a docker container with sops as its main process
• sops spawns our process in a subprocess here https://github.com/mozilla/sops/blob/66043e71a81787d6513bc2e5505a29aac67dc6f1/cmd/sops/subcommand/exec/exec_unix.go#L15
• the subprocess is in the same process group, which means both sops and the subprocess will receive incoming signals
• we ask Docker to send sigterm (or sighup)
• Docker sends sigterm (or sighup) to that process group
• sops exits immediately
• docker container is terminated immediately and no stdout is sent to the host

…which sounds similar to the problem someone was having in this blog post https://bigkevmcd.github.io/go/pgrp/context/2019/02/19/terminating-processes-in-go.html

If my understanding is correct, it's a subtle problem for a lot of software using sops. The solution would be for sops to spawn subprocess into a separate process group and pass signals on manually, waiting for the process to finish.

Thank your for your awesome piece of software!

Start with cmd/sops/subcommand/exec/exec_unix.go, the subprocess entry point referenced in the report, and compare exec-file behavior with the Docker and py.test signal scenario described. Reproduce the termination sequence if possible; done means the child process can finish and its output is preserved when the container receives SIGTERM or SIGHUP.