3 ms·

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'

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.

omeid2 3y ago
pass here is most likely: https://www.passwordstore.org/ 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.
christophilus 3y ago
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!
wvh 3y ago
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.
bloopernova 3y ago
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
- zilti 3y ago
  I use syncthing to share it, it is part of a folder structure I install using Stow.
- INTPenis 3y ago
  I use it as a git repo and share it with an encrypted USB drive that I use for backups.
chriswarbo 3y ago
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)

omeid2 3y ago

pass here is most likely: https://www.passwordstore.org/ 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.

christophilus 3y ago

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!

wvh 3y ago

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.

bloopernova 3y ago

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

zilti 3y ago
I use syncthing to share it, it is part of a folder structure I install using Stow.
INTPenis 3y ago
I use it as a git repo and share it with an encrypted USB drive that I use for backups.

chriswarbo 3y ago

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)