About Archive Tags RSS Feed


Password store plugin: env

4 May 2021 18:00

Like many I use pass for storing usernames and passwords. This gives me easy access to credentials in a secure manner.

I don't like the way that the metadata (i.e. filenames) are public, but that aside it is a robust tool I've been using for several years.

The last time I talked about pass was when I talked about showing the age of my credentials, via the integrated git support.

That then became a pass-plugin:

  frodo ~ $ pass age
  6 years ago GPG/root@localhost.gpg
  6 years ago GPG/steve@steve.org.uk.OLD.gpg
  4 years, 8 months ago Domains/Domain.fi.gpg
  4 years, 7 months ago Mobile/dna.fi.gpg
  1 year, 3 months ago Websites/netlify.com.gpg
  1 year ago Financial/ukko.fi.gpg
  1 year ago Mobile/KiK.gpg
  4 days ago Enfuce/sre.tst.gpg

Anyway today's work involved writing another plugin, named env. I store my data in pass in a consistent form, each entry looks like this:

   username: steve
   password: secrit
   site: http://example.com/login/blah/
   # Extra data

The keys vary, sometimes I use "login", sometimes "username", other times "email", but I always label the fields in some way.

Recently I was working with some CLI tooling that wants to have a username/password specified and I patched it to read from the environment instead. Now I can run this:

     $ pass env internal/cli/tool-name
     export username="steve"
     export password="secrit"

That's ideal, because now I can source that from within a shell:

   $ source <(pass env internal/cli/tool-name)
   $ echo username

Or I could directly execute the tool I want:

   $ pass env --exec=$HOME/ldap/ldap.py internal/cli/tool-name
   you are steve

TLDR: If you store your password entries in "key: value" form you can process them to export $KEY=$value, and that allows them to be used without copying and pasting into command-line arguments (e.g. "~/ldap/ldap.py --username=steve --password=secrit")



Comments on this entry

icon anarcat at 20:34 on 4 May 2021

did you forget to link to the source of this wonderful tool?

icon Steve Kemp at 20:40 on 4 May 2021

Now you say that I realize I did!

I've published it, along side some related stuff here:

Find the "env.bash" script beneath "extensions".

icon Joel Johnson at 22:19 on 4 May 2021

I'm curious as to what benefit you get by having the password separately labeled instead of as the implicit first field in the file as is the general pass assumption?

icon Steve Kemp at 06:26 on 5 May 2021

I'm not sure there is a particular benefit, though now I'm using the tool for scripting the explicitness is nice.

I just started doing this when I migrated over (from pwsafe), because it felt natural (and that system was explicit with the idea of named fields).

Most of my entries have login/username, password, and URL. Sometimes I have a recovery-code or two, or maybe a couple of comments. Nothing unusual.

icon Paul Wise at 11:16 on 6 May 2021

You might want to add a way to pass other arguments to the command being executed, maybe something like:

$ pass env internal/cli/tool-name --exec $HOME/ldap/ldap.py --argument you are steve

icon Michael Schaffner at 17:29 on 11 June 2021

Hi, great work - thanks..

however, if i use something like RESTIC_REPOSITORY: s3:https://s3.eu-central-1.wasabisys.com, all the colons get stripped. So i replaced:

         pwd=$(echo $line | awk -F: '{$1=""; print $0}' | tr -d \ )


         pos=$(expr index "$line" ":")
         pwd=$(echo ${line:$pos} | tr -d \ )

I am sure there is a better way to do this (since i know next to nothing about shell scripting), but you get the point!

icon Steve Kemp at 22:07 on 11 June 2021

Thanks for the comment, Michael. I'll include a fix for the problem shortly :)