On Wed, 2023-03-01 at 15:38 -0700, Grant Taylor wrote: > 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?
You just described gpg-agent, the core of what Efe (OP) is meddling with :) > 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. > > 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*. Since pass, the utility that OP is using in their script, is built around GPG, of course there have been some spinoffs, using other encryption methods. Personally setting the gpg-agent timeout higher and having good physical security works for my use case, but everyone has a different situation. If I worked in an office still, I think I would have a physical GPG-based key solution, though I will admit I'm not read up on which ones are the tops right now. Efe, it may be useful to review the pass mailing list archives[1] for some other ideas. I don't think you're trying to solve a snowflake problem here, but pam tie-ins doesn't feel quite right for a solution either. 1: https://lists.zx2c4.com/pipermail/password-store/
