when converting from fetchmail to mpop, i didn't want to have to enter passwords or gpg passphrases all the time. these two programs (credeface, which is more general, and credepass, which uses credeface) give me that ability. the idea is to access a file with some form of encrypted password once a day or so, say, and then store that password, now unencrypted, in a running instance of git's credential cache (note the two links; here's a third), allowing the unencrypted password to be accessed as needed to download e-mail while, at the same time, trying to keep the unencrypted password from ever being present in the file system.
(with fetchmail, i left fetchmail running in "daemon" mode, so i only entered passwords for my mailboxes on startup.)
usage: credeface [-h] [--username USERNAME] [--host HOST] [--yes-tty]
[--timeout TIMEOUT] [--gitcredcmd GITCREDCMD]
[--gitcredsocket GITCREDSOCKET]
{get,store,exit}
the operation is one of: get, store, exit:
the other options:
usage: credepass [-h] --username USERNAME --host HOST [--yes-tty]
[--timeout TIMEOUT]
credepass uses credeface to look up the password for host HOST and username USER in the credential cache. if the password is found in the credential cache, it is printed on stdout. if credeface doesn't find the password, then credepass uses pass(1) to obtain the password and, if successful, installs that password (for host HOST and username USERNAME) in the credential cache (via credeface) and prints it on stdout.
sometimes i, at least, have mutliple mailboxes on a given remote host (one for normal e-mail, one for high-volume e-mail lists, say). Lamport's "one extra level of indirection" comes in handy here: there's a facility to allow sed(1) scripts in ~/.credeface/place/host.sed and ~/.credeface/place/username.sed. i.e., an entry like
s/^wonder_lots$/wonder/
in username.sed would change a username "wonderlots" to "wonder", whereas
s/^lotsofmail.example.com$/example.com/
in host.sed would change the host name "lotsofmail.example.com" to "example.com".
when looking up the password in pass(1), credepass has to make some assumptions on where in pass(1)'s tree the password for host HOST and username USERNAME will exist. to help with this, one can also have a sed script file ~/.credeface/place/passpath.sed. the input to sed using this file looks like
HOST/USERNAME
so, e.g., using the above two sed scripts (username.sed, host.sed), running
credepass --username wonder_lots --host lotsofmail.example.com
would, if the password were not found in the credentials cache, invoke the sed(1) script (and, later, pass(1), if the sed(1) script didn't do anything) with
example.com/wonder
if, in this example, there were also a "passpath.sed" script in the appropriate directory, with this contents
sX\([^/]*\)/\(.*\)X\2/\1X
then, the credepass would have pass(1) look instead for
wonder/example.com
as an example of usage, here are the relevant lines i have in `~/.mpoprc`:
# remote user name
user wonder
# use passwordeval
passwordeval credepass --username wonder --host MAILSERVER.example.com --timeout 60000
# second account, inherits from above
account wonder_lots : wonder
user wonder_lots@example.com
passwordeval credepass --username wonder --host MAILSERVER.example.com --timeout 60000