Once again feature freeze came way too early and I had to decide whether I ship a half finished feature or delay it till the next cycle. This time I decided for giving the new screen locker half a year more time to mature.
In fact the feature was finished some weeks ago with a complete transition to KWin. Unfortunately it turned out that there is one possible situation for a race condition which could lead to a desktop being unlocked in the worst case if KWin crashes. Of course it would not be possible to trigger a crash when the screen is locked, but KWin relies and integrates libraries which are out of our own control (e.g. think of drivers).
The architecture I had in mind would let KWin restart and relock the screen immediately after a crash. Nevertheless there is a small timeframe in which the screen is unlocked and any other client grabbing the keyboard would render the screen unlocked. A limitation of the X windowing system. It is unlikely that KWin crashes while the screen is locked. It is even more unlikely that a client would be able to grab the keyboard just during the race. Being able to trigger a crash in KWin and prevent the screen from locking is most unlikely, but still there is the abstract possibility. Security is very important to me and I agree that such an architecture cannot be used. I am thankful to the fellow KDE developers who pointed out the possible race condition which I did not consider in my design.
Given that most of the work on the new lock dialog was already done I thought it would be easy to integrate in a slightly changed architecture. Unfortunately the problems of time constraints as a spare time developer hit me and I did not find time to work on it till this week – in fact I started on Wednesday evening.
I succeeded in getting the new locker to work but it was without any possibility to include the existing animations while screen is locked and I could not include the widgets on screen locker overlay. The first issue I hardly care about as the QML would allow new animations (though none is written yet) but the latter one would mean a clear regression. It is possible to integrate Plasma widgets with the new locker, but it required more changes than feasible on one day of work without a loss of quality. As this is security related code I decided that the feature needs more time to mature and will be made ready to be integrated as soon as the freeze lifts for 4.9 development. In fact I will concentrate on getting it ready for Plasma Active 2.
And just for the records there is another area of work which I decided to not merge into master weeks ago: the initial work on Wayland. Given that hardly any distribution is shipping Wayland libraries we cannot depend on it anyway and so it does not make much sense. Those who want to test have to build the code anyway and a branch is then as good as any other. Also there was not much work going on in the branch lately which is a short reminder to anyone that help is very much appreciated 🙂