Security, security, security! Patches, patches, patches! This happened to me before, but poor me, I forgot about it, for it’s been years since I wasn’t into Ubuntu anymore. Updated with other discoveries.

For goodness’ sake, what does it mean to be a professional these days? For the WHO, it meant to put that idiot of Tedros Adhanom Ghebreyesus on TV, saying “Test, test, test!”, when it was too late to contain the pandemic through testing. But I thought there’s still some meaning into the syntagm IT professional. It looks like I was wrong.

The context

Following some recent adventures, I was examining Xubuntu 21.04. You know, something more “pure” than a derivative of I don’t know what. An official flavor, to which people from the XFCE team have contributed directly. Even if XFCE might not have the brightest future, I said, what the heck, let’s revisit it.

It looks ugly by default (every single edition of Xubuntu looks like shit). I cannot stand docks or imitations of them (I hate macOS). I cannot stand windows that minimize on an upper panel (most people on Earth use a bottom panel for that). But xfce4-panel-profiles now has a “Redmond 7” layout in version 1.0.13, and this quick setting is a good starting point. Add to this Yaru Dark, and it would look nice enough:

Mostly, not fully OK. The integration of the CSD idiocy has created apps that don’t use CSD in their main window, but do use CSD in the About box, with the results of different close buttons! There might be themes that mitigate this effect, but yaru-theme-gtk is not one of them.

Oh, and the “Redmond 7” layout doesn’t brink the proper key bindings. For instance, they preferred Ctrl+Escape to SuperL (the left Windows key) to open xfce4-popup-whiskermenu, but this can be changed. Who is using Ctrl+Escape these days, even in Windows?!

The issue at hand

But using Xubuntu 21.04 revealed me a situation. Houston, we have a problem. I noticed that in Xubuntu 21.04, there is no update for the included Thunar 4.16.6, whereas in other distros there’s 4.16.8 available. Why is this important?

Because of CVE-2021-32563:

An issue was discovered in Thunar before 4.16.7 and 4.17.x before 4.17.2. When called with a regular file as a command-line argument, it delegates to a different program (based on the file type) without user confirmation. This could be used to achieve code execution.

This doesn’t look critical to me (but important nonetheless), having a CVSSv2 Score 7.5 (High), but for some reason the CVSSv3 Score is 9.8 (Critical). Fixes were made available even before the CVE was published on May 11, but what did Ubuntu do?

■ Here’s what Ubuntu did on May 14: they only pushed Thunar 4.16.8 in Impish, the development branch that will become (X)ubuntu 21.10!

4.16.8-1
Published in impish-release on 2021-05-14
Deleted in impish-proposed (Reason: Moved to impish)

Debian pushed Thunar 4.16.8 in unstable on May 13, and in testing on May 20:

