Table of Contents

• 1) Introduction
• 2) Overview of Screen Configurations and Versions
  • About the Screen Multi-User Mode
• 3) Security Issues
  • 3.a) Local Root Exploit via logfile_reopen() (CVE-2025-23395)
  • 3.b) TTY Hijacking while Attaching to a Multi-User Session (CVE-2025-46802)
  • 3.c) Screen by Default Creates World Writable PTYs (CVE-2025-46803)
  • 3.d) File Existence Tests via Socket Lookup Error Messages (CVE-2025-46804)
  • 3.e) Race Conditions when Sending Signals (CVE-2025-46805)
  • 3.f) Bad strncpy() Use Leads to Crashes when Sending Commands
• 4) Possible Further Issues in Screen’s setuid-root Implementation
• 5) General Recommendations
• 6) Problematic Coordinated Disclosure Process and Upstream Status
• 7) Affectedness Matrix
• 8) Timeline
• 9) References

1) Introduction

In July 2024, the upstream Screen maintainer asked us if we could have a look at the current Screen code base. We treated this request with lower priority, since we already had a cursory look at Screen a few years earlier, without finding any problems. When we actually found time to look into it again, we were surprised to find a local root exploit in the Screen 5.0.0 major version update affecting distributions that ship it as setuid-root (Arch Linux and NetBSD). We also found a number of additional, less severe issues that partly also affect older Screen versions still found in the majority of distributions.

We offer two sets of patches for the issues described in this report, one for screen-4.9.1 and another for screen-5.0.0. These patch sets apply against the screen-4.9.1 and screen-5.0.0 release tarballs, respectively. Due to difficulties in the communication with upstream we do not currently have detailed information about bugfixes and releases published on their end.

The next section provides an overview of the Screen configurations and versions found on common Linux and UNIX distributions. Section 3) discusses each security issue we discovered in detail. Section 4) takes a look at possible further issues in Screen’s setuid-root implementation. Section 5) gives general recommendations for the improvement of Screen’s security posture. Section 6) points out problems we encountered during the coordinated disclosure process for these issues. Section 7) provides an affectedness matrix which gives a quick overview of the situation on various Linux and UNIX systems.

2) Overview of Screen Configurations and Versions

In August 2024 a version 5.0.0 major release of Screen was published by upstream. By now Arch Linux, Fedora 42 and NetBSD 10.1 ship this new version of Screen. A lot of refactoring changes made their way into this Screen release that are in some cases dating back more than ten years. Some of the issues discussed in this report have only been introduced in the 5.0.0 release of Screen, while others also affect Screen 4.9.1 (and older), which is still the version found in the majority of Linux and UNIX distributions at the time of writing.

Any source code references in this report are based on the upstream 5.0.0 release tag, unless noted otherwise. Affectedness information is provided for both the current 5.0.0 release and the more widespread 4.9.1 Screen release for each vulnerability discussed below.

NOTE: At the time of writing we often experienced HTTP 502 “Bad Gateway” errors trying to access Screen’s Git web front end. Retrying a few seconds later usually resolved the error.

About the Screen Multi-User Mode

Screen offers a multi-user mode which allows to attach to Screen sessions owned by other users in the system (given the proper credentials). These multi-user features are only available when Screen is installed with the setuid-root bit set. This configuration of Screen results in highly increased attack surface, because of the complex Screen code that runs with root privileges in this case.

A Screen multi-user session is identified by its name, which needs to have a <user>/ prefix. The following command line would create such a session:

user1$ screen -S user1/my-multi-user-session

To manage access to a multi-user session, Screen maintains access control lists (acls) that can be configured in Screen’s configuration file (~/.screenrc), or by sending commands to a running Screen session (see screen(1) man page). These acls are based on the account names of other users and can optionally be protected by a password. Access can be restricted to “read-only”, a mode in which no input can be passed to the terminal.

Of the systems we looked into, only Arch Linux, FreeBSD and NetBSD install Screen with the setuid-root bit set. On Gentoo Linux the setuid-root bit is optionally assigned if the “multiuser” USE flag is set. Some distributions install Screen with a setgid bit assigned to let it run with specific group credentials. This is the case on Gentoo Linux by default, which installs Screen as setgid-utmp, allowing Screen to create login records in the system-wide utmp database. Fedora Linux installs Screen as setgid-screen, which allows Screen to place sockets into a system-wide directory in /run/screen.

3) Security Issues

3.a) Local Root Exploit via logfile_reopen() (CVE-2025-23395)

This issue affects Screen 5.0.0 when it runs with setuid-root privileges. The function logfile_reopen() does not drop privileges while operating on a user supplied path. This allows unprivileged users to create files in arbitrary locations with root ownership, the invoking user’s (real) group ownership and file mode 0644. All data written to the Screen PTY will be logged into this file. Also already existing files can be abused for logging in this manner: the data will be appended to the file in question, but the file mode and ownership will be left unchanged.

Screen correctly drops privileges when it initially opens the logfile. The privilege escalation becomes possible as soon as Screen believes it is necessary to reopen the logfile. Screen checks this by calling stolen_logfile() before writing to the file. The call to logfile_reopen() happens when the link count of the originally opened logfile drops to zero, or if it unexpectedly changes in size. This condition can be triggered at will on the end of the unprivileged user.

This is a reproducer which shows how to achieve a basic local root exploit on an affected system:

# create a Screen session using a custom logfile path
(shell1) user$ screen -Logfile $HOME/screen.log
# enter the key combination to enable logging to the configured path
(screen) user$ <ctrl-a> H

# in another shell remove the logfile that Screen just created and
# replace it by a symlink to a privileged location
(shell2) user$ rm $HOME/screen.log; ln -s /etc/profile.d/exploit.sh \
    $HOME/screen.log

# back in the Screen session, echo an exploit command which will be logged to
# the now redirected logfile.
#
# This needs to be done via `echo` for adding a leading newline to prevent the
# bash prompt from breaking the exploit. Similarly the trailing semicolon
# is necessary to prevent following control characters from becoming part of
# the shell command.
(screen) user$ echo -e "\nchown $USER /root;"

# now perform a new login as root and watch the exploit being executed.
# you will likely see a range of shell errors during login as well.
root# ls -lhd /root
drwxr-x--- 5 user root 4.0K Dec 30  2020 .

This is just one naive approach to achieve a local root exploit, which is not very well hidden (because of strange error messages) and requires the actual root user to login to trigger it. There are likely many other ways to exploit this, however, for example by writing new configuration files for tools like sudo, or by appending code to privileged shell scripts found in /usr/bin and similar locations.

