Background

I am Ayush Singh, a second-year student of the Indian Institute of Technology, Dhanbad, India. My application has been accepted in the Season of KDE 2022. I will be working on writing a Rust wrapper for KConfig KDE Framework. This post describes my journey with KDE and why I submitted this Project for the Season of KDE.

My Introduction to Linux

I was introduced to the world of Linux back in 2016 when I was working on compiling android from source. Like most people, I started with Ubuntu. I didn’t explore Linux much at the time other than building android, and that was it.

However, things changed in 2018 when I got my PC. Since I already knew about Linux, I decided to dual-boot and explore a new operating system. Slowly, I stopped using the Windows partition and removed it altogether in early 2020.

My Introduction to KDE

I was first introduced to KDE when I switched to OpenSUSE Tumbleweed. I didn’t pay much attention to KDE at the time and quickly moved on. After this, I started using standalone window managers (like i3, AwesomeWM) for quite a while. The next time I actively used KDE was in the summer of 2020 when the lockdown began, and my school exams got postponed indefinitely. During that time, I discovered KDE Activities which completely changed my workflow. Since then, I have tried Gnome and standalone windows managers; however, none seem to offer the same level of coherence and flexibility as KDE. Also, did I already mention how much I love KDE Activities?

As for KDE Development, I am somewhat inexperienced. I have also opened Bugs in KDE and two merge requests, but they were pretty minor. Season of KDE will also allow me to get better acquainted with KDE Development.

Past Experience with Qt

I have used Qt Framework to write GUI applications in C++ for my School projects.

1. In 2019, I made a Calculator.
2. In 2020, I made a Library Management software.

Both of them used Qt Widgets since I didn’t know about QML at the time.

My Introduction to Rust

I had been interested in Systems Programming in the past. During the lockdown, I came across Rust Language. I quickly got interested in its promise of performance and safety and being more modern than C in general. After reading the Rust Book, I used Rust to create simple projects, like a web crawler and a magic bytes reader. I now understand that, like all programming languages, Rust has its strengths and weaknesses. However, I still love working with Rust.

Trying to use Rust in KDE

In June of 2021, I thought about writing a Web Browser for some reason. I did not want to use the Blink engine. I had previously heard about Servo and decided to use it. While doing that, I started searching for GUI toolkits in Rust since Servo is written in Rust. I wanted to use Qt with Rust, but I quickly found out that using Rust with Qt was more difficult than I would like. At around the same time, Gtk-rs was made official with Gtk4, which seemed to work great. I tried switching to Gnome for a while after that but ultimately failed.

Sadly, I never created that web browser. However, I did come out with a new conviction. I decided to make the missing tooling required to develop KDE/QML applications with Rust without writing any C++.

I started by looking into already existing crates for Qt development with Rust. I found qmetaobject crate, which was closely aligned with how I wanted Rust + Qt development to be. To create Kirigami applications using qmetaobject, I created bindings for the KI18n Localization framework (kconfig crate). It was used with almost all Kirigami applications and thus was a natural starting point. I also created a Rust crate for linking Kirigami Framework to the Rust application. While working on these bindings, I also contributed the qmetaobject upstream since some of the methods and enums I required were missing for qmetaobject. This helped me get familiar with Rust memory management, which I had previously taken for granted.

Applying for Season of KDE

I already knew about the Season of KDE and decided to apply for it. I submitted a proposal about writing “Rust wrapper of KConfig”. Since I was already working on the KI18n wrapper, I had the necessary experience to make this possible.

After some searching in the KDE mailing list, I came across Jos van den Oever, the author of Rust Qt Bindings Generator. He agreed to become my mentor for the Season of KDE. This project might have been delayed if he hadn’t decided to mentor me. He also helped me with this blog and some other KDE Community stuff.

Now, I will cover some information about my Season of KDE Project.

My Season of KDE Project

Overview

