On Wed, 2023-03-01 at 09:10 -0500, efeizbudak wrote:

I let mutt-wizard set a cron job which takes my password out of pass,
logs into the email server and fetches my mail every 5 minutes. With
this I have to unlock my key as frequently as the amount in
gpg-agent.conf's default-cache-ttl setting.

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.

Disclaimer: I work from home and lock my computers when I'm away from
them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi all,

I let mutt-wizard set a cron job which takes my password out of pass,
logs into the email server and fetches my mail every 5 minutes. With
this I have to unlock my key as frequently as the amount in
gpg-agent.conf's default-cache-ttl setting. pam-gnupg has been suggested
as a remedy to this problem but the disclaimer on its page about
dangerous bugs make me hesitant to use it. What do you think about the
security of it? It's only 500 SLOC but I don't trust myself with
reviewing the security of it.

--
All the best,
Efe

The funny quote of this email is trivial and left as an exercise.

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEVwebaduP4RnpDeHTNg4/A+X8N/oFAmP/XMxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU3 MDc5QjY5REI4RkUxMTlFOTBERTFEMzM2MEUzRjAzRTVGQzM3RkEACgkQNg4/A+X8 N/oFkQ/8Cc6OMRRWnsTMnzSIJiumCRPEYi5hjRuKRLjvCRfT+og6eSATAAayMEY7 V1Z3iVezaaHeqMh0vffPnx3SjirGJQ3SdLJ3WtzgOpOks9fkTrs/wnGUM3aYKgWE 5dRkSqKEeUd5//jphQeATGZr4RQUazBhLbSbB6cHTC2ILxn/5V6q7acVpTOX79KC 1uZmbjJMpsN3zNurajYIUtStMYPFTVGuCVMLi3MlKgYz+yFP+T3Uc/ZIJa3QPV1A dz40CBbNoiXacuUzQGGUTKVdXNd1PJf4MyfMxviOz2Uv8OQUPOjq2h0vQPAv+IOS J8UT2mzcEfOf4FtREShR7E5oV4jAQjwGOVrye3UaonH7xLDXIU+vVfqCtSPt+Dp4 fDd8hLnmFaxlaLInyh/1VS2OX1OIJlYqf6FSZWGe2xkerFl2fZmWlcAcezXExGGx ICI/OVPwSjKvksGO4ViFuHEogzG7V2rUNjFeambpJmw3nYt9imwx0SWmKCC6AuN8 Q2jxowCFawFNLdU3g+YYipq2h8Lp4+AwMPkjyBERWgXNDq8+fntNoFU/RczPljC3 ZoAPb39NloZ9JRefmiMg3uFn8qIJteL100PLWTXuM6xDTd+bU+0Khw93iqAlJEdc 0XwXbdSJCtxgjwy6MeKAoSYNCdGs3B3dSkLCN

On 3/1/23 7:10 AM, efeizbudak wrote:

Hi all,

Hi,

I let mutt-wizard set a cron job which takes my password out
of pass, logs into the email server and fetches my mail every
5 minutes.

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?

With this I have to unlock my key as frequently as the amount in gpg-agent.conf's default-cache-ttl setting.

:-/

pam-gnupg has been suggested as a remedy to this problem but the
disclaimer on its page about dangerous bugs make me hesitant to use
it. What do you think about the security of it? It's only 500 SLOC
but I don't trust myself with reviewing the security of it.

I don't relish the idea of giving something the keys to the kingdom.

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*.

I might also look into other authentication methods, e.g. TLS client certificate, so that the script can do what it needs to without needing
to bother with GPG.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/2/23 6:48 AM, Matt Connell wrote:

You just described gpg-agent, the core of what Efe (OP) is meddling
with :)

No, I didn't.

I was referring to having the OP's utility read the password and
interact with GPG /once/ at startup and then the utility run for a much
longer time retaining the decrypted password in it's memory.

The difference may seem subtle, but it is very important to understand.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEVwebaduP4RnpDeHTNg4/A+X8N/oFAmQBfVlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU3 MDc5QjY5REI4RkUxMTlFOTBERTFEMzM2MEUzRjAzRTVGQzM3RkEACgkQNg4/A+X8 N/r+wQ/7BV+gp/1+lC/nFY/p+UaB8jFTt+BMZR0cKmOeie6nlPvtVP8lIxJUMWkm oXb6FcO5DnAmuSTQoSaImeG7MpFeUqf4Scq4Yl/lVhm3R4V8kJ3SeHSzTMPUNspT 4JLYoz5yf/8mMok47TLC9Ht42sdqUsQfUwCCUi/+4PKqKYqAQtsFF+VPRx9JDI3f 2/T5VyikVdMPgxQPrQ0QSIPPy4Z5Icowc94OH+Dw9Di8CxzmXvPPs56cPr/kX3Ek dB+7ZAw2XsjLZ9KHVd+5gzVEOu23368uKwGXqGMlMo2/bKGbAH0ZAC85WR5sCaQM gNBjeJksBuUuhMbJB+4ddlk23pjhWKJOVAHWrgah0i1fgyr2pJXl5y+RjJHaIaTq oL3cNmWrS5lbCtFTSQFxXR4TbAzab9UdRbLHZ1Gb1/L38zWEBqtVmASfhNdmABh9 ghzZwV5Bl88Jk31BMzadzy5bru7yHQU9OB7L4ENKAi3wosQ58NYkqnGrUyOlXDYw 2TinFjJu+ZkCrUPKZGKgp/9wVfI6sBrZOBRGC1iRtbrJZmGjOu2IUkaVggJzzIUq y7I6bAf8FwTzLncU/9NcuiTCZRZdYQUT9G2/ajWQJY/BSgyADR6C6NGjPddeMmQJ wD8uRRuc1bj8U31XA6C9suVx++Ptgi/1lV7hy

On 3/2/23 9:53 PM, efeizbudak wrote:

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.

There is value in not having a password in clear text on a file system.

It really depends on what your trying to protect from / against.

Grant:

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?

I think we're talking about the same thing.

Again, I may be missing something here, but does having your GPG
credentials unprotected offer any real protection?

See my response to your comment / question to Matt.

I guess this is where I'll eventually be heading towards.

I'm personally looking forward to being able to use TPMv2 to protect
keys for services running on the system. It requires said services to
support the TPM.

By the way, thanks to both of you for your thoughts!

:-)



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2023-03-02 at 23:53 -0500, efeizbudak wrote:

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)?

Yes and no.

Yes in the sense that a rouge piece of software or a bad human actor
could execute `pass $path` and acquire the given secrets, so long as
the gpg-agent is holding the provided password.

No in the sense of that the file itself (remember pass stores
individual files for each secret) is still encrypted at rest. That is
to say, unless someone or some software is specifically looking for gpg-encrypted files and knows how to use gpg or pass, they cannot
access the data.

The original point I was trying to make (in the previous message) is
that usability and security are always going to compromise one another,
and it is up to each of us to decide where the right balance lies.
Since I don't consider local malware a legitimate threat, my concerns
are limited to bad human actors. Working from home, and locking my
computers when leaving them, gpg-agent being unlocked for eight hours
after the start of the work day is sufficient security.

People who use gnome-keyring (myself included!) probably don't think
twice about the fact that the keyring gets unlocked *once* and stays
unlocked until the user's session ends. Heck some of my sessions can
last *months* on some machines. Sure, most of us have rigged it up to
use a pam library, but the the situations parallel. The access agent
is still "unlocked" for long periods of time, while the data on disk
remains encrypted at rest.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)