Bugfix

The problem was introduced via an old commit 441bca708bd, which has only now become part of the 5.0.0 release. In this commit the lf_secreopen() function was removed, which was considered unneeded.

Patch 0001 in screen-5.0.0-patches.tar.gz addresses the issue by reintroducing the secure file handling during logfile reopen.

Affected Distributions

Arch Linux

Arch Linux is fully affected by this issue, since it ships the version 5.0.0 release and assigns the setuid-root bit. Screen is not installed by default on Arch, however.

Fedora Linux

The affected 5.0.0 version is only found in the recently released Fedora 42. Screen runs with setgid-screen credentials there, to be able to write in the /run/screen directory. A private directory with mode 0700 is created in there for each user that runs a Screen multi-user session. Due to this, the exploit will not allow to write in other users’ session directories, it will only be possible to create files directly in /run/screen. The only attack vector we can imagine here is to cause a local DoS scenario by claiming the names of other users’ session directories, should they not yet exist. Another attack vector could be to try and fill up the free disk space of the /run file system (a TMPFS) to break other system services.

Gentoo Linux

Gentoo Linux is not affected in its stable Screen ebuild, which is still based on Screen version 4.9.1.

When using Gentoo’s unstable ‘app-misc/screen-9999’ ebuild, then the affected version 5.0.0 will be installed, however. If the “multiuser” USE flag is also set, then the setuid-root bit will be applied, resulting in a fully vulnerable Screen.

Without this USE flag, Screen runs as setgid-utmp on Gentoo Linux, which allows to use this exploit to overwrite the /var/log/wtmp database. This makes it possible to violate the integrity of the database or even to craft login entries which could adversely influence other privileged programs in the system that rely on this information.

FreeBSD

FreeBSD still uses version 4.9.1. If Screen were to be upgraded to 5.0.0 then FreeBSD would be affected as well, since Screen is installed as setuid-root by default.

NetBSD

On NetBSD the affected Screen 5.0.0 version can be installed and it will by default run with setuid-root privileges. This makes it fully affected by the issue.

3.b) TTY Hijacking while Attaching to a Multi-User Session (CVE-2025-46802)

This issue is found in the Attach() function when the multiattach flag is set (i.e. Screen attempts to attach to a multi-user session). The function performs a chmod() of the current TTY to mode 0666. The path to the current TTY is stored in the attach_tty string:

if ((how == MSG_ATTACH || how == MSG_CONT) && multiattach) {
    /* snip */
    if (chmod(attach_tty, 0666))
        Panic(errno, "chmod %s", attach_tty);
    tty_oldmode = tty_mode;
}

Fortunately the TTY path which is calculated within Screen is sufficiently probed for correctness. In particular, isatty() needs to be true for FD 0 (which is used for determining the TTY path) and the resulting path needs to reside in /dev. Otherwise this chmod() would have led to another local root exploit.

The original TTY mode is restored towards the end of the function in line 284. We are not completely sure about the purpose of this temporary permission change, maybe it is supposed to allow the Screen daemon of the target session (which might have different credentials) to access the client’s TTY for the purposes of the attach procedure.

The issue with this temporary TTY mode change is that it introduces a race condition allowing any other user in the system to open the caller’s TTY for reading and writing for a short period of time. We made some simple tests based on Linux’s inotify API, and we managed to open affected TTYs every second or third attempt using a simple Python script this way.

The impact of this issue is that an attacker can intercept data typed into the TTY and also inject data into it. An attacker could attempt to mislead the owner of the TTY into entering a password, or gain other sensitive information. Also, control sequences can be injected into the affected TTY which adds further possibilities to confuse the victim or to exploit issues in an involved terminal emulator.

There also exist return paths in the Attach() function where the original mode is never restored again. This happens in line 160, for instance, where the process explicitly exits if the target session is not found and the “quiet” command line argument has been set. A simple reproducer of this aspect is as follows:

    # inspect the current TTY permissions, which are safe
    user$ ls -l `tty`
    crw--w---- 1 user tty 136, 1 Feb  5 12:18 /dev/pts/1
    # attempt to attach to some non-existing session of the root user.
    # note that this only works if the target user's session directory (e.g.
    # in $HOME/.screen) already exists, otherwise the logic terminates early
    # and the `chmod()` does not happen.
    user$ screen -r -S root/some-session -q
    # observe the now unsafe TTY permissions
    user$ ls -l `tty`
    crw-rw-rw- 1 user tty 136, 1 Feb  5 12:19 /dev/pts/1

The Panic() function, which is mostly used in Attach() to stop process execution, correctly restores the old TTY mode. Only code paths that use return or eexit() suffer from this missing TTY mode restore.

Bugfix

We assume that the problematic chmod() calls are most likely only remnants of past times, when this insecure approach was used to grant the target Screen session access to the new client’s PTY. These days Screen passes the PTY file descriptor securely via the UNIX domain socket to the target session.

Thus to fix this, the temporary chmod() to mode 666 can be dropped. This is what is done in patch 0001 in screen-4.9.1.tar.gz and patch 0004 in screen-5.0.0.tar.gz.

Shortly before the publication of this report it was pointed out to us that this patch likely breaks some reattach use cases in Screen. We can confirm this problem, but at the same time found out that this specific use case was obviously already broken before, even in Screen 4.9.1. For this reason we decided not to move the publication date again or to adjust this patch in a hurry with uncertain results. The patch still fixes the security issue and upstream can now fix this regression, that already seems to have existed earlier, in the open.

Affected Distributions

Unlike the previous issue, this one is not limited to the current 5.0.0 release. The observed behaviour has been present in Screen versions since at least the year 2005. All Linux distributions and BSDs we checked suffer from this, if they provide multi-user support in Screen by installing it setuid-root.

This issue theoretically also affects Screen if it is not installed setuid-root, because the caller always has permission to modify the mode of its own TTY. Screen refuses to continue the operation, however, if the target session is not owned by the caller and no root privileges are available. The problematic code still triggers when a user attempts for some reason to join a multi-user session owned by itself. An example invocation that leads to this would be screen -r -S $USER/some-session -q. Systems that are affected by this lighter variant of the issue are marked as partly affected in section 7).

3.c) Screen by Default Creates World Writable PTYs (CVE-2025-46803)

In Screen version 5.0.0 the default mode of pseudo terminals (PTYs) allocated by Screen was changed from 0620 to 0622, thereby allowing anyone to write to any Screen PTYs in the system. Security-wise this results in some of the issues that have been outlined in issue 3.b), without the information leak aspects, however.

