Confirmation for cached passphrases useful?

Hauke Laging mailinglisten at
Sat Oct 16 01:05:11 CEST 2010

Am Samstag 16 Oktober 2010 00:23:04 schrieb Robert J. Hansen:
> > Ok, then this protects against malicious programs that are not
> > intercepting the dialog box.
> Which means that six months after this feature gets implemented, the
>  malware authors will write exploits that intercept the dialog box.
> Arms races are inevitable, but stupid arms races should be avoided.

This implies the strange claim that it will forever be possible to do that. As 
I already mentioned you can run X clients untrustedly today and SELinux is 
going to be extended by features for X access restriction.

But, of course, you can deny all applications that never use gpg keys access 
to both the files and the socket by means of the LSMs even today. And if an 
application gets hijacked that has to access the key files and the socket then 
an attacker can wait until the next intended operation occurs. So the user 
would not notice the abuse of his key.

The process of informing the user could be more clever than a simple "gpg-
agent access, please click OK" window. An obvious option is to allow the user 
to configure a program and allow or deny access based on the exit code; we saw 
proposals what such a check program could do here in the discussion. I just 
don't like the idea that access to the agent is "not noticed by design".

Somebody mentioned an "inconvenience for the user". I would make this 
behaviour an option (for people understanding the merits and limits) not the 
default. Thus no inconvenience for anyone.

PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20101016/3d050589/attachment.pgp>

More information about the Gnupg-users mailing list