Hello,
Lucas Mulling wrote:
> A few users have questioned a change in behaviour from version 2.4.7 to
> 2.5.0 (commit 92de0387f04b1e87a4a49ed063323624f25ac3ef) where setting
> max-cache-ttl to 0 does not disable password caching anymore, is this
> change intended?
Sorry, it's not intended change. I overlooked this use case of setting
max-cache-ttl to 0.
To disable caching, I think that you can do by:
default-cache-ttl 0
Possible fix to recover the same semantics would be the following.
==========================
diff --git a/agent/cache.c b/agent/cache.c
index e8544205f..fbe1c1f14 100644
--- a/agent/cache.c
+++ b/agent/cache.c
@@ -318,6 +318,7 @@ compute_expiration (ITEM r)
unsigned long maxttl;
time_t current = gnupg_get_time ();
time_t next;
+ int no_maxttl = 0;
if (r->cache_mode == CACHE_MODE_PIN)
return 0; /* Don't let it expire - scdaemon explicitly flushes them. */
@@ -334,13 +335,16 @@ compute_expiration (ITEM r)
{
case CACHE_MODE_DATA:
case CACHE_MODE_PIN:
- maxttl = 0; /* No MAX TTL here. */
+ no_maxttl = 1;
+ /* No MAX TTL here. */
break;
case CACHE_MODE_SSH: maxttl = opt.max_cache_ttl_ssh; break;
default: maxttl = opt.max_cache_ttl; break;
}
- if (maxttl)
+ if (no_maxttl)
+ next = 0;
+ else
{
if (r->created + maxttl < current)
{
@@ -351,8 +355,6 @@ compute_expiration (ITEM r)
next = r->created + maxttl - current;
}
- else
- next = 0;
if (r->ttl >= 0 && (next == 0 || r->ttl < next))
{
--
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
