Follow-up about querying gpg-agent configuration options

[Kenny Evitt]

Back in April there was a thread with the subject "Querying gpg-agent
configuration options".

One of the last posts in that thread was as follows:
>On Wed, 27 Apr 2016 18:02, eric.pruitt [at] gmail said:
>
>> query the information from gpg-agent, it parses the configuration files
>> which is not what I need. Am I missing something? If it matters, the
>
>It parses the configuration files and also consults gpg-agent to test
>which are options are enabled for use by gpgconf and what are the
>current values. To do this gpgconf uses the special gpg-agent option
>'--gpgconf-list'. This usuallay returns the correct values, unless
>gpg-agent has not ben restarted after a gpg-agent.cof chnage or command
>line options are used.
>
>> version of gpgconf / GPG I'm using is 2.0.14.
>
>If really required we could add an Assuan command to return certain
>values similar to "gpg-connect-agent 'help getinfo' /bye". But before
>adding such an option I would like to learn why you need this.

I can't speak for Eric, but I was interested in querying the cache setting
because I was working on shell scripts to implement a 'time-limited'
decryption, using a symmetric key and I decided to implement the 'limit'
aspect by running a shell script to re-encrypt the relevant item before the
gpg-agent cache that includes the symmetric key passphrase expires.

The larger project involves mimicking the manner in which a lot of
'password managers' work by allowing users to 'unlock' (decrypt) a password
database for a limited amount of time and then automatically 'locking'
(encrypting) the database after the limited period has elapsed (and thus
preventing the decrypted data from remaining on the system).

I'm using Pass for storing password entries but I also want to encrypt the
entire 'password store' directory to, e.g. securely share different
password stores among many computers.

I discovered tho that a background process doesn't have access to gpg-agent
or its cache, which upon reflection is wonderful. So instead I modified the
'decrypt' shell script to prompt for the passphrase and then pass it to
both the `gpg2` decrypt command and the `gpg2` encrypt background command.
[I'd separately appreciate any feedback about whether this is a secure or
otherwise sensible way to do this.]

So in my case I wanted to access this option setting so as to fit within
the cache window. Given the current implementation, retrieving the actual
setting in gpg-agent as its running is less important. But it would still
be nice to match its cache setting were the value retrieved by `gpgconf` to
differ.

It would also be nice were there some way that `gpg2` and `gpg-agent` could
provide a 'time-limited' decryption feature themselves. Or maybe some way
commands could be 'hooked' into the expiration of cache entries, i.e. to
cleanup decrypted info and re-encrypt items.

Also, with respect to the example code for retrieving the option setting
with `gpgconf` and `awk`, the output I saw did not include a value for the
`$10` variable. I guessed that the `$8` was a default setting and that
`$10` represented an explicit setting that overrides the default. If I'm
wrong, please let me know.

Thanks,
Kenny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160612/4f92c832/attachment-0001.html>