The history of the default PTY mode in Screen is rather complex. Let’s have a look at the situation in version 4.9.1 (and a lot of older versions):

• There is a 0622 default mode in the code in process.c line 207. This is only a fallback that should not become active unless the code is compiled in unusual ways.
• A default mode of 0620 is applied in configure.ac line 811, which results in a safe default when compiling Screen using autotools.

• In acconfig.h line 81 the following is stated:

  define PTYMODE if you do not like the default of 0622, which allows public write to your pty.

  Thus in this version there is an inconsistency between the default mode on autoconf level and the default on source code level, but in the end the (safe) autoconf default wins.

Now let’s look at the situation in Screen version 5.0.0:

• The configure.ac file was rewritten from scratch in commit df1c012227. This change drops the 0620 default mode on autoconf level.
• In a follow-up commit 78a961188f7 the pty-mode configure switch was reintroduced, this time with default mode 0622.
• Thus in version 5.0.0 there is no longer a mismatch between the source code level default and the autoconf level default, but the default is now unsafe.

Bugfix

We couldn’t find any Screen release notes for version 5.0.0, except for a few ChangeLog entries. It seems it was not a deliberate decision to change the default PTY Mode to 0622.

Patch 0002 in screen-5.0.0-patches.tar.gz addresses the issue by restoring the safe default PTY mode in the configure.ac script. Note that you will need to run autoreconf to make the change effective.

We recommend to packagers to actively pass the configure switch --with-pty-mode=0620 to make this choice explicit, also on older releases of Screen.

Affected Distributions

Gentoo Linux and Fedora Linux pass an explicit safe --with-pty-mode to Screen’s configure script. For distributions other than the ones listed as affected below, we did not check if they are either doing the same, or if they are relying on the safe default present in older Screen releases.

Arch Linux

On Arch Linux the package build does not pass the --with-pty-mode switch, resulting in the new default being applied, thus making Screen on current Arch Linux vulnerable to this issue.

NetBSD

NetBSD is affected by this issue the same way as Arch Linux is.

3.d) File Existence Tests via Socket Lookup Error Messages (CVE-2025-46804)

This is a minor information leak when running Screen with setuid-root privileges that is found in older Screen versions, as well as in version 5.0.0. The code in screen.c starting at line 849 inspects the resulting SocketPath with root privileges, and provides error messages that allow unprivileged users to deduce information about the path that would otherwise not be available.

An easy way to achieve this is by using the SCREENDIR environment variable. Following is an example that works on current Arch Linux:

# this can be used to test whether /root/.lesshst exists and is a regular file
user$ SCREENDIR=/root/.lesshst screen
/root/.lesshst is not a directory.

# this allows to deduce that the directory /root/.cache exists
user$ SCREENDIR=/root/.cache screen
bind (/root/.cache/1426.pts-0.mgarch): Permission denied

# this tells us that the path /root/test does not exist
user $ SCREENDIR=/root/test screen
Cannot access /root/test: No such file or directory

Bugfix

Patch 0002 in screen-4.9.1.tar.gz and patch 0005 in screen-5.0.0.tar.gz address the problem by only outputting generic error messages when Screen is installed setuid-root and when the target path is not controlled by the real UID of the process.

Affected Distributions

All distributions we considered are affected.

3.e) Race Conditions when Sending Signals (CVE-2025-46805)

In socket.c lines 646 and 882 time-of-check/time-of-use (TOCTOU) race conditions exist with regards to sending signals to user supplied PIDs in setuid-root context.

The CheckPid() function drops privileges to the real user ID and tests whether the kernel allows to send a signal to the target PID using these credentials. The actual signal is sent later via Kill(), potentially using full root privileges. By this time, the PID that was previously checked could have been replaced by a different, privileged process. It might also be possible to trick the (privileged) Screen daemon process into sending signals to itself, since a process is always allowed to send signals to itself.

Currently this should only allow to send SIGCONT and SIGHUP signals, thus the impact is likely only in the area of a local denial of service or a minor integrity violation.

The issue affects both Screen version 5.0.0 and older version 4 releases, when Screen is installed setuid-root. This issue results from an incomplete fix for CVE-2023-24626: before this incomplete fix, the signals in question could be sent to arbitrary processes even without winning a race condition.

Bugfix

Patch 0003 in screen-4.9.1.tar.gz and patch 0006 in screen-5.0.0.tar.gz address the problem by sending the actual signal with real UID privileges, just like CheckPid() does.

Affected Distributions

All distributions we considered are affected.

3.f) Bad strncpy() Use Leads to Crashes when Sending Commands

We believe this is a non-security issue, but one that still should be fixed with priority. The issue is only found in Screen version 5.0.0.

In commit 0dc67256 a number of strcpy() calls have been replaced by strncpy(). The author obviously was not aware of the unfortunate semantics that strncpy() has. This function is not intended for safe string handling, but to maintain zero padded buffers of fixed length. For this reason, strncpy() does not stop writing data to the destination buffer when the first \0 byte is encountered, but it writes out zeroes until the buffer is completely filled.

Apart from leading to bad performance, this also triggers a bug in attacher.c line 465. The following change has been applied there:

-      strcpy(p, *av);
+      strncpy(p, *av, MAXPATHLEN);
       p += len;

These lines are part of the following for loop, which processes command line parameters to send them to a running Screen session.

for (; *av && n < MAXARGS - 1; ++av, ++n) {
        size_t len;
        len = strlen(*av) + 1;
        if (p + len >= m.m.command.cmd + ARRAY_SIZE(m.m.command.cmd) - 1)
                break;
        strncpy(p, *av, MAXPATHLEN);
        p += len;
}

The call to strncpy() always passes MAXPATHLEN bytes as destination buffer size. This is correct for the first iteration of the for loop, when p points to the beginning of the struct Message.command.cmd buffer declared in screen.h line 148. It is no longer correct for following iterations of the for loop, however, when p is incremented by len. This means future strncpy() calls will write an excess amount of \0 bytes beyond the end of the buffer.

The result of this can be observed on current Arch Linux when passing more than one command argument to a running Screen instance:

# create a new screen session
user$ screen -S myinstance

# and detach from it again
(screen) user$ <Ctrl A> d

# now try to send a command to the running session
user$ screen -S myinstance -X blankerprg /home/$USER/blanker
*** buffer overflow detected ***: terminated
Aborted (core dumped)

The two command arguments lead to two iterations in the for loop described above; the second iteration will trigger the buffer overflow detection. The visible error only occurs when Screen is compiled with the _FORTIFY_SOURCE feature enabled. Otherwise no errors are seen, not even when compiling with -fsanitize=address, likely because after the end of the target buffer another long buffer char message[MAXPATHLEN * 2] follows (thus only application payload data is overwritten).

