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

HW42 hw42 at ipsumj.de
Thu Oct 30 16:16:40 CET 2014

Am Thu, 30 Oct 2014 12:48:30 -0200
schrieb Martin Ichilevici de Oliveira <iomartin at iomartin.net>:

> On Thu, Oct 30, 2014 at 03:22:31PM +0100, Werner Koch wrote:
> > On Thu, 30 Oct 2014 14:32, iomartin at iomartin.net said:
> > 
> > > I'm sorry (and I don't mean to be annoying), but I still don't
> > > understand why gnupg doesn't support infinite ttl? Is it by
> > > design or
> > 
> > What is the use case case for this?  I can't see one except to work
> > around a bogus security policy.  If you do not have a need for a
> > passphrase you should not use a passphrase for the protection of
> > your secret key.

One use case would be if you don't want to store it unencrypted on disk
- but in keep in in RAM is ok (this works of course only if you don't
 use hibernation or similar). 

> I see what you mean.
> Personally, I use gnupg mostly for signing email, and once in a while
> for encrypting it. I don't want to enter my passphrase every so often,
> but at the same time I didn't like the idea of using no passhprase at
> all.
> Given that I usually reboot my computer around once a week, I found it
> to be a good compromise (in my case), to enter it once and then not
> worrying. I achieved that with a high ttl, but this just feels clumsy
> to me. Maybe that's what you'll call a bogus security policy - and you
> might be right - but it just seems cleaner to use -1 instead.
> Cheers,
> Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20141030/9560beb7/attachment.sig>

More information about the Gnupg-devel mailing list