Security Audit Request for Screenlocker Branch

[Martin Gräßlin]

On Wednesday 12 October 2011 19:38:11 Oswald Buddenhagen wrote:
> On Wed, Oct 12, 2011 at 04:47:54PM +0200, Dario Freddi wrote:
> > 2011/10/12 Martin Gräßlin <mgraesslin at kde.org>:
> > > ok I have been thinking about it and have a new proposal:
> > > * writing a kded module to only handle the screen locking (grab keyboard
> > > and mouse)
> > 
> > TBH, if you really care about not making the thing crash, I would not
> > put it into KDED, which has a lot of things which are not under your
> > control potentially crashy, but into a separate running daemon.
> 
> my first thought, too. :}
ok, so a separate running daemon it shall be
> 
> > > * having greeter in a separate process, so that the kded module can
> > > restart
> > > the greeter in case it crashes
> > > * use xproperty on all greeter windows to inform the compositor which
> > > windows belong to it
> 
> i'm assuming you are including the locker/saver window in "greeter
> windows"?
Yes, everything "visual" in the separate process.
> 
> > > * use a kwin effect to additionally ensure that the screen is
> > > blanked and nothing gets above the greeter windows
> 
> that seems superfluous. the presence of the locker window simultaneously
> indicates "locker mode" and provides "blanking content" (rendered by an
> out-of-process hack and blanked in-process as a fallback). when that goes
> away unexpectedly, all bets are off anyway.
See Thomas mail: with compositing enabled some xscreensavers fail to blank the 
screen. The main reason for the effect would be to fade in/out the locker, but 
when we have it, we can also use it to fix this annoying bug only present with 
compositing.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111013/c40da4e5/attachment.sig>