27 Nov 2015

feedPlanet KDE

Kubuntu: KDE: Munich Hackathon KDE CI work and Kubuntu workflow

Munich Hackathon sponsored by Limux

Munich Hackathon sponsored by Limux

First, a big thank you to the fine folks at Limux for hosting the event. Second, a big thank you to the Ubuntu Community Donations fund for getting me there!

I successfully crammed a ton of work into this short trip! We (Kubuntu) first sorted (mostly) a plan
for Xenial LTS release. We are going to sync with Debian as much as we possibly can this release as
stability is of utmost importance. Don't fret, we (I) will still put newer KDE releases in a PPA for
those that want the newest of KDE, time permitting of course. We are still working out who will host our CI system, as we all agree that this is extremely important to our workflow. During the period that we are synced to debian will have time to fix our somewhat broken toolset so that we can function with less overhead. We bashed a few bugs, updated our to-dos.

On the KDE side, I worked on getting the docker workflow functioning on build-sandbox.kde.org. Unfortunately, ICU was updated so all of KDE will need a rebuild before this can go live. But the good news is we will have more than 2 slaves! And it will be fairly simple to extend in the future, fully clean builds, and we can utilize different OS version requirements. I also spent some time working on Phabricator permissions issues.

Overall this was an essential team building and work event that I could not have participated in without your help. So thank you to all of you that support Ubuntu community donations. Donate today!

With that said, my cry for help:

If you find any of my work useful, please consider a donation or become a patreon!
I can no longer sustain working without an income. If this works I can continue all of my
(K)ubuntu and KDE contributions ( a full time job in its current state + overtime!)
Patreon for Scarlett Clark (me)

27 Nov 2015 10:52pm GMT

Kubuntu: Ubuntu: The vote for UCC is in. I won?!?!

I would like to thank all of you for your support and votes for Ubuntu Community Council. I honestly did not think I could win. We had negative 24 hours to come up with a platform lol.
While I have done some major packaging contributions, I have mostly stayed away from the political side of the project. In my first few weeks I will catch up on current events and construct a plan of action. Hopefully, there is not too much! I do have a heavy load to carry with all of my other volunteering efforts. I do however, hope to be useful to the community in some way. I promise to all of you to put in everything I have.
Here's to productive, useful, and friendly conversations to return Ubuntu and it's flavors to their former glory, attracting new contributors and bringing back the bond of the current family of contributors.

If you find any of my work useful, please consider a donation or become a patreon!
I can no longer sustain working without an income. If this works, I can continue all of my
(K)Ubuntu and KDE contributions ( a full time job in its current state + overtime!)
Patreon for Scarlett Clark (me)

27 Nov 2015 10:25pm GMT

Resuming work on Yokadi

A few weeks ago we started working again on Yokadi, our command-line oriented, todo list. We are now finally ready to release version 1.0. This new version fixes a few bugs but does not bring new features. This lack of new features is actually a conscious decision: we wanted to make changes under the hood, and doing changes under the hood at the same time as adding new features is often a recipe for disaster.

What happened under the hood? I hear you asking.

Well, we finally ported Yokadi to Python 3. Mind you, it was not a straightforward port. The main pain point was SQLObject, the ORM we have been using since we started Yokadi. At the time we wanted to start porting Yokadi to Python 3, SQLObject had not been ported (the port is still not ready, only an alpha has been released) so we had to first switch to another ORM - we went with SQLAlchemy - before actually porting the application to Python 3. In fact I suspect Sébastien started the Python 3 port just to get rid of SQLObject, which he does not really like :)

The code is pretty much frozen by now, we have been using it for real-life todo-list work for quite some time: even if there are periods without active development, we still use and depend on Yokadi daily. We plan to get 1.0 out this weekend. Then we can start working on improvements and new features, a few of them are actually in progress, but I'll write more about them later.

27 Nov 2015 9:36pm GMT

Br-Print3D inside KDE:FINALLY

Well, after a few issues, i finally push the Br-Print3D code to the git on KDE Playground.

Click here to access the repository.

Screenshot from 2015-11-27 14-52-51Thanks a lot to KDE staff for this opportunity to have the Br-Print3D within this community!


