Possible deprecation coming

[joemiller]

I've started to migrate more of my creds usage to pass.

I mainly meant for creds to support the "set environment variable use case". pass can be used for this as well as other cases.

Here is a one-liner I used to convert my creds data to pass under a creds directory, eg: pass show creds/foo

for i in $(creds list | awk '/^-/ {print $2}'); do creds set "$i" | pass insert "creds/$i" -m ; done

[tjanez]

Hey!

Thanks for creating creds, I'm a long-time user and I've also packaged it for Fedora.

I also use pass as my main password manager, so I understand your point.

One thing I'm curious though is how I could export multiple secrets as environment variables similar to:

creds run backup -- mybackup-script ...

without creating an ad-hoc Bash script (using export FOO_SECRET=$(pass sevices/foo) lines) for each project/environment I have?

[joemiller]

When I converted from creds to pass I ended up porting over most of my secrets in a format similar to how I stored them in creds, including the export statements.

eg:

$ pass ls
Password Store
└── creds
    ├── atlas
    ├── aws_personal
    ├── circleci
    ├── github-generalusage

$ pass show creds/aws_personal
 export CLOUD_PROVIDER=EC2
 export AVAILABILITY_ZONE=us-east-1d
 export AMAZON_ACCESS_KEY=...
 export AMAZON_SECRET_KEY=...

I can set all of those in the environment with a single call:

$ eval "$(pass show creds/aws_personal)"
$ echo $CLOUD_PROVIDER
EC2

[tjanez]

Aha, I see, thanks for your explanation.

One thing that is perhaps a little tricky and error-prone is that one has to manually prefix all export statements with a single whitespace character to prevent these statements (and secrets) from being stored in the command history with Bash or Zsh.

Also, I find eval "$(pass show creds/aws_personal)" a bit harder to type manually than, e.g. creds run aws_personal -- some-cmd.