Anyone who has spent any time recently using non-GNOME GTK desktop environments, like Cinnamon, MATE, or Xfce, has had to deal with the unfortunate reality of a lot of GTK applications becoming GNOME applications instead, using GNOME’s own libadwaita. These applications are hard to theme, and do not integrate at all with the proper GTK applications non-GNOME desktop environments ship with. With how popular GNOME is, this has meant that the number of non-GNOME GTK applications has been dwindling.

Linux Mint, the popular Linux distribution that also develops the Cinnamon desktop environment, has long made a bundle of GTK applications called XApps – basically forks of various core GNOME 3.x applications to ensure they would have access to non-GNOME GTK applications. With GNOME effectively forking GTK into its own, unique, GNOME-specific style (like libaidwaita), other GTK environments have suffered, and XApps were intended to close that gap.

That hasn’t really happened though, as XApps remained mostly a Mint-only thing, managed by Mint, as part of the Mint/Cinnamon GitHub projects. Other distributions and GTK desktop environments, such as Xfce, MATE, Budgie, and so on, didn’t really pick them up. The Linux Mint project intends to change that, and will ‘spin off’ the XApps into its own, dedicated, independent project to facilitate cross-distribution and cross-DE collaboration, decision-making and development, all in an effort to ensure the long-term viability of non-GNOME GTK desktop environments.

They also intend to fork a lot more of the GNOME 3 applications, for the same reason I mentioned earlier: GNOME applications are no longer GTK applications, but GNOME applications – they look and feel horribly out of place in environments that don’t use the GNOME-specific libadwaita. As such, Celluloid, GNOME Calculator, Simple Scan, Baobab, System Monitor, GNOME Calendar, File Roller, and Zenity were recently downgraded in Linux Mint to their last GTK 3 versions, and will most likely be forked in the near future.

In addition, the Adwaita theme, the default GNOME/GTK theme, will be removed from the list of available themes in Cinnamon 6.2. Adwaita, too, has become increasingly GNOME-only, and thus, increasingly broken on non-GNOME desktop environments. Flat-our removing Adwaita altogether is not possible, since it’s a GTK dependency, but hiding it from the theme selector is not an issue, of course.

As project lead Clément Lefèbvre writes:

libAdwaita is for GNOME and GNOME only. We can’t blame GNOME for this, they’ve been very clear about it from the start. It was made specifically for GNOME to have more freedom and build its own ecosystem without impacting GTK.

We want to send a strong signal upstream and towards other projects. We cannot and will not support applications which do not support our users and environments.

We can’t promote applications to our users which don’t support our users. The software manager will be vigilant towards that going forward and list compatible software by default.

↫ Clément Lefèbvre

All of this is great news to hear. I’ve been making extensive use of Xfce on OpenBSD lately, and on the Fedora Xfce spin in the weeks before that, and the situation has become almost comical. If you install any GNOME application on Xfce, theming just breaks down completely, as most themes are either not made to support the massive headerbars GNOME uses, or they do support it but still look horribly out of place compared to the more sane titlebar plus menubar plus toolbar layout of traditional desktop environments like Xfce.

I’ve long been saying that the non-GNOME GTK desktop environments need to work together to formulate an answer to the onslaught of libadwaita and the GNOME-ification of GTK, because each of them risks becoming entirely tied to whatever GNOME and libadwaita decides to do, for better or worse. It seems the Linux Mint team has finally realised this as well, and I really hope – and strongly suggest – Xfce, MATE, and others join them as well.

If they don’t, there won’t be an Xfce in a few years. What’s the point in developing Xfce if you’re at the mercy of whatever choices GNOME makes?

Apple has removed WhatsApp and Threads from its app store in China, following an order from the country’s internet watchdog which cited national security concerns.

↫ Juliana Liu at CNN

Over the recent months, as Apple had to change some of its business practices to comply with the European Union’s new Digital Markets Act, a still-ongoing process, Apple fans, spearheaded by John Gruber, have pushed Apple to leave the European Union. They argue that the minor inconvenience of complying with some basic consumer and market protection laws is too great of a deeply unfair financial sacrifice, and that leaving the EU makes more sense. Gruber also goes to bat hard for poor Facebook, arguing that company should leave the EU, too, over the DMA demanding Facebook respects users’ privacy. Apple itself, too, has been harshly attacking the European Union aggressively in the media.

So anyway, today, Apple did what it has been doing for a very long time: bending over backwards for the totalitarian, genocidal regime in China. China tells Apple to remove applications, Apple complies. Every other of the sixteen hundred times Apple has complied with this horrible regime’s demands, Gruber always argued that all poor Apple can do is comply with local Chinese laws and demands, as leaving China over principles and morals would benefit nobody.