27 Nov 2015 4:56pm GMT

screen config victory!

kscreen wayland backend in action

kscreen wayland backend in action

That moment when the application "just works" after all your unit tests pass…

A really nice experience after working on these low-level bits was firing up the kscreen systemsettings module configured to use my wayland test server. I hadn't done so in a while, so I didn't expect much at all. The whole thing just worked right out of the box, however. Every single change I've tried had exactly the expected effect.
This screenshot shows Plasma's screen configuration settings ("kscreen"). The settings module uses the new kwayland backend to communicate with a wayland server (which you can see "running" on the left hand side). That means that another big chunk of getting Plasma Wayland-ready for multi-display use-cases is falling nicely into place.


I'm working on this part of the stack using test-driven development methods, so I write unit tests for every bit of functionality, and then implement and polish the library parts. Something is done when all units tests pass reliably, when others have reviewed the code, when everything works in on the application side, and when I am happy with it.
The unit tests stay in place and are from then on compiled and run through our continuous integration system automatically on every code change. This system yells at us as soon as any of the unit tests breaks or shows problems, so we can fix it right away.

Interestingly, we run the unit tests live against a real wayland server. This test server is implemented using the KWayland library. The server runs headless, so it doesn't do any rendering of windows, and it just implements the bits interesting for screen management. It's sort of a mini kwin_wayland, the real kwin will use this exact same library on the server side, so our tests are not entirely synthetical. This wasn't really possible for X11-based systems, because you can't just fire up an X server that supports XRandR in automated tests - the machine running the test may not allow you to use its graphics card, if it even has one. It's very easy to do, however, when using wayland.
Our autotests fire up a wayland server from one of many example configurations. We have a whole set of example configurations that we run tests against, and it's easy to add more that we want to make sure work correctly. (I'm also thinking about user support, where we can ask to send us a problematic configuration written out to a json file, that we can then add to our unit tests, fix, and ensure that it never breaks again.
The wayland test server is only about 500 lines of relatively simple code, but it provides full functionality for setting up screens using the wayland protocol.

Next steps…

The real kwin_wayland will use the exact same library, on the server as we do in our tests, but instead of using "virtual screens", it does actually interact with the hardware, for example through libdrm on more sensible system or through libhybris on ones less so.
Kwin takes a more central role in our wayland story, as we move initial mode-setting there, it just makes to have it do run-time mode setting as well.

The next steps are to hook the server side of the protocol up in kwin_wayland's hardware backends.

In the back of my head are a few new features, which so far had a lower priority - first the core feature set needed to be made stable. There are three things which I'd like to see us doing:

27 Nov 2015 3:29am GMT

26 Nov 2015

feedPlanet KDE

Pursuing Awesomeness

Plasma 5.5 hasn't even been released yet but work on the next version is already commencing.

Introducing U-Bahn

I've seen Plasma setups resembling Unity, or Gnome Shell, or OS/2, but I haven't seen Windows 8 yet.

YouTube Link: https://www.youtube.com/embed/8qFrich4LFM

This is an experimental Metro-inspired (Metro, U-Bahn, get it?) sidebar. Its name kinda shows how serious I was about this :) Anyhow, it's a nice showcase of Plasma's flexibility. The whole thing took me just over an hour to get up and running. It incorporates KRunner/Milou for search results, the Purpose Framework for sharing, parts of Print-Manager and Device Notifier, as well as the icons from Plasma-PA (audio) and Plasma-NM (network) on the Settings page. The centre button was supposed to launch the Application Dashboard, without tiles, though.

While I'm not planning to finish this very project - it's just too big of a hack the way it is -, I managed to get a discussion going. I'm looking forward to ideas our usability and design experts will come up with. It makes for an interesting concept on touch-enabled devices nonetheless. Also, I would love to see the Purpose framework embraced throughout the workspace rather than it living in the shadows within Kamoso and the Quick Share applet.

Jump Lists

Another feature I have wanted for years has finally landed: "Desktop Actions" aka Jump Lists. Basically, they are additional actions an application can offer to perform common actions or jump directly to a certain task from Task Manager. Common examples are "Open New Incognito Window" to open your browser directly in private mode, or "Compose Email" without launching the full-fledged Email client first.