This issue allows the caller to overwrite MAXPATHLEN bytes of memory following the cmd buffer with zeroes, which can cause integrity violation in Screen, particularly when it runs setuid-root. Since an equally sized buffer writeback[MAXPATHLEN] follows in memory, there should be no possibilities to exploit this issue to the advantage of an attacker, however.

To fix this, MAXPATHLEN needs to be replaced by the actually remaining amount of bytes in p. Furthermore ideally all strncpy() calls should be replaced by snprintf(target, target_size, "%s", source) to avoid the unintended effect of zero padding the target buffer.

We wondered how this issue could be present in Screen 5.0.0 for such a long time without anybody noticing. One part of the explanation likely is that Screen version 5.0.0 is only present in few distributions so far. Another aspect is that perhaps only few users are using this feature to send commands to running Screen sessions. We still found a report from not too long ago on the screen-users mailing list that seems to refer to exactly this issue.

Bugfix

Patch 0003 in screen-5.0.0.tar.gz addresses this problem by changing strncpy() to snprintf() and by properly passing the amount of remaining space in the target buffer.

Affected Distributions

All distributions shipping screen-5.0.0 are affected.

4) Possible Further Issues in Screen’s setuid-root Implementation

While working on the bugfix for issue 3.e), we also noticed that the original (incomplete) bugfix for CVE-2023-24626 introduced a regression to the multi-user mode in Screen when the target session is running as non-root. In this case the target session drops privileges to some UID X and then attempts to send a signal to some UID Y (of the client), which will always fail.

This shows that there are actually three different UIDs to be considered in Screen’s multi-user mode: effective UID 0 to perform privileged operations, the real UID of the user creating the session and the real UID of the user attaching to a session. We don’t believe that the current Screen code takes this properly into account.

This also brought to our attention that Screen multi-user sessions created by root will “drop privileges” to the real UID of the creating user, which will be UID 0, and thus effectively perform no privilege drop at all.

5) General Recommendations

From the changes in Screen 5.0.0 we can see that there have been attempts for a longer time to refactor the code base, which was still written in K&R style C before that. During this refactoring some of the long established security logic has been broken, however, which led to issues 3.a) and 3.c). Before doing further refactoring, some kind of test suite could be helpful to verify various security properties of the implementation. Also anybody who works on this code base obviously should have knowledge about the many dangers that linger in setuid-root binaries.

Even after fixing the issues we identified during our review, there are still many areas left that make us worry as outlined in the previous section. There is also a range of file system operations where security is hanging by a thread.

There is furthermore a broad design issue in Screen: it runs with elevated privileges all the time, and only selectively drops privileges for operations that are considered dangerous. For a robust setuid-root program this should be the other way around: privileges should be dropped by default and only raised for operations that actually require elevated privileges.

To make Screen acceptable for running setuid-root we suggest to implement a design change in this regard and to carefully review each privileged operation that remains for its security. We also suggest to add logic to remove any environment variables except those that are explicitly allowed in the setuid-root context. Other environment variables like PATH should be sanitized to point only to trusted system directories.

Given all this, we don’t recommend to install Screen setuid-root at all at the moment (neither version 5.0.0 nor the older 4.9 versions). An alternative could be to offer the multi-user feature only in an opt-in fashion, e.g. by allowing only members of a trusted group to run a multi-user version of Screen.

6) Problematic Coordinated Disclosure Process and Upstream Status

When we reported these issues to upstream in February 2025, we offered the usual coordinated disclosure process based on our policy. Upstream expressed a lot of interest in keeping the issues private to develop bugfixes before publication. A time frame of one to two months was communicated to us for this purpose. We were not too happy with this long embargo period, but we understand that many upstreams are lacking resources, thus we agreed to these terms.

About a month later some activity ensued on upstream’s end and discussions about bugfixes started. These discussions were not too fruitful, but we still believed that upstream would be able to deal with the issues - given it was upstream itself that asked us to perform a security review for Screen.

No further communication happened, however, until about two weeks before the maximum 90 days embargo period we offer, when we inquired upstream about the current status and pointed out the publication date coming close. We had to find out that upstream did not use the long time period up to this point to work on the bugfixes. Meanwhile further distributions like NetBSD updated to Screen 5.0.0, becoming fully affected by issue 3.a), unaware of the risk.

It was only at this point that we realized that upstream was not sufficiently familiar with the Screen code base, not capable of fully understanding the security issues we reported and that they did not clearly state that they need more help than us only reviewing patches they come up with.

The communication with upstream became increasingly problematic: upstream suddenly wanted to publish bugfixes earlier than we suggested, even though many issues were still unaddressed. We tried to dissuade upstream and quickly involved the distros mailing list to make other distributors aware of the issues. We exceptionally suggested a publication date beyond our maximum 90 days embargo to the list, to accommodate for the chaotic situation that the embargo ended up in.

After some further not very productive attempts to develop patches in cooperation with upstream, we decided to take the matter into our own hands. We developed the missing bugfixes and adjusted and properly documented the patches that had already been drafted by upstream. In doing this, we deduced that a dedicated upstream would likely have been able to complete the coordinated disclosure process within about two weeks.

We are not satisfied with how this coordinated disclosure developed, and we will try to be more attentive to such problematic situations early on in the future. This experience also sheds light on the overall situation of Screen upstream. It looks like it suffers from a lack of manpower and expertise, which is worrying for such a widespread open source utility. We hope this publication can help to draw attention to this and to improve this situation in the future.

7) Affectedness Matrix

8) Timeline

9) References

• Screen GNU Savannah Project Page
• openSUSE Bugzilla Screen Review Bug
• Links to Private GNU Savannah Bugs (it seems upstream cannot make them accessible even after publication)

Finally, a new syslog-ng release! As you can see from its version number, this is a bug fix release. It took a bit longer than expected, as we wanted to release it in sync with syslog-ng PE, the commercial variant of syslog-ng. 4.8.2 serves not just as the foundation of the new syslog-ng PE release, but also provides fixes to 4.8.1, which is included in major Linux distributions. This update ensures that all our recent bug fixes reach the majority of our users.

Read more at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-4-8-2-is-now-available

Table of Contents

