[PATCH] Make pinentry-qt read and store passphrases in KDE 3.2's wallet

Robert Schiele robert.schiele at t-online.de
Mon Dec 1 13:03:28 CET 2003

On Mon, Dec 01, 2003 at 12:18:54PM +0100, Werner Koch wrote:
> On Mon, 1 Dec 2003 09:55:06 +0100, Robert Schiele said:
> > To be fair it should be mentioned that KWallet does _not_ store the passwords
> > in clear text on the disk, but does encrypt it by a password that has to be
> > entered each time kwallet is started. Thus it is somewhat similar to what the
> And thus the clear passwords are floating around in KDE occupied
> memory without much control.  In contrast gpg-agent is designed to

Well, if this is the case, I agree with you that this is a problem. But as I
did not look into the code of KWallet, I cannot comment on that in a senseful

> minimize traces of secrets left on system resources and to keep close
> control over it.
> If the goal is to make password entry easier, you should use gpg-agent
> at least for gpgsm passwords and best also for gnupg passwords,
> becuase at some point gpg will delegate all seret key operations to
> gpg-agent.

Yes, I am using gpg-agent.

It's just that if KWallet is implemented the right way, it is in my opinion a
nice add-on. If it is not implemented the right way, then I agree with you
that it should not be used for cryptographic products. Whether it is
implemented the right way or not, I don't know.

You might argue (and obviously you do ;-) that such a powerful application is
more risky than a small specially designed one. --- And I also agree with you
here, but I think you cannot hold your statement that using such an
application is like storing the unencrypted private key to disk, because you
still can have the hope that there is no bug in the application code that
allows an attacker to fetch the password.

> > I can't tell exactly how smart encryption (AFAIK Blowfish) and management of
> > passwords in KWallet are implemented, so I cannot tell whether it is a good
> > idea to use it or not. But assuming that it is implemented in a smart way I
> Assuming might not be the way to handle securit critical things ;-)

That's correct, but blaiming a software product to do nasty things just
because it could have done it that way is not nice to the author of this
software. This is why I wanted to make clear that the software at least does
not store passwords in cleartext on the disk.


Robert Schiele			Tel.: +49-621-181-2517
Dipl.-Wirtsch.informatiker	mailto:rschiele at uni-mannheim.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20031201/99a50a11/attachment.bin

More information about the Gpa-dev mailing list