Confirmation for cached passphrases useful?

Ingo Klöcker kloecker at
Sun Oct 24 00:27:54 CEST 2010

On Monday 18 October 2010, Faramir wrote:
> El 17-10-2010 22:09, Doug Barton escribió:
> > On 10/17/2010 5:43 PM, Faramir wrote:
> > |    That may be true. However, remember feeling secure is part of
> > |    security
> > | 
> > | too, so if that feature doesn't break anything, and make people
> > | sleep better...
> > 
> > Two problems with that theory. The first is that a false sense of
> > security does more harm than good. The second is that there is no
> > such thing as a zero-cost change to software. So any proposed
> > change has to have benefits that outweigh the costs. Of course
> > accurately anticipating those costs is a whole different category
> > of problems. :)
>   Right, I agree, we don't want those stones that keeps tigers away.
> But as long as people know the feature may be ignored by malware, it
> wouldn't be false sense of security, maybe it would be the solution
> against false sense of insecurity (if such thing exist).
>   Also, I was not saying anything about costs of adding the feature,
> so my message should have said: "if there is a developer willing to
> add it, and it doesn't break anything, and it can be disabled by
> user, I'm ok with it". Please note I'm not requesting that feature,
> I just said I would not oppose to it's addition.

The feature might not break anything now but it will make the software 
more complex. More complex software tends to break more easily. One of 
the main design goals of gpg-agent, pinentry, etc., was to keep the code 
of those small helper applications dealing with the secret keys and the 
passphrases as simple as possible to avoid the complexity trap.

Also, it's a popular fallacy that adding a feature generates cost only 
once. Every new feature will increase the maintenance costs and thus 
generate additional cost for the whole lifetime of the software.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20101024/0deb2a2f/attachment.pgp>

More information about the Gnupg-users mailing list