If you're an application developer, start assessing which actions to provide - only few applications on my system actually do: Chromium (Google Chrome only ships Ayatana Desktop Shortcuts), LibreOffice (its launcher enables you to jump into a specific app, like Calc or Impress) and Konsole.

LibreOffice launcher providing access to apps within the suiteLibreOffice launcher with access to apps within the suite Chromium providing handy shortcutsChromium providing handy shortcuts

The specification is pretty "dumb", you can basically specify a name, an icon and a command to run - your application must then do the right thing™ eg. depending on whether an instance is already running or not.

Update: Chime in to the discussion on Jump List Actions on the KDE Forums.

More Convenient Plasmoid Install

While applets can be installed through "Get Hot New Stuff" and distribution repositories, there's also the classic .plasmoid file. A feature suggested by one of my colleagues - fresh KDE Plasma user - was to drag .plasmoid files onto the desktop or panel and have them installed. After Marco Martin implemented the neccessary KPackage plumbing this is now possible.


(Sorry for the quality, I wanted to make a GIF out of this but it turned out to be 24 MiB, then I downsampled it using ffmpeg and it mashed the picture)

If the applet is already installed, it will update if neccessary but still add it to where you dropped. To uninstall use the Widget Explorer which gained a new "Uninstallable" applets filter. Also, its uninstall feature now follows the undo pattern where you have a grace period before it actually uninstalls. Uninstalling also removes all instances of the applet rather than leaving broken applets behind.

Miscellaneous Improvements

First of all, FFMpegThumbnailer will finally be released as KF5-based plugin in KDE Applications 15.12 meaning you get thumbnails for videos in Dolphin again.

Secondly, in the Power Management department, switching sessions should no longer unexpectedly send your computer to sleep. Moreover, inhibitions will only be enforced after 5 seconds - this should prevent Chrome waking up your screen just because it played a short "You got message" sound. Also, I'm planning to overhaul the Battery Monitor UI which was essentially just ported from Plasma 4, where it worked well, to Plasma 5, where its layout is out of place. I won't promise that, though. :)

Finally, I ported the face / avatar gallery from the old user accounts KCM to the now used user manager. The Visual Design Group made some marvellous user pictures, like the Leonardo Da Vinci I'm using, it would be a shame if there was no UI to pick them.

26 Nov 2015 9:23pm GMT

Plasma 5.5 Release Party in Heidelberg

This time we'll celebrate early!

Date: Friday, 4 December 2015 (correct year this time around)
Time: 19:00
Place: Medocs Cafe am Bismarckplatz, Sofienstraße 7b, 69115 Heidelberg
Who: You! And fellow KDE developers and users
What we're going to do: Have a few beers, a delicious dinner, talk, have fun, …

Please ping me, if you're around and planning to come (contact info can be found in the Impressum, or tell kbroulik in #plasma on Freenode), so I can extend the reservation, if needed.

26 Nov 2015 11:45am GMT

25 Nov 2015

feedPlanet KDE

Marble Maps forking for SailfishOS

Marble, the swiss army knife for maps and globes, developed in the KDE community, this year has got an app variant added that is concentrating on maps and that is designed for today's typical mobile devices with touch UI, called Marble Maps. It currently is in Beta state. Read "Announcing Marble Maps for Android Open Beta" for more info.

At this year's Randa meeting for a few days I joined the people working on having KDE software run on Android. After all there are gazillions of such systems out there, and it only makes sense to have existing FLOS software, such as KDE ones, also run there, as a matter of dealing with realities. With the developers of Marble, KAlgebra and GCompris around, some experience could be shared, and I compiled what I learned into a small Hello KWorld example.

As a Marble fanboy, Marble Maps was my obvious toy project here when learning more about building Qt5-based software for Android. I had no Android device available, but a Jolla phone with SailfishOS. That one also has support for running Android apps, so I still could use it to test my self-built Marble Maps Android packages.

Now, it felt strange to run a Qt5-based application via Android emulation layer on an OS like SailfishOS which itself is using Qt5 and then some usual "Linux" software stack/middleware. Should it not simply run directly there?

