What to do with potential workflow-changing / breaking changes?

[Martin Gräßlin]

Am 2017-02-21 11:07, schrieb Fabian Vogt:

> For the kscreenlocker patch, the better option would be to just disable 
> the
> option to show the password (which is IMO a security issue by itself) 
> again
> and the best option to disable pasting.

That would also break a feature. So given what you wrote above that 
should not be allowed as well. Given that you find that acceptable you 
do the mistake of considering one feature more important as the other.

Given the emerge of touch screens I consider the possibility to see the 
password as highly important. (Yes I'm aware that we don't have an 
onscreen keyboard on the lockscreen, I'm working on that and have a 
branch which could go in now that we depend on 5.7)

> Instead, it did something that breaks
> even beyond the screen locker: It erases the clipboard!

Just pointing out that this also prevents against brute force attacks 
through pasting the clipboard. Such attacks existed for example against 
Android. As the screenlocker maintainer I'm highly interested in 
reducing the attack surface.

> 
> That kate/kwrite cannot be run as root anymore is fine for everyone, 
> but the
> way the patch implements it is not ok. When run using "kdesu kate" or 
> similar,
> the user just gets nothing as feedback! I'm working on a patch to open 
> a
> dialog box as the original user but it's not implemented in a readable 
> way
> yet.

I'm sorry, I didn't consider kdesu(do) at all. It's a tool I never use. 
If I need root I use konsole or polkit. But not kdesu. That was an 
oversight, which also nobody during review noticed. I'm sorry I didn't 
consider that one can start a gui application as root through gui.

Cheers
Martin