1. 24
  1. 4

    I was hoping there would be more around the project organization. One thing I’ve struggled with in particular is dealing with secret values such as tokens or passwords. I often end up doing one thing and that’s reading it from environment variables, but that can be cumbersome for the more non-technical folks on my team to use my tools.

    1. 6

      Everyone will fight for their preferred method, but I’ll mention some of the more common ones:

      • Have your app go get it’s own secret via some command you run(say via a config option) that returns the password via stdout. You just suck it in, and make generating the secret some other person’s problem.

      • Have your app read it from a file or file descriptor (i.e. a pipe or an actual file or stdin) The actual file could be on an in-memory file system so it doesn’t live past reboots

      • pass it via an ENV variable, this almost ensures a leak vector, since /proc and loads of debugging tools make ENV variables of processes quite easy to see.

      • Hide it in some blessed “tool”, something like hashicorp vault, gpg, 1password or whatever suits your fancy and only support said tool.

      I put them basically in my preferred order, but usually what I do is a mix of 1 & 2. I.e. by default I accept the password via STDIN, but have an option to run some command to get it, the command is defined by a config option.

      1. 2

        #1 is the best generic method to implement #4 - those blessed tools should have get-secret commands. Bonus points if they verify their parent process.

        1. 1

          Agreed. Sadly what I see in the wild is almost always #4(blessed tool) as the only option.

          I like my mix of 1 and 2: assume STDIN if nothing is configured. If something is configured, then all other options are instantly available, want to read in a file, the cmd would be: cat <path to file>, want to get it from the ENV, the cmd would be echo $ENVVAR, some blessed tool: vault read <path to vault secret>, etc.

      2. 3

        We released a cross-platform, multi-language open solution for this with reference implementations in rust and C#: https://neosmart.net/blog/2020/securestore-open-secrets-format/

        1. 1

          I sadly see this all the time, code requiring some specific tool. I much prefer a config option of a cmd to run to get the secret. This way the code will work for basically any blessed tool, and not be tied to some particular whatever, that might go unsupported tomorrow, have a security leak or $CORP switches vendors/tools/etc.