• 1) Introduction
• 2) Bypass of the openSUSE Packaging Policy via a “License Agreement” Dialog
• 3) Review History of Deepin Components
  • 2017-12-04: deepin-api: Initial Review of D-Bus Service and Polkit Actions
  • 2019-03-25: deepin-clone: Polkit Action com.deepin.pkexec.deepin-clone
  • 2019-05-05: deepin-file-manager: D-Bus Service and Polkit Actions
  • 2019-05-23: deepin-anything: D-Bus Service
  • 2021-02-01: dtkcommon: FileDrag D-Bus Service
  • 2021-02-06: deepin-system-monitor: Polkit Policy
  • 2023-05-13: deepin-app-services: dde-dconfig-daemon D-Bus Service
  • 2023-05-13: deepin-api: Follow-up Review of D-Bus and Polkit
  • 2024-08-29: deepin-api-proxy: D-Bus Service
  • 2024-09-02: deepin-system-monitor: added D-Bus service and new Polkit actions
• 4) Conclusions about the Future of Deepin in openSUSE
• 5) How to Continue Using Deepin on openSUSE
• 6) References
  • Dedicated Security Reports
  • Review Bugs
• Change History

1) Introduction

The Deepin desktop environment (DDE) is part of the Deepin Linux distribution. It focuses on usability, a polished graphical presentation and support for the Chinese language. It is also available on a number of other Linux distributions, openSUSE among them.

Recently we noticed a policy violation in the packaging of the Deepin desktop environment in openSUSE. To get around security review requirements, our Deepin community packager implemented a workaround which bypasses the regular RPM packaging mechanisms to install restricted assets.

As a result of this violation, and in the light of the difficult history we have with Deepin code reviews, we will be removing the Deepin Desktop packages from openSUSE distributions for the time being.

In this blog post we will look at the exact nature of the policy violation, the review history of Deepin components in openSUSE and the conclusions we draw from all of this. Finally, we will give an outlook on how this situation could be resolved, and how users of openSUSE can continue to opt-in to use Deepin in the future.

2) Bypass of the openSUSE Packaging Policy via a “License Agreement” Dialog

The SUSE security team enforces a number of packaging restrictions for openSUSE distributions. Among others, the installation of D-Bus system service configuration files and Polkit policies requires a review by us. When we are satisfied with a package’s security, then we whitelist the respective components. From there on, the package can be submitted to the openSUSE:Factory project in the Open Build Service, which is the base for the openSUSE Tumbleweed rolling release distribution.

For a large software suite like Deepin, which contains a significant number of D-Bus services, this can be a difficult initial hurdle to overcome. We have been in contact with the openSUSE Deepin packager ever since 2017, and have whitelisted various Deepin D-Bus components in the meantime. A number of remaining Deepin review bugs have seen little progress in recent years, however, because the issues we pointed out have not been addressed properly.

Perhaps tired of waiting, the packager decided to try a different avenue to get the remaining Deepin components into openSUSE skirting the review requirements. In January 2025, during routine reviews, we stumbled upon the deepin-feature-enable package, which was introduced on 2021-04-27 without consulting us or even informing us. This innocently named package implements a “license agreement dialog” which basically explains that the SUSE security team has doubts about the security of Deepin, but to properly use Deepin, certain components need to be installed anyway. Thus, if the user does not care about security then “the license” should be accepted. If the user accepts, the missing D-Bus configuration files and Polkit policies are automatically extracted into system directories from tarballs found in the deepin-daemon-dbus and deepin-daemon-polkit packages. The license text also contains a hint suggesting to manually install the deepin-file-manager-dbus and deepin-file-manager-polkit packages and run a script to sideload further configuration files that are needed for the Deepin file manager D-Bus component to work.

For end users, this effectively means that typing “y” once during the installation of the Deepin pattern is enough to opt in to activating components with questionable security which have not been accepted by the SUSE security team.

Given the number of reviews that happened over many years, with some decline in frequency and activity, we had wrongly assumed that by now the bulk of Deepin D-Bus components had managed to enter openSUSE:Factory after being whitelisted by us (apart from some optional utility packages). Instead we had to find out that core components, which are found in the deepin-daemon package, had never been submitted for our review, but had been smuggled into openSUSE.

A review bug has been running for Deepin file manager since 2019 without the package reaching a satisfying state. Offering users the ability to run a script to activate the problematic components is less critical than automatically doing so via a crafted “license dialog”, but is still an unclean and questionable approach.

3) Review History of Deepin Components

This section gives an overview of the long history of review requests for Deepin components in openSUSE. This should give an insight into the effort that already went into checking Deepin’s security, and the difficulties that we often encountered in attempting to arrive at a good solution.

2017-12-04: deepin-api: Initial Review of D-Bus Service and Polkit Actions

This was the first review request we received for Deepin. It reached us during a time of restructuring in our team, which caused a delay of about half a year before we found time to work on it. deepin-api contained a D-Bus service which ran as root, offering a miscellaneous collection of D-Bus methods on the D-Bus system bus e.g. for playing audio files.

We found various issues in the D-Bus method implementations. Most prominently, any user in the system was allowed to run various commands like rfkill with arbitrary parameters as root. Polkit authentication was only implemented in some of the D-Bus methods, while others merely had a TODO: marker to add authentication. Furthermore, the Polkit authentication that was implemented for some methods was subject to a race condition allowing authentication bypass.

The Deepin packager involved upstream and we started a discussion in the review bug about how to address the issues. A first attempt to fix them produced incomplete results. We asked for a formal security contact at the Deepin project to offer coordinated disclosure, since we found problems in other Deepin components as well in the meantime. We did not receive an answer to this, though.

After this initial activity there was no more progress for six months, which is why we closed the bug due to inactivity in December 2019. In April 2021 the Deepin packager reopened this bug assigning it to an upstream developer. In July 2021 we were finally pointed to the proper fixes for the issues, and we granted a whitelisting for this specific Deepin component in August 2021.

2019-03-25: deepin-clone: Polkit Action com.deepin.pkexec.deepin-clone

deepin-clone is a backup utility for the Deepin desktop. In March 2019 we received a review request for a Polkit action contained in the package. We found a large number of issues in the implementation of this Polkit action, such as problematic predictable /tmp file uses, a world-readable log file in a fixed path in /tmp and the possibility to prevent the unmounting of temporarily mounted block devices.

We reported these issues to the packager in April 2019. In July 2019 we were pointed to a couple of fixes, but we found that some issues had still not been addressed and the code in general still looked unclean. The more severe issues had been fixed at least, thus we requested CVEs for them and published a report on the oss-security mailing list.

We never heard back about the remaining concerns we had, thus the whitelisting for this component was never granted.

2019-05-05: deepin-file-manager: D-Bus Service and Polkit Actions

