[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnupg-devel
Subject:    Re: [PATCH] doc: elaborate on --default-cache-ttl and --max-cache-ttl
From:       HW42 <hw42 () ipsumj ! de>
Date:       2014-10-30 15:16:40
Message-ID: 20141030161640.388422d8 () ipsumj ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

> On Thu, Oct 30, 2014 at 03:22:31PM +0100, Werner Koch wrote:
> > On Thu, 30 Oct 2014 14:32, iomartin@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

[Attachment #5 (application/pgp-signature)]

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


[prev in list] [next in list] [prev in thread] [next in thread]