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/ |