In May 2019 we received review requests for the D-Bus part and the Polkit part of the deepin-file-manager package. This application is a file manager similar to Dolphin in KDE or Nautilus in GNOME. The D-Bus service implemented in the package offers methods to perform actions like mounting Samba network shares or managing the UNIX group membership for user accounts in the system. This is one of the packages for which the Deepin packager eventually implemented a whitelisting bypass, as explained in section 2).

After reviewing the main D-Bus service, we could not help ourselves but call it a security nightmare. The service methods were not only unauthenticated and thus accessible to all users in the system, but the D-Bus configuration file also allowed anybody to own the D-Bus service path on the system bus, which could lead to impersonation of the daemon. Among other issues, the D-Bus service allowed anybody in the system to create arbitrary new UNIX groups, add arbitrary users to arbitrary groups, set arbitrary users’ Samba passwords or overwrite almost any file on the system by invoking mkfs on them as root, leading to data loss and denial-of-service. The daemon did contain some Polkit authentication code, but it was all found in unused code paths; to top it all off, this code used the deprecated UnixProcess Polkit subject in an unsafe way, which would make it vulnerable to race conditions allowing authentication bypass, if it had been used.

Other Polkit policies found in the package were at least being used. One Polkit action allowed locally logged-in users to run /usr/bin/usb-device-formatter as root without authentication. The program allowed to determine the existence of arbitrary files in the system, and to unmount or format non-busy file systems. A Deepin developer joined the discussion in the bug and again we tried to bring to upstream’s attention the overarching security situation in Deepin, but to no avail.

A couple of bugfixes appeared for the Polkit issues but once more they were incomplete. By December 2019 we did not receive any further responses, thus we closed the bug without whitelisting the Polkit policies. In March 2021 the Deepin packager reopened the bug but only pointed us to supposed fixes later in October 2022. We moved the discussion for the Polkit parts into the other bug for the D-Bus service component at this time.

For the D-Bus service issues we did not receive any response at all, and thus also closed the bug in December 2019 without whitelisting the service. Meanwhile we published our findings on the oss-security mailing list in August 2019. In April 2021 the Deepin packager reopened the bug, stating that upstream would be working on the issues. In August 2021 an upstream developer was assigned to the bug, who pointed to a partial bugfix but at the same time stated that Deepin developers had “different opinions” about the reported security issues, without providing further details, however.

In October 2022 the Deepin packager pointed us to more fixes and a new release packaged for openSUSE. The D-Bus interface received major changes at this point. Polkit authentication was added to some D-Bus calls now, but it again used the deprecated UnixProcess subject in an unsafe manner, which would allow to bypass authentication by winning a race condition. Newly added D-Bus methods also introduced new issues, such as lacking path validation when unmounting Samba shares. Some other methods again were left completely unauthenticated.

In November 2023 the Deepin packager informed us about another new release that was supposed to contain more bugfixes. This time some of the problematic D-Bus methods disappeared completely, but some of the original issues as well as confusing and broken Polkit authentication attempts remained.

In April 2024 the Deepin packager informed us again about a new release containing bugfixes. Some more D-Bus methods simply disappeared, some now actually used proper Polkit authentication based on the D-Bus system bus name. The D-Bus service configuration still allowed any user in the system to impersonate the service, however. Also, once more, a bunch of newly added D-Bus methods introduced new problems. One of them, for example, allowed any user in the system to start the Samba system daemons nmbd and smbd. A lot of path verification issues also lingered in the new APIs.

We did not get further responses for these reviews, and the components are still not whitelisted for openSUSE. Due to the frequent alteration of the D-Bus methods in the Deepin file manager daemon, which led to partial bugfixes and new issues appearing, we also refrained from assigning further CVEs for the issues. Formally, each incomplete bugfix would need a dedicated CVE, which would have led to a confusingly long list of CVEs revolving around the same topic: that the Deepin file manager daemon has major security issues, some of them likely still unfixed.

2019-05-23: deepin-anything: D-Bus Service

In May 2019 we received a review request for the deepin-anything package. This component acts as the back end for a desktop search engine. Given the number of unsolved Deepin related reviews we already faced at this time, we refused to work on this additional review until the others would have been resolved.

Still, just from taking a quick look at the package we noticed yet another issue: the D-Bus service configuration allowed any user in the system to register the deepin-anything service on the system bus.

In September 2024 the Deepin packager approached us again pointing to changes in the upstream D-Bus configuration. We did not get around to looking more closely into it again, as we treated Deepin with lower priority at that time.

2021-02-01: dtkcommon: FileDrag D-Bus Service

Another review request arrived in February 2021. This time it was about a “com.deepin.dtk.FileDrag” D-Bus interface, but the actual implementation of this D-Bus service remained a mystery to be found. In the end, upstream moved this interface to the D-Bus session bus in July 2021 and no whitelisting on our end was necessary after all.

Interestingly the Deepin packager stated in the bug that upstream finds itself unable to respond to security bug reports, which is rather worrying for such a big project with such an amount of security issues uncovered.

2021-02-06: deepin-system-monitor: Polkit Policy

This request also arrived in February 2021. It is one of the few Deepin reviews that was completed quite quickly and without any major worries. The Polkit policy only allowed execution of programs like kill, renice and systemctl via the pkexec utility. This was only allowed with admin authentication. We whitelisted the policy in May 2021.

2023-05-13: deepin-app-services: dde-dconfig-daemon D-Bus Service

Here we see a gap of about two years since the last Deepin review request. This might be due to the fact that the offending deepin-feature-enable package had meanwhile been introduced in May 2021 to circumvent the whitelisting requirements. It seems the packager was still willing to involve us in newly added Deepin packages that contained D-Bus components, however.

Sadly the review of deepin-app-services was another chaotic case, one that is actually still unfinished. Even understanding the purpose of this D-Bus service was difficult, because there wasn’t really any design documentation or purpose description of the component. From looking at the D-Bus service implementation, we judged that it is a kind of system wide configuration store for Deepin. Contrary to most other Deepin D-Bus services, this one is not running as root but as a dedicated unprivileged service user.

We quickly found one class of issues in this D-Bus service, namely the crafting of relative path names by adding ../ components to various D-Bus input parameters that are used for looking up configuration files. It seemed the D-Bus service should only allow the lookup JSON configuration files from trusted paths in /usr. By constructing relative paths, however, the D-Bus service could be tricked into loading untrusted JSON configuration from arbitrary locations. We were not completely sure about the impact of this, given the abstract nature of the configuration store, but it seemed to have security relevance, since upstream reacted to our report of the issue.

