Matt: > I don't have any thoughts on the pam module, but I make use of some > scripts that rely on pass as well. For my use case I just raised the > TTL setting of gpg-agent to match an eight hour work day or eight hour > evening period and ran with it. Feels fairly natural to "log in" to > the agent once a day at the first use.
Doesn't this sort of defeat the purpose of using pass? I mean if it's always decryptable then is it really useful to have it encrypted in the first place (assuming you have full disk encryption set up)? I may be missing something crucial here so please let me know. Grant: > Can you re-architect this as a (pseudo) daemon so that you unlock it > once (or at least a LOT less often) and it stores the necessary > information in memory for subsequent re-use? This seems like the lesser of all evils to me. As I understand, you're suggesting that I lend the email password to the daemon at start and only have that password stored in memory instead of my actual gpg password, is that correct? > Could you re-configure things so that (a copy of) the requisite password > is accessible via a different set of GPG credentials specific to the > process that you're running? Then you could probably have just that set > of GPG credentials unprotected so that the script could use them as it > is today. Again, I may be missing something here, but does having your GPG credentials unprotected offer any real protection? > If neither of these options were possible I'd look into something like a > TPM and / or Yubikey wherein I could offload some of the GPG to it so > that the decryption key is physically tied to the source computer /and/ > *where* *it* *can't* *be* *copied*. I guess this is where I'll eventually be heading towards. By the way, thanks to both of you for your thoughts! -- All the best, Efe The funny quote of this email is trivial and left as an exercise.
signature.asc
Description: PGP signature
