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 🙂
Wasn’t it already better than kscreenlocker?
that depends on the point of view: if you do not need widgets or animations, than yes 🙂
Well, I don’t really care about animations or widgets (except those strictly needed to unlock the screen), and I don’t use screensavers anymore since when I am not using the computer, I simply turn off the screen.
Would a KWin screen locking code work for KDE 4.8 under those conditions?
But wasn’t the complete but “insecure” version already more secure than kscreenlocker? Haven’t you been complaining about the security issues with the traditional screensaver-based locking?
It was insecure in a different way. With kscreenlocker it can happen that content is shown above the screen locker, but the screen would not unlock due to crashes in the OpenGL drivers 😉
It’s a pity that the new screen locking mechanism didn’t make it for 4.8. Especially considering that it was the first feature listed by Aaron in his blog post on plasma workspaces 4.8 (ok, order maybe was not intentional, but…). However, I agree that security is important and better to wait until the code is really mature.
Please keep up with your impressive work on kwin
Releasing a in-perfect program can be against ones pride – but if it is better that the existing solution then one should do it.
I don’t want to sound overly picky, but it should be “imperfect”. “Inperfect” confused me at first; it sounds more like “in a perfect state” which is the exact opposite.
I already thought it wouldn’t make it, but I think we can live yet another release with the old implementation 🙂 But that then makes it possible to transition entirely to the new technology, i.e. also the new QML screensavers etc?
And for the Wayland thing, also not bad since it is not production-suitable yet anyway and the developers and Plasma Active guys, like you said, still can compile it.
The screenlocker branch is this farfad_h/screenlocker thing?
That’s the one with everyhthing in KWin. The new code will go into a different branch.
I totally agree with your decision pal, releasing not finished features is something that will hurt more than anything else, and we have seen some of those during the last years don’t we? :p
I’m wondering if will be a way of somehow test it with 4.8, for example a simple way of disabling kscreenlocker and using KWins one.
cheers!
I will do my best to make them installable next to each other and not to depend too much on unrelated changes. But I fear that I need at least kephal, so it has to be in workspace.
Would it be worth trying to get the freeze delayed for this feature?
no, that destroys the general idea behind a freeze
Sad, but understandable.
I agree with BajK, if the release has to wait for another 6 months anyways, the best could be made of it by using the time to prepare for a clean break, so that by the time of 4.9 the new screen locker can be shipped as a fully polished and complete solution (together with beautiful themes and applets to choose from), and maybe even completely dropping fallback support for old screensavers etc.
Yes, there won’t be any fallback now, as that is more complex to achieve with little to gain.
It is interesting how difficult the whole area of controlling the whole screen is. Not just for screen locking but full screen applications as well: there is so much inconsistency between applications and broken behaviour and not just in the free desktop world (where it is quite understandable given the way X11 and the desktop has historically developed) but also in windows and OSX.
Naively you would have thought it would be possible for an API to provide give_me_a_full_screen_context(full_screen_context*) or whatever and for everyone to live happily ever after. But obviously not.
well, that’s what Wayland is going to fix as well.
KPA 2 will be released before SC 4.8 but it’s too late for 4.8 but not for KPA 2?
Frankly: I don’t get it.
Well, thanks anyway for your work. One additional reason to already get excited for 4.9.
PA 1 already uses a subset of the work done on screen locker. In the end it’s all about freezes. PA 2 is not yet frozen, so it’s possible to finish it for that release.
Hello Martin,
I just picked this article randomly in order to say you a huuuge THANK YOU!
You know, for all the (coding) work you do, for all articles you write, the interview you give, and especially for the excitement you spread around 🙂
I hope there are many, many shiny days in the (OpenSource) world waiting for you…
Martin, we have a problem:
http://gu1.aeroxteam.fr/2012/01/19/bypass-screensaver-locker-program-xorg-111-and-up/
So the security issues were not so theoretical as some stated.
well also the new screen locker uses grabs. Even for the window manager/compositor there is no other way on X11. The proper fix will be with Wayland.