So, we’re left with the rather peculiar situation where the response to some relatively minor consumer and market protection regulations is one of deep hostility, both from Apple as well as its PR attack dogs, whereas the response to the demands from one of the most brutal, totalitarian, genocidal regimes in human history is one of “that’s life”. Such is the way of the Apple corporatist: a democratically drawn up and widely popular law enacted by an incredibly popular government that causes some mild inconvenience for Apple is vilified with populist and nationalist anti-EU rhetoric, while the undemocratic, totalitarian decrees from a vicious genocidal dictator are met with effectively disinterested shrugs since those decrees don’t really inconvenience Apple.

Corporatism and fascism are two sides of the same coin, from early 20th century Europe, through mid-20th century United States, to the megacorporations of today.

Despite yet another decree from China that goes far further in nature than anything the DMA demands, we won’t be seeing any pushes from the Grubers of this world for Apple to leave China. We won’t be seeing copious amounts of malicious compliance from Apple. We won’t be treated to lengthy diatribes from Apple executives about how much they despise China and Chinese laws. All because China’s demands don’t harm Apple’s bottom line, but the DMA might.

And for the corporatist, praying at the altar of money, the former is irrelevant, while the latter is sacrilege.

One of the things I’ve always wanted to experiment with on my computers is logging in and authenticating things like sudo requests with a hardware tool – a fingerprint reader, a smart card, or a USB hardware security device like a YubiKey. There’s really no solid reason for me to want this other than that it just feels cool and futuristic to me (yes, even in this, the year of our lord 2024). I have no state secrets, no secret Swiss bank accounts, no whistleblower material to protect, and my computers rarely leave the house – I just want it because it’s possible and cooler than typing in my password.

Due to the flexibility and feature set of the YubiKey, I think it’s the best choice to go for. A no-name USB fingerprint reader would probably be ugly, cumbersome to position, and Linux support would be difficult to determine. A USB smart card reader would bring the same issues as the fingerprint reader, and combined with a smart card it seems like it’s just a Yubikey with extra steps. I do have to admit the idea of sliding a smart card in a slot and have it authorise you sounds really, really satisfying.

Anyway, YubiKeys come in all shapes and sizes, but I want one of the USB-A ones with a fingerprint reader built-in, since I can plug it in at the bottom of my monitor, perfectly positioned to put my thumb on it to authenticate. This way, it’s easily accessible to be used to log into my desktop session, authorise sudo requests when I’m configuring things, log into websites with Firefox, and so on.

But there’s a problem: setting up a YubiKey on Linux seems like it’s a huge ordeal.

Just look a the official instructions on the YubiKey website, or the instructions on the Fedora website, my distribution of choice. That’s absolutely insane, and nobody should be expected to understand any of this nonsense to use what is being marketed as a consumer product. It’s important to note that this is not a hardware, software, or driver issue – all the necessary support is there, and Linux can make full use of the functionality tools like the YubiKey offers. The problem is that you’re expected to set this up manually, package by package, configuration file by configuration file, PAM module by PAM module.

When I first looked into getting a YubiKey, I expected biometric and advanced authentication tools like these to be fully integrated into modern Linux distributions and desktop environments. I figured that once you plugged one of these tools into your PC, additional options would become available in GNOME’s or KDE’s user account settings, but apparently, this isn’t the case. This means that even if you manually set everything up using the official arcane incantations, your graphical user interface won’t be aware of any of that, and changing anything will mean you have to go through those official arcane incantations again.

This is entirely unacceptable. The moment you plug in an an advanced hardware security tool like a YubiKey, GNOME and KDE should recognise it, and the settings, tools, and setup ‘wizards’ relevant to it should become available. All the hardware and software support is there – and in 2024, biometric and advanced security devices like these should not be so complicated and unforgiving to set up. Smart cards and fingerprint readers have been supported by Linux for literally decades. Why isn’t this easier?

For now, I’m still in doubt about going through with buying a YubiKey. I definitely have the skills to go through with this whole insane setup process, but I really shouldn’t have to.

As some of the dust around the xz backdoor is slowly starting to settle, we’ve been getting a pretty clear picture of what, exactly, happened, and it’s not pretty. This is a story of the sole maintainer of a crucial building block of the open source stack having mental health issues, which at least partly contributes to a lack of interest in maintaining xz. It seems a coordinated campaign – consensus seems to point to a state actor – is then started to infiltrate xz, with the goal of inserting a backdoor into the project.