I will create a wrapper crate for KConfig KDE Framework in Season of KDE. It will allow the usage of KConfig from Rust projects without writing C++. The crate will be dependent on qttypes, which wraps a lot of QML types and makes them available in Rust. While I will mainly be testing it with qmetaobject, I would like to avoid having any hard dependency on it. My goal is to make the bindings safe while having as little overhead as possible.

Finally, I would like to find a way to have something similar to KConfigXT for Rust. This is a bit of a lofty goal, and I’m not entirely sure how to achieve it. However, I think KConfigXT is one of the best features of KConfig, and I don’t believe the wrapper would be complete without it.

The kconfig bindings crate is available here. Feel free to test it out and report Bugs.

Goals

Creating bindings for more languages allows bringing more people to the KDE Community. Currently, Qt only has good support for C++ and Python. Rust promises to provide a safe and performant language with modern conveniences like a good package manager, async support, etc. As such, I think it can be pretty helpful to promote the use of Rust in KDE.

C++ is a great language, so I don’t believe in rewriting everything in Rust. However, we should use it in places where it is better than C++. For example, Rust is excellent for parsers and thus can be used in KDevelop and Kate.

Currently, the barrier for using Rust in KDE is very high, which discourages most people from giving it a shot. This means that most Rust programmers never give KDE much of a chance, and in turn, there has been very little progress with Rust in KDE.

I want to create bindings for enough components that simple Kirigami applications can be written entirely in Rust. Since QML UI is already mostly decoupled from the C++ backend in most applications, writing the backend in Rust instead of C++ is not as difficult as trying to use QtWidgets from Rust. This should attract new application developers to consider Rust a viable option.

Future

Making bindings between KDE and Rust shows surpringing contrasts between the two languages. In the next post, I’ll explore how QtFlags can be used in Rust.

Helpful Links for Rust/Qt Development

1. qmetaobject
2. Rust Qt Binding Generattor
3. ki18n crate
4. kconfig crate
5. rust-qt-template
6. kirigami crate
7. kde frameworks crate

There is a local privilege escalation in Polkit (formerly PolicyKit, and used in plenty of places where privilege escalation is needed). It was found by Qualys, and carefully documented on the oss-sec mailing list. It has hit the mainstream media fairly hard, too – probably because it follows closely on unrelated log4j and faker.js issues in Open-Source-land. I’m not a security specialist by a long shot (not by at least 3 light-seconds, even), but let’s take a brief look at execve() in FreeBSD.

The description below applies to FreeBSD’s execve() as it is today. This morning. Right now when I write it, because there is a review to fix the root cause of the issue which will surely roll out quickly. In the meantime I landed updates to the polkit package last night, although navigating-the-security-notifications parts have not finished yet.

In UNIX talk, when one process wants to start another, there is a “fork-exec dance”. The one process makes a copy of itself, proceeding as two separate processes, and then exec is called, which replaces a process by a different one from another executable. The most common program (process) that starts other processes is the shell. When you do this in a terminal:

$ ls

Aside from all the other things going on, the shell is going to fork itself and then one of the two will replace itself by the executable for ls. The ls executable then runs, does its thing, and exits. Afterwards, there is one shell process left.

The current API for exec – for replacing the running process by different one from another executable – is execve(). Here is a snippet from the manpage:

     int
     execve(const char *path, char *const argv[], char *const envp[]);

     The execve() system call transforms the calling process into a new
     process.  The new process is constructed from an ordinary file, whose
     name is pointed to by path, called the new process file.
     
     The argument argv is a pointer to a null-terminated array of character
     pointers to null-terminated character strings.  These strings construct
     the argument list to be made available to the new process.  At least one
     argument must be present in the array; by custom, the first element
     should be the name of the executed program (for example, the last
     component of path).

Here is a complete program that uses execve(). The intention is that this program just replaces itself with ls. Running ls with no arguments usually lists the files in the current directory. With arguments, there’s command-line option processing and then the named files or directories are listed.

#include <unistd.h>

int main(int argc, char **argv)
{
    char * const bogus_argv[2] = {NULL, NULL};
    char * const bogus_envp[2] = {"PS1=$", NULL};
    int r = execve("/bin/ls", bogus_argv, bogus_envp);
    return 0;
}