So last week finally I gave it a try to build and to run Marble Maps natively on SailfishOS. And was presented with a problem: SailfishOS in the latest version is (still) at Qt 5.2 (with QML upgraded to 5.3 it seems) and, more important, has no QtQuick Controls. Which are used in Marble Maps for all controls. At least all the Marble C++ code was building fine after 2 small fixes, so that part was looking promising.

An option might have been to build a custom version of QtQuick Controls. But that somehow smelled like problems waiting. And I also was tempted to try to do some native UX to gather more experience with QtQuick and the SailfishOS ideas. So I forked the Marble Maps code and started to write a SailfishOS variant, using its Silica UI components. The code for Marble Maps is mainly the UI layer one, written in QML, with the actual business logic nicely in the shared Marble libs and components, so it is not that much logic which is duplicated here. Still it is not "Write once and run everywhere". It's up for discussion how much native multi-platform apps should go. For now I will play more with it.

Right now Marble Maps for SailfishOS almost has all current features of the "normal" Marble Maps implemented, modulo some small bugs:

Marble Maps on SailfishOS: Editing a route Marble Maps on SailfishOS: Adding a new point to a route

These days sadly many people hearing "marble" and "sailfishos" might rather think of "tombstone", bad timing here. But until that OS is pushing up the water lilies I will play more with it, after all I can use the code on a working device of mine.

If you want to use the code on a device of yours, find first RPMs on build.merproject.org and the code in branch "sfos" in my Marble repo clone clones/marble/kossebau/marble on the KDE git servers, see src/apps/marble-maps-sailfishos/ for the app code. Once it's stable enough the code will be proposed for inclusion in the official Marble repo.
(Update: when installing the RPM on the Jolla phone, make sure you have "qt5-qtscript" installed, pkcon install qt5-qtscript in the terminal should get you there.)

Also looking forward to see the "normal" Marble Maps and other Marble-based apps soon on Plasma Mobile hopefully.
And anyone looking into an Ubuntu Touch version? Would that work with stock Marble Maps, thanks to QtQuick Controls, or would more native UX be needed there as well?

25 Nov 2015 7:39pm GMT

Area51 updates (KDE on FreeBSD)