It took three passes and a year of time, however, for upstream to fix all combinations of input parameters that would allow construction of arbitrary paths. Upstream did not verify and solve these on their own. Instead they only fixed the concrete issues we reported and, when we returned to the review, we found yet more ways to escape the /usr path restriction.

In December 2024 we were close to whitelisting this D-Bus service. With this much time passed, however, we thought it would be better to have a fresh look at the current situation in the D-Bus interface. This led to a series of new concerns, partly again in the area of path lookup, but also due to the fact that arbitrary users could read and store configuration for arbitrary other users. There was a lack of Polkit authentication and user separation in the interface.

2023-05-13: deepin-api: Follow-up Review of D-Bus and Polkit

In parallel to the deepin-app-services review described in the previous section, we also received a follow-up review request for deepin-api. The trigger for this review was that upstream renamed their D-Bus interface and Polkit action names from com.deepin.* to org.deepin.*.

Luckily, this time the implementation of the D-Bus service did not change much compared to the last time and we could not identify any new security issues. For this reason we quickly accepted the changes and finished the review.

2024-08-29: deepin-api-proxy: D-Bus Service

After a longer time of standstill regarding Deepin reviews, a request for the addition of deepin-api-proxy arrived. This package greeted us with over two dozen D-Bus configuration files. Again, upstream’s description of what the component is supposed to do was very terse. From looking at the implementation we deduced that the proxy component seems to be related to the renaming of interfaces described in the previous section.

We found a design flaw in the proxy’s design which allowed a local root exploit. You can find the details in a dedicated blog post we published about this not too long ago.

It is noteworthy that the communication with upstream proved very difficult during the coordinated disclosure process we started for this finding. We did not get timely responses, which nearly led us to a one-sided publication of the report, until upstream finally expressed their wish to follow coordinated disclosure at the very last moment. The actual publication of the upstream fix was not communicated to us and neither was the bugfix shared or discussed with us. This resulted in a follow-up security issue, since upstream once again relied on the unsafe use of the deprecated Polkit UnixProcess subject for authentication.

The review of this component was also what led us to the discovery of the deepin-feature-enable whitelisting bypass, since we installed the full Deepin desktop environment for the first time in a long time, which triggered the “license agreement” dialog described above. After finding out about this, we decided that it was time to reassess the overall topic of Deepin in openSUSE based on our long-standing experiences.

2024-09-02: deepin-system-monitor: added D-Bus service and new Polkit actions

The deepin-system-monitor received additions in the form of a new D-Bus service and additional Polkit actions. We accepted the D-Bus service although it contained some quirks. We did not find time to fully complete the review of the Polkit actions until now, however. A second look that we had at the D-Bus service showed that it was once more using the deprecated UnixProcess subject for Polkit authentication in an unsafe way. This is something that we had previously overlooked.

4) Conclusions about the Future of Deepin in openSUSE

The experience with Deepin software and its upstream during the code reviews that we performed has not been the best. More than once, security issues we reported have been replaced by new security issues. Other times, upstream did not invest the effort to fully analyze the issues we reported and fixed them insufficiently. Generally the communication with upstream proved difficult, maybe also due to the language barrier. While upstream stated at times that they don’t have enough resources to deal with security reports, which is worrying enough, the design and implementation of Deepin D-Bus components often changed radically in unrelated ways. This makes the security assessment of Deepin components a moving target. Building trust towards Deepin components has thus been extremely difficult over the years.

The history of Deepin code reviews clearly shows that upstream is lacking security culture, and the same classes of security issues keep appearing. Although we only looked at a small fraction of the code Deepin consists of, we found security issues nearly every time we looked at one of its components. Based on these experiences, we expect further security issues to linger in the rest of the Deepin code that does not stick out, as the D-Bus services do (as they run with raised privileges). Given the experiences we have gathered with Deepin D-Bus services, we consider it likely that they break user isolation. These components are certainly not fit for multi-user systems; even on single user systems they will be weakening defense-in-depth significantly.

The discovery of the bypass of the security whitelistings via the deepin-feature-enable package marks a turning point in our assessment of Deepin. We don’t believe that the openSUSE Deepin packager acted with bad intent when he implemented the “license agreement” dialog to bypass our whitelisting restrictions. The dialog itself makes the security concerns we have transparent, so this does not happen in a sneaky way, at least not towards users. It was not discussed with us, however, and it violates openSUSE packaging policies. Beyond the security aspect, this also affects general packaging quality assurance: the D-Bus configuration files and Polkit policies installed by the deepin-feature-enable package are unknown to the package manager and won’t be cleaned up upon package removal, for example. Such bypasses are not deemed acceptable by us.

The combination of these factors led us to the decision to remove the Deepin desktop completely from openSUSE Tumbleweed and from the future Leap 16.0 release. In openSUSE Leap 15.6 we will remove the offending deepin-feature-enable package only. It is a difficult decision given that the Deepin desktop has a considerable number of users. We firmly believe the Deepin packaging and security assessment in openSUSE needs a reboot, however, ideally involving new people that can help get the Deepin packages into shape, establish a relationship with Deepin upstream and keep an eye on bugfixes, thus avoiding fruitless follow-up reviews that just waste our time. In such a new setup we would be willing to have a look at all the sensitive Deepin components again one by one.

This is a process that will take time, of course, and there are limits to what we as a security team can do. Given the size of the Deepin project we would also like to see other Linux distributions and the (security) community join us in trying to establish a better security culture with Deepin upstream.

5) How to Continue Using Deepin on openSUSE

Given the security record of Deepin and the concerns expressed in the previous section, we don’t recommend to use the Deepin desktop at this time. If you still would like to install (or continue using) the Deepin desktop on openSUSE Tumbleweed despite the existing security concerns, then you can add the Deepin devel project repositories to your system as follows:

# add the devel project repository for Deepin to zypper
# for other distributions you need to adjust the URL here to point to the proper repository for your case
root# zypper ar https://download.opensuse.org/repositories/X11:/Deepin:/Factory/openSUSE_Tumbleweed deepin-factory
# refresh zypper repositories
root# zypper ref
New repository or package signing key received:

  Repository:       deepin-factory
  Key Fingerprint:  EED7 FE07 D0FC DEF0 E5B4 D4A9 C0DA 4428 1599 EA1E
  Key Name:         X11:Deepin:Factory OBS Project <X11:Deepin:Factory@build.opensuse.org>
  Key Algorithm:    RSA 2048
  Key Created:      Sat Apr 29 01:27:01 2023
  Key Expires:      Mon Jul  7 01:27:01 2025
  Rpm Name:         gpg-pubkey-1599ea1e-644c5645



    Note: Signing data enables the recipient to verify that no modifications occurred after the data
    were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system
    and in extreme cases even to a system compromise.

    Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key\'s name. If
    you are not sure whether the presented key is authentic, ask the repository provider or check
    their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they
    are using.

Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r):