Evan Boehs has done the legwork of diving into the mailing lists and commit logs of various projects and the people involved, and it almost reads like the nerd version of a spy novel. It involves seemingly fake users and accounts violently pressuring the original xz maintainer to add a second maintainer; a second maintainer who mysteriously seems to appear at around the same time, like a saviour. This second maintainer manages to gain the original maintainer’s trust, and within months, this mysterious newcomer more or less takes over as the new maintainer.

As the new maintainer, this person starts adding the malicious code in question. Sockpuppet accounts show up to add code to oss-fuzz to try and make sure the backdoor won’t be detected. Once all the code is in place for the backdoor to function, more fake accounts show up to push for the compromised versions of xz to be included in Debian, Red Hat, Ubuntu, and possibly others. Roughly at this point, the backdoor is discovered entirely by chance because Andres Freund noticed his SSH logins felt a fraction of a second slower, and he wanted to know why.

What seems to have happened here is a bad actor – again, most likely a state actor – finding and targeting a vulnerable maintainer, who, through clever social engineering on both a personal level as well as the project level, gained control over a crucial but unexciting building block of the open source stack. Once enough control and trust was gained, the bad actor added a backdoor to do… Well, something. It seems nobody really knows yet what the ultimate goal was, but we can all make some educated guesses and none of them are any good.

When we think of vulnerabilities in computer software, we tend to focus on bugs and mistakes that unintentionally create the conditions wherein someone with malicious intent can do, well, malicious things. We don’t often consider the possibility of maintainers being malicious, secretly adding backdoors for all kinds of nefarious purposes. The problem the xz backdoor highlights is that while we have quite a few ways to prevent, discover, mitigate, and fix unintentional security holes, we seem to have pretty much nothing in place to prevent intentional backdoors placed by trusted maintainers.

And this is a real problem. There are so many utterly crucial but deeply boring building blocks all over the open source stacks pretty much the entire computing world makes use of that it has become a meme, spearheaded by xkcd’s classic comic. The weakness in many of these types of projects is not the code, but the people maintaining that code, most likely through no fault of their own. There are so many things life can throw at you that would make you susceptible to social engineering – money problems, health problems, mental health issues, burnout, relationship problems, god knows what else – and the open source community has nothing in place to help maintainers of obscure but crucial pieces of infrastructure deal with problems like these.

That’s why I’m suggesting the idea of setting up a foundation – or whatever legal entity makes sense – that is dedicated to helping maintainers who face the kinds of problems like the maintainer of xz did. A place where a maintainer who is dealing with problems outside of the code repository can go to for help, advice, maybe even financial and health assistance if needed. Even if all this foundation offers to someone is a person to talk to in confidence, it might mean the difference between burning out completely, or recovering at least enough to then possibly find other ways to improve one’s situation.

If someone is burnt-out or has a mental health crisis, they could contact the foundation, tell their story, and say, hey, I need a few months to recover and deal with my problems, can we put out a call among already trusted members of the open source community to step in for me for a while? Keep the ship steady as she goes without rocking it until I get back or we find someone to take over permanently? This way, the wider community will also know the regular, trusted maintainer is stepping down for a while, and that any new commits should be treated with extra care, solving the problem of some unknown maintainer of an obscure but important package suffering in obscurity, the only hints found in the low-volume mailing list well after something goes wrong.

The financial responsibility for such a safety net should undoubtedly be borne by the long list of ultra-rich megacorporations who profit off the backs of these people toiling away in obscurity. The financial burden for something like this would be pocket change to the likes of Google, Apple, IBM, Microsoft, and so on, but could make a contribution to open source far greater than any code dump. Governments could probably be involved too, but that will most likely open up a whole can of worms, so I’m not sure if that would be a good idea.

I’m not proposing this be some sort of glorified ATM where people can go to get some free money whenever they feel like it. The goal should be to help people who form crucial cogs in the delicate machinery of computing to live healthy, sustainable lives so their code and contributions to the community don’t get compromised. This means not just doling out free money, but also helping people connect to the therapists, doctors, debt restructuring experts and whatever other specialists we all sometimes need in our lives to help us get back on track.

I’m not going to pretend to know how something like this should be set up, organised, or run, and this article and suggestion are more borne out of frustration with how we’re letting these crucial and hard workers hang out to dry and fend for themselves, but it’s obvious the industry needs to do something. If we don’t, we’re going to be seeing a lot more of the kind of orchestrated, sophisticated attacks like the one xz just experienced.

Open source is more than just code, and it’s about damn time we acknowledge that.