Teller: Universal secret manager, never leave your terminal to use secrets

pass here is most likely: https://www.passwordstore.org/

Which is gpg based and extremely scriptable. You can pipe it into your platforms virtual/emualted keyboard like xdotool on linux to get "universal" integration.

My local dev environment variables are not usually critical (e.g. they are test Stripe secrets, dev-S3 access, etc) So I’ve never really made an effort to keep them secure. They’re just in a plain text .env file.

That said, your solution is cool. It makes me want to find a reason to use it!

I have written a one-liner that exports dot-env files stored in `pass` into the current shell for those projects that have a lot of secrets. I don't use `direnv` though, just close the shell (or all of a project's tabs/windows) when done. Similarly, for Kubernetes, I just export KUBECONFIG by means of an `fzf` script for just that shell. I also keep a terminal window and virtual desktop per project. I have access to too many projects for any secrets or contexts to be set by default.

As a consultant, simple solutions that allow for quickly (manual) setting and getting rid of environments when done have worked best over the years. Using dedicated windows and desktops helps your brain to use "physical" location to keep you from messing things up. Obviously your mileage may vary if you mostly work on just one project at a time.

Question: do you share this password store between computers, and if so, what method do you use?

Finally decided to try out pass, it's pretty slick and makes a lot of sense:

  $ pass init 1234ABCDEBEEF # create password store using GPG key ID

  $ pass git init

  $ pass git remote add origin https://github.com/foo/bar.git

  $ pass generate A_Folder/An_ID 22
  /Users/itsme/.password-store/A_Folder
  [main 1959acb] Add generated password for A_Folder/An_ID.
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 A_Folder/An_ID.gpg
  The generated password for A_Folder/An_ID is:
  |tfj!eU8e/r%DF|2@fJ`ZH

  $ pass git push -u --all

  $ pass ls
  Password Store
  └── A_Folder
      └── An_ID

It always bothered me that the AWS CLI relies on plaintext credentials (in a well-known location too, at ~/.aws!). These days my AWS credentials are stored encrypted in pass, the only field in the credentials file is `credential_process` which asks for the values from pass, and that credentials file itself is an auto-generated temporary file (set in the appropriate `AWS_FOO` env var)

The project seems to use DocToc to generate the table of contents, and that's what that package.json is in there for. Precisely because of the issues with the NPM ecosystem, it's good that they made sure to add the lockfile.

Looks like those deps are for doctoc

The lockfile mitigates supply chain attacks to a large extent. Much like any other language’s package ecosystem.

A “teller” tells things.

Apparently `security` is exactly that

I have a simple workflow I use for ENV vars. Another comment noted a script written which likely does more but I haven’t fully read the code. Here’s my simple workflow in case someone is interested.

Create a DB in MacOS keychain called envs:

  security create-keychain -P envs

Then use these shell functions:

  which get-env
  get-env () {
     security find-generic-password -s "$1" -w envs
   }

  which add-env
  add-env () {
      security add-generic-password -a "$USER" -s "$1" -w "$2" envs
   }

Then add one via:

  add-env ENVNAME SECRET

Example using it:

  ENVVAR=“$(get-env ENVNAME)” ./script.sh