The current GPG key fingerprint for this project is EED7 FE07 D0FC DEF0 E5B4 D4A9 C0DA 4428 1599 EA1E. You can verify it yourself by downloading the public key , importing it via gpg --import and checking the output of gpg --fingerprint for the newly imported key.

Note that by doing this you will trust any packages originating from this devel project, which are neither vetted by the SUSE security team nor by the openSUSE package submission review teams.

For openSUSE Leap you need to adjust the repository URL to point to the proper Leap repository for your system.

6) References

• Deepin desktop website
• openSUSE packaging security guidelines
• deepin-feature-enable package (implements whitelisting bypass)

Dedicated Security Reports

• blog post about deepin-api-proxy security issues
• oss-security report about various Deepin issues
• oss-security report about deepin-clone issues

Review Bugs

• initial deepin-api review bug (bsc#1070943)
• follow-up deepin-api review bug (bsc#1211376)
• deepin-clone review bug (bsc#1130388)
• deepin-file-manager Polkit policy review bug (bsc#1134131)
• deepin-file-manager D-Bus review bug (bsc#1134132)
• deepin-anything review bug (bsc#1136026)
• dtkcommon FileDrag D-Bus review bug (bsc#1181642)
• deepin-system-monitor review bug (bsc#1181886)
• deepin-app-services review bug (bsc#1211374)
• deepin-api-proxy review bug (bsc#1229918)
• deepin-system-monitor D-Bus additions review bug (bsc#1229918)
• deepin-system-monitor Polkit additions review bug (bsc#1233054)

Change History

Heading to the openSUSE Conference 2025 in Nuremberg? Great news! The project will have a shop available at the conference venue where attendees can purchase openSUSE merchandise! Items available at the shop will include popular products from Freewear.org’s openSUSE section.

Between 100 to 125 items, mainly t-shirts, will be available as a preview of brand-new designs that emphasize Leap, Tumbleweed, Slowroll, Aeon and Kalpa and MicroOS. These new items aren’t yet listed on Freewear.org’s website, but there are plans to update the online shop with all of them after the conference.

If you’re particularly interested in specific items, sizes, or styles, we encourage you to email your request in advance to ddemaio@opensuse.org and ishwon@openSUSE.org with the subject line “oSC25 Shop Selection”. Please do this before June 4 since shipments will happen around this time. This helps us better prepare and ensure we have the most requested items available during the event.

Event Details

• Conference Dates: June 26 – 28, 2025
• Location: Z-Bau, Nuremberg, Germany
• What to Expect: Talks, workshops, and community networking

The openSUSE Conference is a free, community-driven event that brings together contributors, developers and enthusiasts from across the globe to collaborate on open-source software development.

Pre-Party

Kick things off early! Join us for the pre-party on June 25 at Kater Murr.

Come by anytime after 6 p.m. and connect with fellow attendees ahead of the main event. 📍 Kater Murr on OpenStreetMap
📍 Google Maps Location

Stay tuned, get involved, and don’t forget to gear up at oSC25!

Microsoft will end support for Windows 10 on Oct. 14 and this will likely trigger a surge in unnecessary electronic waste (e-waste) on International E-Waste Day, which is a day designed to raise awareness about the global issue of e-waste and promote responsible recycling and disposal practices.

The openSUSE Project’s Upgrade to Freedom campaign urges people to extend the life of their device rather than becoming e-waste. Since millions of Windows 10 users may believe their devices will become useless and contribute to the waste of fully functional devices, installing a Linux operating systems like openSUSE or another Linux distribution is more reasonable.

A new initiative called End of 10 has launched that shares the purposes and origin of openSUSE’s Upgrade to Freedom efforts. As the #endof10 initiative also intends to help people extend the life of devices that would otherwise become e-waste, rather than dilute the messaging and narrative, members of openSUSE marketing have decided to transition the Upgrade to Freedom campaign to joining the End of 10 initiative.

The project will update all its previous Upgrade to Freedom content to reflect these changes.

Many articles in the media report that Microsoft demands new hardware or extended support payments for continued use of Windows. Many users own computers that still run well but fail to meet Windows 11 upgrade requirements.

Most computers built after 2010 can run Linux operating systems like openSUSE, Fedora, or Debian with excellent performance. The campaign encourages users to upgrade their software, not their hardware.

Volunteers developed endof10.org as a resource hub. Users can find local repair groups, download installation tools and offer support to others. The site connects people who want to switch away from Windows with those ready to help.

The End of 10 organizers have launched the first phase with outreach to FOSS communities, Repair Cafes, and media outlets. Over the next several months, they will promote install fests and coordinate local outreach events. They will continue promoting the campaign throughout 2025 as the Windows 10 deadline approaches.

Organizers encourage teachers, developers, and students to join the effort.

We encourage everyone to learn more about the campaign at endof10.org.

Additional Information

What does the “End Of 10” campaign have planned? At the moment, activities include traditional media outreach, social media campaigns, and in-person install events ramping up to 14 October. As an example, we are planning a “Lists of 10” campaign with the hashtag #EndOf10, with topics like:

• “10 reasons to switch to Linux”
• “10 Free & Open Source apps to try on your new Linux computer”
• “10 Free & Open Source apps you may already use but didn’t know it”

Important: End Of 10 wants the larger FOSS universe to be at the center of everything the campaign does. The goal of the campaign is to speak as a big FOSS family and therefore there is no tolerance for negative messaging about other FOSS communities.

We hope you and other FOSS members will join us in the End Of 10 campaign, so we can promote Free & Open Source Software as a solution for Windows 10 users who wish to keep their devices safely in use, together.

This is part of a series on End of 10 where we advocate for Free & Open Source Software as a solution for Windows 10 users who wish to keep their devices rather than contributing to e-waste of functioning devices.

Qactus 3.0.0 comes with many changes, such as:

• UI redesign, package-centred with a modern style (Plasma-ish)
• Code ported to Qt6
• Improved memory usage
• New features:
  • Location bar
  • Search bar
  • Project/package overview
  • Getting revisions
  • Getting requests per project/package
• New logo
• Multiple fixes (and some bugs?
• Switch to Apache License 2.0

RPM packages

I have also updated jOBS, a Java-based Open Build Service library and developed a basic GUI for it,
OBS FX; it is a JavaFX-based OBS client with a green touch

The rpm and zip are available at GitHub.
Download OBS FX