KPasswordEdit patch (was Re: new widgets...)

Thomas Zander zander at
Fri Sep 27 10:39:37 BST 2002

On Fri, Sep 27, 2002 at 01:50:40AM -0700, Neil Stevens wrote:
> Hash: SHA1
> On Friday September 27, 2002 01:42, David Faure wrote:
> > On Friday 27 September 2002 10:17, Neil Stevens wrote:
> > > On Friday September 27, 2002 01:05, Simon Hausmann wrote:
> > > > It is not more secure at all because the mlock()/munlock() calls
> > > > will fail if the processes is not running with root privileges.
> > > > Citing Waldo: Sorry, security is not optional :)
> > >
> > > Well, it's free software.  Anyone who wants it optional is going to
> > > make it optional.  The only question is, are people going to be able
> > > to have flexible security models within KDE, or will they have to fork
> > > KDE to do so?
> >
> > Oh come on. It makes no sense to include code that only works if you
> > run a KDE application as root - we've always discouraged doing so
> > (to the point that suidroot kde apps are forbidden by kapplication
> > IIRC).
> Grr.. that's not what I meant to convey.  I agree the mlock is worthless.  
> I think the const char * is just as worthless.
> I'm talking about making optional the use of a clunky, inconvenient const 
> char *, when a QString is no less safe for nearly all of KDE's users.

How is providing a secure and a non-secure interface going to allow users 
with a choice?

I doubt many users will rewrite the applications just so it can become secure.

Therefor everything has to be secure, since the weakest link will crack first.
Therefor we come back to Waldo's statement; 'security is not optional'

As a sidenote; not all implementations of malloc zero-fill the memory before
returning it; therefor _any_ user can grab all memory which is free in the 
system and search for passwords, even of passwords of other users.

Making sure the password is not in memory any longer then it should provides
that KDE will not be the weakest link in the security chain.

Thomas Zander   zander at
We are what we pretend to be

More information about the kde-core-devel mailing list