thunar (4.16.8-1) unstable; urgency=medium
  * New upstream version 4.16.8 
    - includes fix for CVE-2021-32563: don't directly execute a file passed as
    an argument but rather open the containing folder (Closes: #988394)
-- Yves-Alexis Perez corsac@debian.org  Thu, 13 May 2021 20:14:27 +0200
From: Debian testing watch noreply@release.debian.org
Subject: thunar 4.16.8-1 MIGRATED to testing
To: thunar@packages.debian.org
Date: Thu, 20 May 2021 04:39:07 +0000
FYI: The status of the thunar source package
in Debian's testing distribution has changed.

Previous version: 4.16.3-1
Current version: 4.16.8-1

Arch Linux has updated Thunar to 4.16.8 on May 7:

thunar 4.16.8-1
Architecture: x86_64
Repository: Extra
Last Packager: Evangelos Foutras
Build Date: 2021-05-07 13:58 UTC
Signature Date: 2021-05-07 13:59 UTC
Last Updated: 2021-05-07 14:00 UTC

Manjaro did well too, but they being imbeciles, their Thunar package page lists the antiquated version from XFCE 4.14, and the title is wrong, and there’s no screenshot for something that should have had one. (They’re infinitely stupid to have listed all the packages in a single page that puts a huge stress on the browser, and in which a search for thunar only finds thunar-gtk3, which is even older.) But we can look in a repo and find thunar-4.16.8-1:

Sometimes, rebuilding the upstream (Arch) packages is very fast!

■ Other distros to have provided official updates to Thunar 4.16.8 include: Fedora 34, OpenMandriva Rolling, openSUSE Tumbleweed. Since PCLinuxOS follows the bleeding edge 4.17 branch, they have the vulnerability-free Thunar 4.17.3.

The root cause

Why are things this way? Ubuntu Security FAQ:

Ubuntu is currently divided into four components: main, restricted, universe and multiverse. All binary packages in main and restricted are supported by the Ubuntu Security team for the life of an Ubuntu release, while binary packages in universe and multiverse are supported by the Ubuntu community.

A moderator on Ask Ubuntu:

Even in Debian, there are many many packages that don’t get regular security updates. …

However, the consideration point is that the security team isn’t going to be fluent in all packages, and will rely on the support from package maintainers and upstream devs as well to ‘fix’ problems. …

Upon further discussion in the Debian Security IRC channel, it was said that my analysis here sums up the situation nicely: The Debian security team provides support for all with the help of package maintainers and upstream, but they don’t personally patch everything.

Ubuntu is no different, except that the community supports ‘universe’. The Universe packages are not actively maintained by the Ubuntu Security Team, and security fixes for those packages are community provided (with some exceptions, such as the nginx package which almost exclusively I provide patches for to the Ubuntu Security Team). While you are not guaranteed any updates for these packages, a lot of the popular ones will have enough attention to usually have someone working to try and patch security issues.

There’s a difference in who packages what. In Ubuntu, you’ll have:

  • Core components (main, restricted), including GNOME: packaged by Ubuntu Developers
  • Non-core components (universe, multiverse), including KDE, XFCE, Cinnamon, MATE: packaged by Ubuntu MOTU Developers

Now you know why. But the retards did package thunar 4.16.8-1 for the upcoming 21.10, so they could (and should!) have built it for 21.04 too, as it’s the same 4.16 branch as the one in 21.04, and this is a security update!

The irony? Ubuntu was created in 2004 to bring the Linux Desktop to everyone, with freely shipped CDs for some time, but nowadays only Ubuntu Server can be trusted from a security standpoint!

Unless you’re retard enough to use the main Ubuntu that uses GNOME, not Kubuntu, Xubuntu or other flavors and derivatives.

No, this isn’t only about Ubuntu!

Now don’t get relieved if you’re using some other distro: unless you’re using a rolling-release one, you might find out that your Thunar is vulnerable too, and who knows how many other packages have unpatched vulnerabilities for which patches exist?

First of all, CVE-2021-32563 is easy to test. Just take a sceenshot, save it on the Desktop, e.g. as img.png, then open a terminal on the Desktop, and invoke thunar img.png:

  • If Thunar is vulnerable, it will open the image in the default image viewer, no question asked.
  • If Thunar has been patched, it will open the Desktop folder instead, because that’s where the image is.

What we know so far is that the latest stable branch of XFCE, 4.16, includes the patch in Thunar 4.16.8 (the CVE says the vulnerability exists “before 4.16.7,” i.e. “not including 4.16.7,” but the actual patch came with 4.16.8), and that the development branch 4.17 has patched it in 4.17.3 (again, 4.17.2 should have been safe according to the CVE, but the dev branch has 4.17.3, in which it’s been fixed). How about the Thunar versions included in Debian Buster, Ubuntu LTS, and other still supported distros that have XFCE 4.12 or 4.14? Are they vulnerable, or not?

Here are the facts:

Debian Buster 10.9 XFCE + latest updates: XFCE 4.12.4, Thunar 1.8.4, the image is automatically opened in Ristretto. VULNERABLE!

MX Linux 19.4.1 + latest updates: XFCE 4.14.2 (built by MX), Thunar 1.8.14 (built by MX), the image is automatically opened in Nomacs. VULNERABLE! UPDATE: FIXED in Thunar 1.8.17 on June 5.

Linux Mint 20.1 XFCE + latest updates: XFCE 4.14.2, Thunar 1.8.14, the image is automatically opened in Xviewer. VULNERABLE!

Linux Lite 5.4 + latest updates: XFCE 4.14.2, Thunar 1.8.14, the image is automatically opened in Shotwell. VULNERABLE!

Xubuntu 20.04 LTS + latest updates: XFCE 4.14.2, Thunar 1.8.14, the image is automatically opened in Ristretto. VULNERABLE!

To test with a recent distro, I used Fedora 34 XFCE Spin: the ISO included Thunar 4.16.5, which opened the image in Ristretto, being thus vulnerable; after the update to Thunar 4.16.8, it only opened the Desktop folder instead, as needed to fix the vulnerability.

So yes: the older versions of Thunar from XFCE 4.12 and 4.14, namely 1.8.4 and 1.8.14, are vulnerable too, and the security patch should have been backported to them, but no major distro bothered to do so!

I didn’t check Thunar 1.8.15 built in EPEL on 2020-05-29 for RHEL 8, CentOS 8, Rocky Linux 8, AlmaLinux OS 8, VzLinux 8, Oracle Linux 8, but from the Changelog and the News file, its bug fixes DO NOT include any backport related to CVE-2021-32563. Red Hat only supports RHEL though, which doesn’t offer XFCE, so we can only blame the EPEL maintainer of this package.

What Is to Be Done?

In lieu of some conclusions:

  • If you’re using a Linux distro professionally, specifically as a headless server, or in containers, you should probably be safe with any major distro during its supported lifetime, including Debian and Ubuntu.
  • When a desktop environment is used, in RHEL and clones you should trust the retarded GNOME and GNOME only, and the same is true for Ubuntu. Other desktop environments are second-class citizens!
  • Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, and Xubuntu shouldn’t be used professionally. Their desktop environments are in universe and, as you can see from Thunar’s case, they might not get security fixes.
  • There might be an exception with Ubuntu MATE, though: the “representative” distro for MATE is nowadays Ubuntu MATE (not Linux Mint!), and MATE’s developers can be found on Ubuntu MATE’s forums. Their involvement might be more resolute, and the occasional security issues found in a desktop with a slow-paced evolution, promptly fixed. I don’t say this as a sign of trust in Martin Wimpress, quite the contrary: Wimpy and his minions are dictatorial, and they have betrayed MATE’s spirit by forcing snaps into Ubuntu MATE, and silencing any other opinions. Also, I didn’t check for past vulnerabilities in MATE, so I don’t know whether 20.04 LTS still being at MATE 1.24.0 is fine (21.04 has MATE 1.24.1).
  • In Linux Mint too there might be an exception: Cinnamon being their creation, its vulnerabilities should be closed in Mint faster than anywhere else! Avoid the other flavors in mission-critical environments.
  • For Debian’s security when used with a desktop environment, or even generally, I’m more than skeptical. In the first five months of 2021, Debian had only 102 security advisories, which can’t possibly match all the CVEs affecting Debian’s packages. Debian actually admits that Buster’s Thunar is vulnerable! Their bug #988394 declares the severity “grave” (upstream it was “important”), but the fix only reached sid and testing, once the upstream has released a new version! Definitely, Debian is not a recommendation. Even for a headless server, Ubuntu Server should be a better choice.
  • Fedora (Server/Workstation) is probably safe enough security-wise, but being a testbed for the latest technologies, it shouldn’t be used professionally, i.e. in mission-critical environments. For such cases, better use Fedora CoreOS (containers) or Fedora Silverblue (is anyone really using this thing for a workstation?). For personal usage scenarios, Fedora Spins should be “good enough” for the brave; the Fedora Labs bundles too.
  • Rolling-release distros have the potential to be patched the quickest, but I’m not sure such a distro (Arch, Manjaro, Debian testing/unstable, Fedora Rawhide, openSUSE Tumbleweed, CentOS Stream, etc.) should be used in mission-critical environments. Most definitely not! (I’m not talking of things such as openSUSE MicroOS.)

From a practical standpoint, most of those who use Linux on their laptop or desktop, at their small company, or at school, won’t get impressed by such unfixed vulnerabilities. So … why did I write this blog post?!

There is no purpose in anything

I don’t know, maybe because I’m an idiot who cares about quality in software, despite such a thing being non-existent for many years.

These days, nobody cares about writing good software. Changes for the sake of changes, regressions galore, random bug fixes and security patches:

In 2007, I was mocked for a feature like this one. For the entire period when this blog was Planète Béranger (read more about its history), I have been more unpopular than popular. Think of Dedoimedo today: is he appreciated for the bugs and design flaws he finds in various distros? Quite the contrary: he receives this kind of bashing on Reddit and in other places.

Do you think Linux Lite would be interested in knowing they have a vulnerable package they can’t do anything about, when they treated me this way? No, bug reports from outside their target group are not welcome. And one of their idiots quickly diagnosed me like this: «He suffers from a “craving to be famous” and “a horror of being known to like being known”.» Go figure.

If someone craves to be famous, it’s the bunch of retards who talk nonsense on YouTube, who don’t know how to review anything, but somehow still manage to make enough people watch their crap. Every single narcissist can have their personal TV channel on YouTube. And they do. And they monetize it. At the other end of the spectrum, this blog never had any kind of monetization, not even in its heydays (roughly 2005-2009).

A valid point would be to say: stop criticizing, DO something constructive instead! OK, but what, exactly? Could I do the job of hundreds of package maintainers in dozens of distros? Certainly not! Should I pester them with my opinions that they should apply a certain patch, that they should test the package, then push it in production? Even less, as I cannot patronize them, and I can’t make them do what they don’t want to do.

Frankly, there is no logic nor common sense in software development and in Linux distros, as one can see, most recently, in the conflictual communication I had on the forums of Ubuntu MATE and Linux Lite. It’s been this way for many years. It wasn’t logical to have license wars that led to XFree86 being abandoned in favor of XOrg (a more recent case concerns OpenOffice.org). It wasn’t logical to discontinue proven technologies only to replace them with half-baked ones, for the sake of novelty. It wasn’t smart to drop features in GNOME3 and Nautilus. Actually, it’s hard to find bigger idiocies than GNOME3, Compiz, Mir, Wayland, KDE Plasma 4, GRUB2, and dozens of other crappy pieces of software. People now complain of systemd, which is relatively decent, while loving technologies that are much, much worse. But this is how things are, and I cannot respect the people who took such decisions.

I should pay more respect to the package maintainers though, being them lazy or not, busy or less busy. After all, I have had such experiences myself when I created and maintained for a while two repositories: Odiecolon.repo for EL5 (until Aug. 26, 2009; it last included 489 RPMs and 269 SRPMs for clones of RHEL5); and Unofficial Mageia Cauldron/2 Repository (until Sept. 20, 2011; it last included 45 SRPMs and 100 RPMs). They were tiny personal projects from the times when not everyone had projects on GitLab, and they never had more than 12-14 users, by my estimate.

But how can people pretend they maintain one of the major desktop environments if they can’t be bothered to patch its file manager? How can they pretend they love that desktop environment?! Xubuntu 21.04 and Fedora 34 XFCE Spin were both released end-April; only the second one patched Thunar!

Maybe it’s time to rediscover Fedora and the RPM-land, after all these years of looking elsewhere. Despite Fedora being Red Hat, despite Red Hat being GNOME3 (now GNOME4), despite Red Hat having killed CentOS, and despite Red Hat being IBM. (People like Gordon Squash even believe Red Hat will have brought the total demise of GTK and GNOME by 2030.)

Fedora 34 XFCE can easily be themed to look decent (it comes with xfce4-panel-profiles, something Arch only has in AUR or prebuilt in Chaotic-AUR, and Debian totally lacks), and I don’t have to fear Wayland as long as I don’t use NVidia (even if I did, it looks like akmod-nvidia and xorg-x11-drv-nvidia-cuda from RPM Fusion provide a quick fix, as opposed to this monstrosity). Of course, DNF Dragora is even slower than YumEx was, but you can’t fight progress, can you?

And I missed the way they shoot themselves in the foot:

But I am secure and protected, ain’t I?

Over and out for now, you nincompoops.

Special note regarding openSUSE

Learning that openSUSE 15.3 has just been released, I was struck by this part of the announcement:

There is one huge change from the previous Leap versions. openSUSE Leap 15.3 is built not just from SUSE Linux Enterprise source code like in previous versions, but built with the exact same binary packages, which strengthens the flow between Leap and SLE like a yin yang.

“The software craftsmanship of this release makes server, workstation, desktop and container use on openSUSE Leap a desirable distribution for IT professionals, entrepreneurs, hobbyists, small businesses and educational practitioners,” said release manager Lubos Kocman.

I instantly thought, wow, whereas Red Hat broke the trust connection with the community by not allowing CentOS anymore to be a clone of RHEL, SUSE might have just done the opposite by allowing SLE packages to enter openSUSE Leap directly! Shouldn’t this be great news? (I never trust anything coming from a corporation that says it’s good for you; it’s always good for them, in 110% of cases.)

The last time I used openSUSE was not long after this screenshot taken on April 14, 2009:

Much more recently, I tried some rolling builds of GeckoLinux: my feelings were mixed, but without installing them, I couldn’t form an opinion. At the same time, I noticed that Dedoimedo’s last three experiences with openSUSE Leap 15, 15.1 and 15.2 weren’t stellar, so I kept staying away of it.

Under the current circumstances though, I thought of downloading openSUSE-Leap-15.3-XFCE-Live-x86_64-Media.iso:

Out of the box, Thunar 4.16.3, which is vulnerable, and there isn’t any update candidate!

While I was living in a different universe than SUSE, I missed a change that I still don’t understand after having read the official pages regarding Package repositories and Additional package repositories: why should anyone add a 3rd-party repository hosted by openSUSE and having the name X11:xfce to get XFCE updates? What kind of update model is this? No other distro has it!

You will find this:

http://download.opensuse.org/distribution/leap/15.3/repo/oss/x86_64/
thunar-4.16.3-bp153.1.11.x86_64.rpm 06-Mar-2021 09:24 495K
http://download.opensuse.org/repositories/X11%3A/xfce/openSUSE_Leap_15.3/x86_64/
thunar-4.16.8-lp153.173.1.x86_64.rpm 18-May-2021 08:35 454K

Oh, they didn’t have the time to test the newer Thunar. Fucking corporate slowness. And the builder of 4.16.8 only mentioned some bug fixes, but not the CVE-2021-32563! Unbelievable. People were much more professional a decade ago, when I was more into Linux than today!

OK, so the users of openSUSE Leaf should add an extra repo to get XFCE updates that include security fixes! But according to SUSE, such a repo has packages that “are not supported by openSUSE, meaning they may not be tested,” for which reason “it is recommended to use the four default repositories: OSS, Non-OSS, Update and Update-Non-OSS.” Which include unpatched, vulnerable packages!

It’s beyond my comprehension. A company that builds so many professional products, a company with such a huge infrastructure that builds and hosts tons of third-party software (OBS has been open to the masses for more than a decade), is a company that simply cannot update the packages after they’re released?!

Vulnerable be vulnerable

It was clear though:

Release notes for 1.8.17
========================
Bugfix and translation release on the thunar 4.14 branch:

- Dont execute files passed via command line due to security risks
(That fixes CVE-2021-32563 as well for this old branch. A similar fix
was already released for 4.16 branch and master)
- Fix combo box entry order (Issue #435)

They should stop pretending they support a distro if they cannot update a package in three weeks, if at all.

Late updates

Also, idiots be idiots

Whoever is so idiot as not to understand that are two entirely different issues at hand, I’ll reiterate them explicitly:

  1. In a LTS distro (Debian stable, Ubuntu LTS, EPEL for RHEL, etc.), backporting a security patch can take some time, especially if the upstream doesn’t do it, so the distro maintainers have to investigate how to do it. Here, we’re talking of backporting a patch from a package that’s part of XFCE 4.16 to the corresponding packages that are part of XFCE 4.14. In our case, Thunar 4.16.8 was released on May 7, and the backport as Thunar 1.8.17 (for 4.14) was released on May 13, after an acceptable delay.
  2. In a normal distro in its latest version, such as Fedora 34 and Xubuntu 21.04, both released end-April, both featuring XFCE 4.16, there should be no question as to “why” a newer package belonging to the same XFCE 4.16 should be integrated in the distro! Fedora did update Thunar from 4.16.5 to 4.16.8, Xubuntu did not, still having 4.16.6 almost a month after the release of 4.16.8. Why?! (OpenSUSE Leap 15.3 considers the update repo as “3rd-party” and discourages the beginners from using it, which is a different thing of irresponsible idiocy.)

Here’s a Twitter update from Sean Davis, which is the Xubuntu Technical Lead, and an Xfce Core Developer:

OK, Launchpad is there for that, but at the same time, what are the Xubuntu maintainers there for, if not for maintaining Xubuntu-specific packages, which should start with the very XFCE?

Because there’s another problem with Xubuntu: the update process!

As I already said, updating from 4.16.x to 4.16.y shouldn’t raise the question “why”!

One more reason not to touch anything Ubuntu (except for the server, possibly) not even with a 10-ft pole. They hate you when you tell them that they didn’t do what they were supposed to do. This is how things work in the IT: sometimes, people who actually do what they said they’ll be doing are fired, whereas too many people who don’t are kept in place and cannot be touched not even with a flower (they’re Gods that can’t be questioned).

OK, they don’t always hate you, but they keep failing to understand:

Over and out… to Fedora 34 XFCE!