[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Re: Re: Ksshaskpass ?
From:       Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= <mgraesslin () kde ! org>
Date:       2014-12-12 6:37:18
Message-ID: 2790551.izGlnOhDQA () martin-desktop
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 11 December 2014 10:37:22 Jeremy Whiting wrote:
> Martin,
> 
> Thanks for the review. I see what you mean, is there an example of doing
> that on X11, also does that make it so ksshaskpass (or kpassworddialog)
> won't work on wayland?

Concerning Wayland: on this windowing system doesn't allow clients to read key 
events for other clients (of course root can still just listen to the device 
files). This implies that one cannot grab the keyboard any more.

Given that I would suggest to do the hardening only on X11, by either using 
QX11Info::isPlatformX11() or comparing the platformName to xcb.

> At any rate if you can point me to another example
> that does this I'll put a patch for KPasswordDialog on reviewboard (unless
> someone else beats me to it).

I think Thomas already explained the steps quite good.

Cheers
Martin

> 
> thanks,
> Jeremy
> 
> On Thu, Dec 11, 2014 at 8:43 AM, Martin Gräßlin <mgraesslin@kde.org> wrote:
> > On Thursday 11 December 2014 08:33:48 Jeremy Whiting wrote:
> > > ksshaskspass has been in kdereview and has been improved since it got
> > > there. Is it ready to be moved to kde/workspace ?
> > 
> > Sorry for being late for the review. I just cloned the repo and did a
> > quick
> > look for a common problem on X11: the dialog doesn't grab keyboard input.
> > 
> > When a window asks for a password it should make sure that no other X
> > client
> > intercepts the input. On X11 every other client is able to get to the key
> > events. Thus the dialog should:
> > * grab the keyboard when it gets keyboard focus (is active)
> > * disable entering the password if it failed to grab keyboard and print a
> > useful message
> > * release the grab keyboard once it lost focus (e.g. user wants to switch
> > to
> > browser to check why that wants a password)
> > 
> > While writing that I realized that this is not at all the fault of
> > ksshaskspass but rather of KPasswordDialog which should implement those
> > checks. So I wouldn't say it's a blocking issue for a move, though I would
> > prefer to not get new applications into kde/workspace which aren't secure
> > against the key logging attacks on X11.
> > 
> > Cheers
> > Martin
> > 
> > > On Wed, Nov 5, 2014 at 12:50 PM, David Faure <faure@kde.org> wrote:
> > > > [cutting down on the massive cross-posting]
> > > > 
> > > > On Monday 03 November 2014 14:13:50 Jeremy Whiting wrote:
> > > > > ksshaskpass has no more krazy issues and has been moved to
> > > > > kdereview.
> > > > > I think it's final resting place should be kde/workspace but I'm
> > > > > open
> > > > > to other ideas. It is usable on other platforms besides plasma, but
> > 
> > it
> > 
> > > > > saves passwords in kwallet, so may make the most sense there.
> > > > 
> > > > Yep, sounds like a workspace component to me. It doesn't make sense
> > 
> > when
> > 
> > > > using
> > > > a single KDE app in e.g. gnome, which surely has another GUI for
> > 
> > ssh-add.
> > 
> > > > --
> > > > David Faure, faure@kde.org, http://www.davidfaure.fr
> > > > Working on KDE Frameworks 5

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]