The area51 repository continues to update, even as the official ports tree for FreeBSD sticks with KDE4. Since the KDE-FreeBSD team is also responsible for the official ports, that basically means that not everything has been shaken out yet, and that the team doesn't feel that it can provide a really good Frameworks5 / Plasma5 / Applications installation .. yet. I've been playing with ideas for a default desktop wallpaper (the upstream default gives me a headache; I'd really like to combine Flying Konqui by Timothée Giet with bubbles made from the BSD logo.

That said, Plasma5 and some Applications work very nicely on FreeBSD. They also produce plenty of .core files, so it's not all wonderful, but it's a usable desktop by all means (and of course, all your KDE4 and GNOME applications continue to work). I tried to install a Qt5-only (+Frameworks, of course) desktop and discovered a long-standing bug in gsettings, as well.

The KDevelop-KF5 beta is available as a port from area51 as well. There's an interesting potential bug there, too: it uses LLVM 3.5 libraries while the Mesa libraries use LLVM 3.6 in the software renderer. So if you have a machine without hardware GL, you can end up with two LLVM libraries runtime-linked into an application, which means crashy-time. This is the first time that upgrading my graphics card has fixed my IDE.

25 Nov 2015 12:59pm GMT

Krita 2.9 Animation Edition Beta released!


Today we are happy to announce the long awaited beta-version of Krita with Animation and Instant Preview support! Based on Krita 2.9, you can now try out the implementation of the big 2015 kickstarter features!

What's new in this version? From the user point of view Krita didn't change much. There are three new dockers: Animation, Timeline and Onion Skins, which let you control everything about your animation frames and one new menu item View->Instant Preview Mode (previously known as Level of Detail) allowing painting on huge canvases. For both features, you need a system that supports OpenGL 3.0 or higher.

For people who previously installed Krita, to get Instant Preview to show up on the view menu, delete the krita.rc(not kritarc) file in your resource folder(which can be accessed quickly via Settings->Manage Resources->Open Resource Folder) and restart Krita. Or just use the hotkey Shift+L.

But under these visually tiny changes hides a heap of work done to the Krita kernel code. We almost rewritten it to allow most of the rendering processes run in the background. So now all animated frames and view cache planes are calculated in the moments of time when the user is idle (thinks, or chooses a new awesome brush). Thanks to these changes now it is possible to efficiently work with huge images and play a sequence of complex multi-layered frames in real time (the frames are recalculated in the background and are uploaded to you GPU directly from the cache).


So, finally, welcome Krita 2.9 Animation Edition Beta! (Note the version number! The final release will be based on Krita 3.0, this version is created from the 2.9 stable release, but it is still beta. We welcome your feedback!

Video tutorial from Timothee Giet:

A short video introduction into Krita animation features is available here.

Packages for Ubuntu:

You can get them through Krita Lime repositories. Just choose 'krita-animation-testing' package:

sudo add-apt-repository ppa:dimula73/krita
sudo apt-get update
sudo apt-get install krita-animation-testing

Packages for Windows:

Two packages are available: 64-bit, 32-bit:

You can download the zip files and just unpack them, for instance on your desktop and run. You might get a warning that the Visual Studio 2012 Runtime DLL is missing: you can download the missing dll here. You do not need to uninstall any other version of Krita before giving these packages a try!

User manuals and tutorials:

25 Nov 2015 6:18am GMT

24 Nov 2015

feedPlanet KDE

A clockwork carrot

This weekend I had the opportunity to travel to the yearly LiMux sprint to spend some time with my fellow kubuntu devs and talk about the potential issues we're facing with the CI system and improving the Debian CI system to be more robust.

Some of the more important issues that were discussed included figuring out a way to improve file tracking in packages, so that the CI can detect file conflicts without having to actually install all the packages. Another important topic that was bought up was using the packagekit and appstream with Muon. This is apparently being held back on account of Ubuntu Touch, but is slated to be resolved soon. Once the necessary packagekit packages are updated, we can play around with the idea of perhaps shipping a muon using the packagekit backend on the next Kubuntu release.

As usual, the LiMux folks are a great bunch to hang out with, and I happened to notice something on the wall of their office while lunching with them. It was a clock. Not just a regular clock though, a timey wimey clock. I'll let a picture do more of the talking here :

Timey Wimey clock

Timey Wimey clock

Told you. Timey Wimey.

I got quite the headache looking at the clock, but my fascination with it stuck. So once I was back home, I hacked up the regular Plasma 5 analog clock and made it timey-wimey too ;)

Timey Wimey clock

You can download and install the clock from here. Clocks and Carrots, a weekend well spent I say. As usual, you can find me and the other kubuntu devs in #kubuntu-devel on IRC or on kubuntu-devel@lists.ubuntu.com in case you want to reach out to us about Kubuntu, Clocks or Carrots.

24 Nov 2015 10:32pm GMT

Krita 2.9 Animation Edition beta

I'm very happy to tell you, finally, a version of Krita supporting basic animation features is released ! (Check it here)

This is still in early stage, based on latest 2.9 version, with lot of additional features to come later from version 3.

If you want to have fun with it, here is a little introduction tutorial to get started, with some text and a video to illustrate it.

-Load the animation workspace to quickly activate the timeline and animation dockers.

-The timeline only has the selected layer. To keep a layer always visible on it, click on the plus icon and select the corresponding option (Show in timeline to keep the selected layer, or Add existing layer and select one in the list …)

-To make a layer animated, create a new frame on it (with the right-click option on the timeline, or with the button on the animation docker). Now the icon to activate the onion skins on it becomes visible (the light bulb icon), activate it to can see previous and next frames.

-The content of a frame is visible in the next frames until you create a new one.

-After drawing the first frame, go further in the timeline and do any action to edit the image (draw, erase, delete all, use transform tool, …). It creates a new frame with the content corresponding to the action you made.

-If you prefer to only create new frames manually, disable the auto-frame-mode with the corresponding button in the animation docker (the film with a pen icon).

-To move a frame in time, just drag and drop it to a new time position

-To duplicate a frame, press Control while you drag and drop it to a new time position.

-In the animation docker, you can define the start and end of the animation (to define the frames to use for export, and for the playback loop). You can also define the speed of the playback with the Frame rate value (frames per second) and the Play speed (multiplier or the frame rate).

-In the Onion Skins docker, you can change the opacity for each of the 10 previous and next frames. You can also select a color overlay to distinguish previous and next frames. You can act on the global onion skins opacity with the 0 slider.

-To change the opacity of several onion skins at the same time, press Shift while clicking across the sliders.

-To export your animation, use the menu entry File - Export animation, and select the image format you want for the image sequence.

Have fun animating in Krita, and don't forget to report any issue you find to help improve the final version ;)

24 Nov 2015 9:23pm GMT

digiKam Recipes 4.9.7 Released

A new release of digiKam Recipes is ready for your perusal. This version features the new Use Exposure Indicators recipe along with the updated Find the Shutter Count Value with digiKam recipe. Astute readers will also notice the new cover. That's all there is to it this time around.


Continue reading

read more

24 Nov 2015 10:40am GMT

23 Nov 2015

feedPlanet KDE

Game Art Quest Kickstarter!

Today an exciting new crowdfunding campaign kicks off! Nathan Lovato, the author of Game Design Quest, wants to create a new series of video tutorials on creating 2D game art with Krita. Nathan is doing this on his own, but the Krita project, through the Krita Foundation, really wants this to happen! Over to Nathan, introducing his campaign:

"There are few learning resources dedicated to 2d game art. With Krita? Close to none. That is why I started working on Game Art Quest. This training will show you the techniques and concepts game artists use in their daily work. If you want to become a better artist, this one is for you."

"We are developing this project together with the Krita Foundation. This is an opportunity for Krita to reach new users and to sparkle the interest of the press. However, for this project to come to life, we need your help. A high quality training series requires months of full-time work to create. That is why we are crowdfunding it on Kickstarter."

"But who the heck am I to teach you game art? I'm Nathan, a professional game designer and tutor. I am the author of Game Design Quest, a YouTube channel filled with tutorials about game creation. Every Thursday, I release a new video. And I've done so since the start of the year, on top of my regular work. Over the months, my passion for open source technologies grew stronger. I discovered Krita 2.9 and felt really impressed by it. Krita deserves more attention."

"Long story short, Game Art Quest is live on Kickstarter. And its existence depends on you!"

"Even if you can't afford to pledge, share the word on social networks! This would help immensely. Also, this campaign is not only supporting the production of the premium series. It will allow me to keep offering you free tutorials for the months to come. And for the whole duration of the campaign, you're getting 2 tutorials every single week!"

Check out Nathan's campaign: https://www.kickstarter.com/projects/gdquest/game-art-quest-make-professional-2d-art-with-krita.

23 Nov 2015 4:21pm GMT

Looking at the security of Plasma/Wayland

Our beta release of Plasma 5.5 includes a Wayland session file which allows to start in a Plasma on Wayland session directly from a login manager supporting Wayland session. This is a good point in time to look at the security of our Plasma on Wayland session.

Situation on X11

X11 is not secure and has severe conceptual issues like

This can be used to create very interesting attacks. It's one of the reasons why I for example think it's a very bad idea to start the file manager as root on the same X server. I'm quite certain that if I wanted to I could exploit this relatively easily just through what X provides.

The insecurity of X11 also influenced the security design of applications running on X11. It's pointless to think about preventing potential attacks if you could get the same by just using core X11 functionality. For example KWin's scripting functionality allows to interact with the X11 windows. In general one could say that's dangerous as it allows untrusted code to change aspects of the managed windows, but it's nothing you could not get with plain X11.

Improvements on Wayland

Wayland removes the threats from the X11 world. The protocols are designed in a secure way. A client cannot in any way interact with windows from other clients. This implies:

In addition the protocols do not allow to e.g. position windows themselves, or raise themselves, change stacking order and so on.

Security removed in Plasma

But lots of these security restrictions do not work for us in Plasma. Our desktop shell need to be able to get information of other windows (e.g. Tasks applet), be able to mark a panel as a panel (above other windows) and need to be able to position windows itself.

Given that we removed some of the security aspects again and introduced a few custom protocols to provide window management facilities and also to allow Plasma windows to position themselves. At the moment we have no security restrictions on that yet which gives this functionality to all clients.

We will address this in a future release. There are multiple ways how this could be addressed, e.g. using the Wayland security module library or use systemd in some way to restrict access. Overall I think it will require rethinking security on a Linux user session in general, more on that later on.

Security added in Plasma compared to X11

The most important change on the security front of the desktop session is a secure screen locker. With Plasma 5.5 on Wayland we are able to provide that and address some long standing issues from X11. The screen locks even if a context menu is open or anything else grabbing input. The compositor knows that the screen is locked and knows which window is the screen locker. This is a huge change compared to X11: the XServer has no concept of a screen locker. Our compositor can now do the right thing when the screen is locked:

As a matter of fact the Wayland protocol itself doesn't know anything about screen locking either. This is now something we added directly to KWin and doesn't need any additional custom Wayland interfaces.

How to break the security?

Now imagine you want to write a key logger in a Plasma/Wayland world. How would you do it? I asked myself this question recently, thought about it, found a possible solution and had a key logger in less than 10 minutes: ouch.

Of course there is no way to get a client to act as a key logger. The Wayland protocol is designed in a secure way and also our protocol additions do not weaken that. So the key to get a key logger is to attack KWin.

So what can an attacker do with KWin if he owns it? Well pretty much anything. KWin internally has a very straight forward trust model: everything is trusted and everything can access anything. There is not much to do about that, this is kind of how binaries work.

For example as a Qt application each loaded plugin has access to the QCoreApplication::instance. From there one could just use Qt's meta object inspection to e.g. get to the InputRedirection model and connect to the internal signal on each key press:

<code>void ExamplePlugin::installKeyLogger()
    const auto children = QCoreApplication::instance()-&gt;children();
    for (auto it = children.begin(); it != children.end(); ++it) {
        const QMetaObject *meta = (*it)-&gt;metaObject();
        if (qstrcmp(meta-&gt;className(), "KWin::InputRedirection") != 0) {
        connect(*it, SIGNAL(keyStateChanged(quint32,InputRedirection::KeyboardKeyState)), this, SLOT(keyPressed(quint32)), Qt::DirectConnection);

void ExamplePlugin::keyPressed(quint32 key)
    qDebug() &lt;&lt; "!!!! Key: " &lt;&lt; key;

But Martin, why don't you just remove the signal, why should any other aspect of KWin see the key events? Because this is just the example of the most trivial exploit. Of course it's not the only one. If you have enough time and money you could write more sophisticated ones. For example look at this scenario:

KWin uses logind to open restricted files like the input event files or the DRM node. For this KWin registers as the session controller in logind. Now a binary plugin could just send a DBus call to logind to also open the input event files and read all events. Or open the DRM node and take over rendering from KWin. There is nothing logind could do about it: how should it be able to distinguish a valid from an invalid request coming from KWin?

How to secure again?

As we can see the threat is in loading plugins. So all we need to do is ensure that KWin doesn't load any plugins from not trusted locations (that is not from any user owned locations). This is easy enough for QML plugins where we have the complete control. In fact it's easy to ensure for any of KWin's own plugins. We can restrict the location of all of them.

And even more: by default a system is setup in a way that no binary plugins are loaded from user's home. So yeah, no problem after all? Well, unfortunately not. During session startup various scripts are sourced which can override the environment variables to influence the loading of plugins. And this allows to also use the well known LD_PRELOAD hack. My naive approach to circumvent this issue didn't work out at all as I had to learn that already the session startup and the PAM interaction source scripts. So your session might be owned very early.

An approach to black list (unset) env variables is futile. There are too many libraries KWin relies on which in turn load plugins through custom env variables. Most obvious examples are Qt and Mesa. But there are probably many more. If we forget to unset one variable the protection is broken.

A different approach would be to white list some known secure env variables to be passed to KWin. But this also requires that at the point where we want to do the restriction the session is not already completely broken. This in turn means that neither PAM nor the session manager may load any variables into the session before starting the session startup. And that's unfortunately outside what we can do in our session startup.

So for Plasma 5.5 I think there is nothing we can do to get this secure, which is fine given that the Wayland session is still under development. For Plasma 5.6 we need to rethink the approach completely and that might involve changing the startup overall. We need to have a secure and controlled startup process. Only once KWin is started we can think about sourcing env variables from user locations.

So how big is the threat? By default it's of course secure. Only if there is already a malicious program running in the system there is a chance of installing a key logger in this way. If one is able to exploit e.g. a browser in a way that it can store an env variable script in one of the locations, you are owned. Or if someone is able to get physical access to your unencrypted hard disk, there is a threat. There are easy workarounds for a user: make all locations from where scripts are sourced during session startup non-writable and non-executable, best change ownership to root and encrypt your home location.

Overall it means that Plasma 5.5 on Wayland is not yet able to provide the security I would have liked to have, but it's still a huge improvement over X11. And I'm quite certain that we will be able to solve this.

23 Nov 2015 10:13am GMT

Interview with Christopher Stewart


Could you tell us something about yourself?

My name is Christopher, and I am an illustrator living in Northern California. When I'm not in a 2d mindset I like to sculpt with Zbrush and Maya. Some of my interests include Antarctica, Hapkido and racing planes of the 1930s.

Do you paint professionally, as a hobby artist, or both?

I have been working professionally for quite some time. I have worked for clients such as Ubisoft, Shaquille O'Neal and Universal Studios. I'm always looking for new and interesting work.

What genre(s) do you work in?

SF, Fantasy, and Comic Book/ Sequential art. This is where the foundation of my work lies - these genres have always been an inspiration to me ever since I was a kid.

Whose work inspires you most - who are your role models as an artist?

Wow, what a tough question! So many great artists out there.. Brom- definitely, N.C. Wyeth, George Perez, and Alphose Mucha. Recently I have revisited the background stylists of Disney with their immersive environments.

How and when did you get to try digital painting for the first time?

About 9 years ago. Until then my work was predominantly traditional. I wanted to try new mediums, and I thought digital painting would be a great area to explore.

What makes you choose digital over traditional painting?

Time and space.

Alterations and color adjustments can be done quickly for a given digital piece.

The physicality of traditional medium has different challenges, and usually the solution will take longer to accomplish with traditional mediums in general.

Digital painting doesn't take up a lot of space, a few decent sized stretched canvases..

How did you find out about Krita?

I had tried Painter X and CS and they were unsatisfying, so I was looking for a paint program. Krita was recommended by a long-time friend who liked the program, and I was hooked.

What was your first impression?

It was very intuitive. It had a UI that I had very few difficulties with.

What do you love about Krita?

I really really liked the responsiveness of the brushes. With other applications I was experiencing a "flatness" from the tablet I use to the results I wanted on screen, Krita's brushes just feel more supple. The ability to customize the interface and brushes was also a huge plus.

What do you think needs improvement in Krita? Is there anything that really annoys you?

I haven't been using Krita very long (less than 6 months) but I would like to be able to save and import/export color history as a file within an open Krita document.

What sets Krita apart from the other tools that you use?

When a company makes an application as powerful as Krita available for free, it's a statement about how confident they are that artists will love it. And judging from the enthusiastic and knowledgeable people in the forums, they not only love it they want others to be able to love it and use it too. Developing and experienced artists need to evaluate new tools easily. Access to those tools should never be so prohibitively costly as to turn them away. Krita doesn't get in the way of talent being explored, it supports it.

What techniques and brushes do you prefer to use?

I use a lot of the default brushes especially the Bristle brushes, a semi transparent texture to add to a plein air look as a final layer. I use some of David Revoy's brushes, specifically the Splatter brushes. I recently made a new custom brush that I tried out on my most recent illustration.

Where can people see more of your work?

My website is redacesmedia.com. You can reach me there!

Anything else you'd like to share?

Thank you so much for the interview and a special thanks to the developers and community that make Krita work!

23 Nov 2015 8:22am GMT