| 1 |
On 3/1/23 7:10 AM, efeizbudak wrote: |
| 2 |
> Hi all, |
| 3 |
|
| 4 |
Hi, |
| 5 |
|
| 6 |
> I let mutt-wizard set a cron job which takes my password out |
| 7 |
> of pass, logs into the email server and fetches my mail every |
| 8 |
> 5 minutes. |
| 9 |
|
| 10 |
Can you re-architect this as a (pseudo) daemon so that you unlock it |
| 11 |
once (or at least a LOT less often) and it stores the necessary |
| 12 |
information in memory for subsequent re-use? |
| 13 |
|
| 14 |
> With this I have to unlock my key as frequently as the amount in |
| 15 |
> gpg-agent.conf's default-cache-ttl setting. |
| 16 |
|
| 17 |
:-/ |
| 18 |
|
| 19 |
> pam-gnupg has been suggested as a remedy to this problem but the |
| 20 |
> disclaimer on its page about dangerous bugs make me hesitant to use |
| 21 |
> it. What do you think about the security of it? It's only 500 SLOC |
| 22 |
> but I don't trust myself with reviewing the security of it. |
| 23 |
|
| 24 |
I don't relish the idea of giving something the keys to the kingdom. |
| 25 |
|
| 26 |
Could you re-configure things so that (a copy of) the requisite password |
| 27 |
is accessible via a different set of GPG credentials specific to the |
| 28 |
process that you're running? Then you could probably have just that set |
| 29 |
of GPG credentials unprotected so that the script could use them as it |
| 30 |
is today. |
| 31 |
|
| 32 |
If neither of these options were possible I'd look into something like a |
| 33 |
TPM and / or Yubikey wherein I could offload some of the GPG to it so |
| 34 |
that the decryption key is physically tied to the source computer /and/ |
| 35 |
*where* *it* *can't* *be* *copied*. |
| 36 |
|
| 37 |
I might also look into other authentication methods, e.g. TLS client |
| 38 |
certificate, so that the script can do what it needs to without needing |
| 39 |
to bother with GPG. |
| 40 |
|
| 41 |
|
| 42 |
|
| 43 |
-- |
| 44 |
Grant. . . . |
| 45 |
unix || die |
Archives