Let’s take a look at some of the lines of this program.

    char * const bogus_argv[2] = {NULL, NULL};

Here we have an array of pointers, ready to act as the argv for the program we’re going to run. Note that both pointers are set to NULL, so we’re violating the constraint mentioned in the manpage: here there are zero arguments in the null-terminated array. But there’s two NULLs, so we can at least pretend that we’re compliant: if there were a non-null pointer which would customarily point to the name of the program, the array would look like {"ls", NULL}. So we have a suitable null-terminator in place.

    char * const bogus_envp[2] = {"PS1=$", NULL};

This is a very minimal environment. PS1 is the name of the variable – it’s the shell prompt. The value $ is what you traditionally have in the POSIX shell.

    int r = execve("/bin/ls", bogus_argv, bogus_envp);

The current process (this program whose source I show above) is replaced by the executable which is in the file /bin/ls – that’s the ls program we know and love. We pass in the bogus argv, which violates the constraints described for execve(), and the very simple environment.

Personally I expected ls to run and list the current directory. After all, even without the name-of-the-program as the first argument, the argv array is null-terminated. Nope.

$ cc t.c && ./a.out 
: PS1=$: No such file or directory

Somehow we’re reaching the environment pointers, which are interpreted as arguments to ls. Replace the first NULL in the assignment to bogus_argv by anything else, including "", and the program behaves as I expected. Not with a bunch of NULLs, though. Making the bogus_argv longer, e.g. with 16 NULLs, doesn’t help: all of them are ignored and the environment leaks into the arguments of ls.

Takeaway

OpenBSD did it right in 2015 (quoting a Twitter message from Bryan Steele, @canadianbryan):

date: 2015/02/07 08:47:49;  author: tedu;  state: Exp;  lines: +7 -1;
forbid execve() with argc == 0. prompted by a millert email.
ok deraadt miod

FreeBSD is going to do it right (in review), and maybe even Linux is going to do it right (via Ariadne Conill, @ariadneconill on Twitter, this patch).

Qt Quick 3D has some new features in 6.2. One of them is that you can map interactive Qt Quick scenes onto 3D objects.

During a hackathon last year, we developed the Kappa Tau Station demo: a model of a space station in which you can use the WASD keys to walk around (as in many games), but also containing some 2D UI elements on some surfaces. For example you can:

Let's welcome Latte Dock v0.10.8 the 8^th Official Bug Fix Release of v0.10.x branch!

 

Go get it from, download.kde.org^*

Fixes

• multi-screen: fix docks/panels screen repositioning when the user specifies different screen for dock or panel
• fix borders identification for autopositioning vertical docks/panels
• fix vertical docks/panels autopositioning which is relevant to top and bottom panels
• position kwin edges helper window properly on startup after offscreen positioning
• x11: center applets config window on screen
• do not shrink vertical docks/panels on startup after switching from offscreen to onscreen
• make dock and panel work properly when they undo their removal

Kubuntu Hirsute Hippo was announced on April 22, 2021 with 9 months support.

As of January 20, 2022, 21.04 reached ‘end of life’.

No more package updates will be accepted to 21.04, and it will be archived in the coming weeks.

You can read the official end of life announcement for Ubuntu as a whole.

Kubuntu 20.04 Focal Fossa and 21.10 Impish Indri continue to be supported.

Users of 21.04 can follow the Kubuntu 21.04 to 21.10 Upgrade instructions.

Should for some reason your upgrade be delayed, and you find that the 21.04 repositories have been archived, instructions to perform a EOL Upgrade can be found on the Ubuntu wiki.

Thank you for using Kubuntu 21.04 Hirsute Hippo.

Up to today, Okular would kind of error out when opening a PDF file that contains a signature field that was unsigned (think like the old space in paper forms saying "sign here")

It would tell you "document is signed but can't be properly validated"

