It's not as powerful but I use direnv a lot and when I add secrets I simply do this with my personal password manager;

    export secret=$(pass secret/foo)

I'm asked for my GPG password once when I enter the project dir, and when I exit the project dir it's cleared from my environment. Pretty decent and cheap solution.

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

I use it as a git repo and share it with an encrypted USB drive that I use for backups.

I use syncthing to share it, it is part of a folder structure I install using Stow.

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.

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.

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!

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)

I find it strange. Github says 99% of the code is Go and 1% Makefile. Yet I see a package.json and a yarn.lock. I am not sure to which degree this relies on the NPM ecosystem. Probably I wouldn't want to use it for secrets, if it uses NPM ecosystem in any runtime processes. Perhaps the NPM stuff is merely for development utils?

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

I have a few solutions for this. The 1password CLI, using the macOS keychain through CLI (refer to command ‘security’), and AWS SSM through the AWS CLI tool (for infrastructure secrets).

Novops - https://github.com/PierreBeucher/novops - is a similar tools with active maintenance, more flexibility (generic interface, support plain strings and different secrets providers). Teller is nice but lacks some features Novops aims to provide.

Funny name, assuming it refers to the magician who does not speak

A “teller” tells things.

I think he meant as in Penn and ...

I’m referring to going for the most closely adjacent explanation, the mundane noun which represents something which tells something, like secrets. Since I apparently have to spell everything out.

I get your theory, but I think the other one is more likely. A Magician is someone who keeps secrets, and Teller is a particularly good example for this, since he doesn't speak at all in the act.

It could also be both.

but it seems dead, is it stable enough to use?

I would love it if I could just use my Mac's Keychain Access from the command line

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

this is gold, thank you

Happy it was helpful! Neglected to mention that your entry with the password will be stored in the shell history. You can prefix a space and have those commands (prefixed with a space) to be ignored in shell history. Alternative is to use `read` to pass the password in and hide the input. I can rewrite it for you if that’ll help.

Apparently `security` is exactly that

Yes, but it's super awkward to actually use day to day

I've got something of a wrapper script at https://github.com/bbkane/dotfiles/blob/8573e44d0f9fb5ddcbdc...

Its getting a bit too unwieldy to stay as a single Python file and add tests and features, so I'm rewriting it in Go (nothing useful yet though)