| 1 |
On Wed, 2023-03-01 at 15:38 -0700, Grant Taylor wrote: |
| 2 |
> Can you re-architect this as a (pseudo) daemon so that you unlock it |
| 3 |
> once (or at least a LOT less often) and it stores the necessary |
| 4 |
> information in memory for subsequent re-use? |
| 5 |
|
| 6 |
You just described gpg-agent, the core of what Efe (OP) is meddling |
| 7 |
with :) |
| 8 |
|
| 9 |
> Could you re-configure things so that (a copy of) the requisite password |
| 10 |
> is accessible via a different set of GPG credentials specific to the |
| 11 |
> process that you're running? Then you could probably have just that set |
| 12 |
> of GPG credentials unprotected so that the script could use them as it |
| 13 |
> is today. |
| 14 |
> |
| 15 |
> If neither of these options were possible I'd look into something like a |
| 16 |
> TPM and / or Yubikey wherein I could offload some of the GPG to it so |
| 17 |
> that the decryption key is physically tied to the source computer /and/ |
| 18 |
> *where* *it* *can't* *be* *copied*. |
| 19 |
|
| 20 |
Since pass, the utility that OP is using in their script, is built |
| 21 |
around GPG, of course there have been some spinoffs, using other |
| 22 |
encryption methods. Personally setting the gpg-agent timeout higher |
| 23 |
and having good physical security works for my use case, but everyone |
| 24 |
has a different situation. If I worked in an office still, I think I |
| 25 |
would have a physical GPG-based key solution, though I will admit I'm |
| 26 |
not read up on which ones are the tops right now. |
| 27 |
|
| 28 |
Efe, it may be useful to review the pass mailing list archives[1] for |
| 29 |
some other ideas. I don't think you're trying to solve a snowflake |
| 30 |
problem here, but pam tie-ins doesn't feel quite right for a solution |
| 31 |
either. |
| 32 |
|
| 33 |
1: https://lists.zx2c4.com/pipermail/password-store/ |
Archives