And that was it, you couldn't do much with the signature. When you tried to "see" it all the fields would be default like "Signed at 1 Jan 1970", etc.

With the new code we properly detect that there are unsigned signatures and we offer to sign them when interacting with it

Relevant merge requests:

https://invent.kde.org/graphics/okular/-/merge_requests/539

https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1026

First Try (ft. failure)

I usually learn something between semesters when I have holidays. During September - October 2021, I tried learning some Qt and looking around codebase for KDE apps. But something just didn't work out. I suspect my leaning style wasn't correct.

Transitioning to 2022

November - December was very busy, with college asking us to appear in person. I had practicals and exams.

Starting Christmas, I was supposed to be free during holidays, and hopefully learn some Qt. Something unexpected happened again. A university society I had joined wanted to push out update to one of their apps. I like Flutter, but the way this team worked was simply not my style. I managed to get it done by 8th Jan, and in a series of crisp conversations made it clear I won't be able to help the society further.

During holidays, the SoK announcement mail arrived in my inbox. Most of the ideas were above my knowledge paygrade, but I almost jumped to the ceiling when I saw the word "packaging". No I've never worked with Flatpak before, but I have basic understanding of packaging, and it is in fact, one of the things I take a lot of interest in.

Flashbacks

While my first touch with Linux was in 2014, I could use it on my machine only in 2016. One of the most striking features was that you could install any software (subject to availability) along with its dependencies with a single command.

Much later in 2019, I finally decided to try and understand how packaging on Linux distros work, because I wanted to package applications for the distro I was using at the time. I failed though.

In March 2020, I switched to Endeavour OS and thats when the picture got a lot clearer.

PKGBUILDS ft. success (yay!)

These are build scripts to package applications for pacman, the package manager for Arch Linux. Its stupidly simple to understand, and easy to work with and test.

Out of interest, I decided to publish a python application to AUR. With some help from a user on Endeavour OS forum, I was able to get it right and publish.

I took some more trivial packages later on. I published my application crabfetch too. I adopted two applications, MapTools and BreakTimer. These two are the ones that require regular updates.

Thanks to Endeavour OS...

Back when I signed up on the Endeavour OS forum in April 2020, I didn't expect I'll one day join them. Till date I haven't taken up any task that requires significant effort from me. But I have taken up multiple tiny tasks here and there. I maintain Bspwm and Openbox community editions. Once in a blue moon write tutorial (2 published till yet; one in draft). I do some testing before ISO releases.

Frankly speaking, these might be trivial tasks, but working with a group of experienced people was certainly a head start for an 18 year old. There's much to be thankful about. I still get friends asking me "how to get started with open source" and similar questions. I realize Bryan served me the opportunity on a silver platter.

On the KDE Flatpak Matrix channel

The KDE Flatpak channel on Matrix is exactly my liking. My submissions usually got reviews within reasonable time. I packaged some applications before the contribution period officially started. With some help from Aleix Pol and Albert Cid, I was even able to send some patches to KDiskFree, which was my first contrubution to a Qt/C++ application. (thanks!)

My mentor is Timothée Ravier. I had a quick chat with him today evening (24th Jan). He briefed me about what all I will be working on during the next two and half months. He's a sweet person to talk with. (thats probably the case with everyone at KDE)

Hoping to learn and contribute over the coming weeks. Big thanks to KDE for giving me the chance to work with the team as a part of Season of KDE 2022!

Link to project on ideas page : https://community.kde.org/SoK/Ideas/2022#KDE_Apps_packaging_as_Flatpak_for_Flathub

Projects announcement: https://dot.kde.org/2022/01/26/season-kde-kicks

Keyboards and Open-Source, how is that related?

In my Keyboard Fun post from last year I talked a bit about my interest in mechanical keyboards.

Since then, I played around with a few more keyboards/switches/keycaps/…

Interesting enough, beside the actual hardware, naturally there is some software component to all these keyboards, too.

Whereas most commercial keyboards still come with proprietary firmware, there is the trend within the keyboard enthusiast scene to go for open-source firmware.

