[PATCH] doc: elaborate on --default-cache-ttl and --max-cache-ttl

[Martin Ichilevici de Oliveira]

On Wed, Oct 29, 2014 at 04:08:46PM +0100, Werner Koch wrote:
> On Wed, 29 Oct 2014 14:04, iomartin at iomartin.net said:
> > The gpg-agent cache supports infinite ttl, through the --default-cache-ttl
> > option, which was not documented. That, however, is still subject to
> > --max-cache-ttl. This patch adds this documentation.
> 
> Well, what you see is a buglet.  It is not intentional.
> 
> What happens is that the argument is converted to an unsigned long using
> strtoul but at some point that value is assigned to an int which may
> then turn to a negative.  This is due to a strange strtoul feature which
> I almost always forget about: a sign in the string is legal.

Hello, Werner.

I'm not sure I'm following you here. On agent/cache.c, the declaration
of struct cache_item_s is

    struct cache_item_s {
      ITEM next;
      time_t created;
      time_t accessed;
      int ttl;  /* max. lifetime given in seconds, -1 one means infinite */
      struct secret_data_s *pw;
      cache_mode_t cache_mode;
      char key[1];
    };

on what situations could we have ttl < 0 then if not with
default-cache-ttl? Is that what gpg-set-passphrase is for?

Also, on the housekeeping function we check if r->ttl >= 0 before expiring a
passphrase.

> I also do not think that it makes sense to have such a feature in
> particular not due to the explict limit set by --max-cache-ttl.
> However, if this is desired the argument parser needs to be changed to
> explicitly take a signed argument.

From what I understood (please correct me if I'm wrong), using
default-cache-ttl = -1 is essentialy the same as using gpg-set-passphrase
for all passphrases. So that was the idea behind this patch, given the
decision on the patch 

Do you mean that if you someone wants to have all passphrases to have
infinite ttl, then they should explicitly use gpg-set-passphrase for all
of them?

Finally, what is the rationale behind max-cache-ttl not allowing
"infinite"? Afterall, in practice, it could be achieved by setting an
extremely high value for max-cache-ttl. I'd be happy to work on a patch
to support this, if you think it's OK.

Cheers,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20141029/b0f3cee1/attachment.sig>