This allows you to properly update the firmware even from your Linux machine and do proper configuration of e.g. the keymap, too.

QMK Firmware

A popular project in that area is QMK.

I supports a mass of keyboards out of the box already and is actively extended by both volunteers and some companies.

That means it is deployed not only on main stream products but even in more exotic projects like the “I improve my vintage and modern Model M keyboards” by Eric S. Raymond.

VIA

Whereas QMK provides the open-source firmware part and you can do close to everything with it that is possible, given the features your hardware actually has, it is hard for simple task like “I want that my key x does y”.

Naturally you can change the keymap in your QMK port and compile & flash. But even I would call this a sub-optimal workflow, given a lot of commercial offerings at least provide some GUI to do this on the fly.

Here VIA comes into the picture.

For sure, it is an Electron based monster, but it provides a cross-platform UI for QMK based keyboards that allow on the fly configuration of at least the common things, like keymaps. And it provides trivial things like testing all your keys, which is not that unneeded, given I was too dumb to properly install all my hot-swap switches ;)

Actual Keyboard?

Naturally, after this talk about the software side, all this makes no sense without an actual keyboard using it.

As I use the German ISO layout for typing, I am more limited on product choices than e.g. people using the ANSI layout.

It is really frustrating that where ever you look for some cool keyboard project, in many cases no ISO variant is available. And yes, I don’t want to switch to ANSI, I like to have my umlauts easily accessible and I can’t swap all keyboards I need to use at work with ANSI variants, others would be not amused.

Therefore, if you are in need of some ISO layout keyboard, you might be interested in the information below. If you use ANSI, ignore all this, there are masses of ANSI keyboards out there to buy, with QMK, too. I have done no great research how the keyboard I did choose compares to them, for ISO there were not that many available contenders that were 75%, hot-swap and QMK ready.

After some trial and error I went with a Keychron Q1 75% keyboard. It is available in ISO layout, unfortunately only as bare bone kit, that means you must buy your own switches and keycaps. It naturally comes already with factory installed QMK, nice, above the VIA screenshot was actually from this board on my Linux machine.

For switches, I went with some BOX Navy switches, they are very heavy but have a nice click ;) Even my office neighbor is happy with the sound and hasn’t yet attacked me. I won’t link random reviews of them, you can search for that yourself if you are interested. In any case, yes, they are HEAVY, really, you can believe that from the reviews. And they are loud, but in no bad way.

For keycaps, yeah, same issue with the German ISO layout, there are not many sets that are available.

At work I now have some SA profile set from Signature Plastics, they are able to produce sets with proper legends and no missing German keys, unlike some other vendors I tried (and yes, I tried it with cheap vendors, it seems not to be trivial at all print all the proper German keys at all and not just forget them in the package…). Funny enough, shipping from US did take 4 weeks, even with air express, USPS seems to be not the fasted variant of travel. If others play with the idea to buy there, I must confess the quality is really good, but they are expensive, if you don’t require exotic layouts like German, I would rather go with some cheaper sets, for US ANSI even the cheapest I tried out were ok, without obvious faults.

If you look a bit more around on the picture you will see I have still my good old Nokia rubber ducky, a sole survivor from the time Nokia owned Qt :P And no, I don’t use a Mac, that is just one we use for our compile farm.

At home I went with some MT3 profile set without any legends, that is really cheap and funny enough did take only 4 days from US to Germany with standard UPS.

:=) And no, no second Nokia ducky at home.

So far, the Q1 works nicely, both at work and at home. Having the exact same layout and switches in both places really helps to get used to it.

Using VIA works nicely, too. So far I have not flashed any updated QMK version, therefore no experience how well that works in practice.

I actually even learned a bit more about my use of the different keys. On the work picture you still see on the right the page up/down buttons (with Fn key => home/end). At home I already reprogrammed that to home/end (with Fn key => page up/down), as I use that far more often during editing whereas the page up/down stuff just rarely in the terminal. Actually, I didn’t know I would miss these two keys until they were no longer easy accessible ;=)