Mon, May 12th, 2025


Yo voy a Akademy-es 2025 de Málaga #OpenSouthcode edition II #akademyes
El 20 y 21 de junio se va a celebrar el mayor evento de la Asociación KDE España. Si quieres ayudar en la promoción de este evento aquí te dejo una forma de hacerlo de forma muy sencilla: comparte el banner «Yo voy a Akademy-es 2025 de Málaga #OpenSouthcode edition II» en tus redes sociales para que lleguemos a todo el mundo. Pon tu granito de arena para que seamos una gran montaña de conocimiento compartido.
Yo voy a Akademy-es 2025 de Málaga #OpenSouthcode edition II #akademyes
Un año más… y ya no recuerdo cuantos llevamos ya, tenemos un banner expresamente creado para el evento, durante unos años fue fruto de la ayuda desinteresada de Rosanna García, compañera y amiga de cientos horas de docencia, paciencia y terapia en forma de charla.
En esta ocasión ha sido gracias a Carlos A.F., nacido de una petición realizada en el grupo de Telegram Oficial de KDE España, conocido como Cañas y Bravas, que tiene una subsección llamada «Se necesita voluntario/a para…», en un tiempo récord.
Gracias a sus dotes artísticas creó un banner que vamos a ir adaptando para todas las necesidades de promoción que deseemos. De hecho ya lo he iré utilizando en el blog para buscar patrocinadores del evento, para anunciar el programa. Hoy lo utilizo para poner el clásico «Yo voy…» que muchos eventos usan para promocionarse.

El banner este año está inspirado en la Catedral de Málaga acompañada de la Comunidad de Konqis mostrando la variedad en el Proyecto KDE.
¿Qué es Akademy-es?
Akademy-es (#akademyes, que es la etiqueta para las redes sociales) es evento más importante para los desarrolladores y simpatizantes de KDE, que se ha ido celebrando desde el 2006 con éxito creciente.
En general, las Akademy-es son el lugar adecuado para conocer a los desarrolladores, diseñadores, traductores, usuarios y empresas que mueven este gran proyecto.
En ellas se realizan ponencias, se presentan programas, se hace un poco de caja para los proyectos libres (camisetas, chapas, etc) pero sobre todo se conoce a gente muy interesante y se cargan baterías para el futuro.
Podéis repasar las anteriores ediciones en estas entradas del blog:
- Camino Akademy-es 2013: Las anteriores ediciones (I): 2006 – 2008
- Camino Akademy-es 2013: Las anteriores ediciones (II): 2009-2010
- Camino Akademy-es 2013: Las anteriores ediciones (III): 2011-2012
- Anteriores ediciones de Akademy-es (IV): 2013 y 2014
La entrada Yo voy a Akademy-es 2025 de Málaga #OpenSouthcode edition II #akademyes se publicó primero en KDE Blog.


Multiple Security Issues in Screen
Table of Contents
- 1) Introduction
- 2) Overview of Screen Configurations and Versions
-
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
- 3.a) Local Root Exploit via
- 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
System | Screen Version | Special Privileges | Affected by | Comment |
---|---|---|---|---|
Arch Linux | 5.0.0 | setuid-root | 3.a, 3.b, 3.c, 3.d, 3.e, 3.f | |
Debian 12.10 | 4.9.0 | 3.b (partly) | ||
Ubuntu 24.04.2 | 4.9.1 | 3.b (partly) | ||
Fedora 42 | 5.0.0 | setgid-screen | 3.b (partly), 3.f | 5.0.0 is only found in the recently released Fedora 42 |
Gentoo | 4.9.1 | setgid-utmp (setuid-root if multiuser USE flag is set) | 3.b (partly) | 5.0.0 is available via the unstable ebuild |
openSUSE TW | 4.9.1 | 3.b (partly) | ||
FreeBSD 14.2 | 4.9.1 | setuid-root | 3.b, 3.d, 3.e | |
NetBSD 10.1 | 5.0.0 | setuid-root | 3.a, 3.b, 3.c, 3.d, 3.e, 3.f (without visible crash) | update to 5.0.0 was only released recently |
OpenBSD 7.7 | 4.9.1 | 3.b (partly) |
8) Timeline
2024-07-01 | A review request from upstream was forwarded to us. |
2025-01-08 | We started working on the review. |
2025-02-07 | We privately reported the issues to the Screen upstream by email, offering coordinated disclosure. |
2025-02-07 | Upstream expressed that they will need 1 - 2 months of time to work on the issues, likely requiring most of the 90 days maximum embargo period we offered. |
2025-02-11 | We created private bugs in the GNU Savannah bug tracker to deal with each finding. |
2025-03-11 | Some discussions started in the private GNU Savannah bugs about patches for a couple of the findings. |
2025-04-29 | After nearly a month without visible activity, and the 90 days maximum embargo time approaching we asked upstream for the current status and procedures for publication of the report. |
2025-04-30 | Upstream started taking up work again, trying to come up with fixes until the end of the 90 day embargo period. We offered advice on the various patches in the private GNU Savannah bugs. |
2025-04-30 | Following some unclarity in the discussion with upstream regarding CVE assignment, we decided to assign CVEs for the security relevant issues. |
2025-04-30 | Upstream declared its intention to publish something on the weekend, while bugfixes were still missing. We urged them not to do this. In the light of this we quickly forwarded a draft of this report to the distros mailing list to give other distributors the chance to react to these findings before they go public. |
2025-05-05 | Although we did not get a clear answer, upstream ended up not publishing one-sidedly. Given the chaotic situation we suggested a publication date of 2025-05-12 to the distros mailing list, which was a few days after the 90 days maximum embargo period we usually offer upstream. |
2025-05-07 | Further attempts to develop the missing bugfixes in cooperation with upstream seemed futile. We started to develop all necessary patches on our own, some of them based on patches that had already been discussed in the upstream Savannah bugs. We shared the finished and tested patches for screen 4.9.1 and screen 5.0.0 with the distros mailing list and upstream. |
2025-05-08 | Upstream complained about wrong Author: tags in some of the patches we distributed (we did not receive formally finished patches from upstream, only copy/paste snippets). Thus we adjusted the authorship information for these patches to accommodate for this complaint and shared the updated result with the distros mailing list again. |
2025-05-12 | Publication of the report happened as planned on our blog and on the oss-security mailing list. |
9) References
Sun, May 11th, 2025

Cumpleaños de un reloj
Hace ya muchos años, por recomendación de mi hermana, descubrí el fascinante mundo de los Cronopios y Famas de los que el gran Julio Cortázar hizo de historiador, dejando huella escrita de aquello que les ocurría.

Fue el primer paso para descubrir más cuentos y libros de este escritor. Lo reconozco, hay muchos relatos que me fascinan y todavía tengo en mi memoria y otros libros con los que no he podido. Sí Rayuela, te estoy mirando a tí. Aunque lo he ido desgranando de a poco.
Pero de aquellas historias de Cronopios y Famas, una que me gustó y que con el tiempo le he escuchado de la voz de Cortázar y recuperado de tanto en tanto es el «Preámbulo a las instrucciones para dar cuerda a un reloj» ¿Lo recuerdas?
Te dejo aquí el texto y un enlace para escucharlo de la voz de Cortázar con su característico acento y compás:
Piensa en esto: cuando te regalan un reloj te regalan un pequeño infierno florido, una cadena de rosas, un calabozo de aire. No te dan solamente el reloj, que los cumplas muy felices y esperamos que te dure porque es de buena marca, suizo con áncora de rubíes; no te regalan solamente ese menudo picapedrero que te atarás a la muñeca y pasearás contigo. Te regalan -no lo saben, lo terrible es que no lo saben-, te regalan un nuevo pedazo frágil y precario de ti mismo, algo que es tuyo pero no es tu cuerpo, que hay que atar a tu cuerpo con su correa como un bracito desesperado colgándose de tu muñeca.
Te regalan la necesidad de darle cuerda todos los días, la obligación de darle cuerda para que siga siendo un reloj; te regalan la obsesión de atender a la hora exacta en las vitrinas de las joyerías, en el anuncio por la radio, en el servicio telefónico. Te regalan el miedo de perderlo, de que te lo roben, de que se te caiga al suelo y se rompa. Te regalan su marca, y la seguridad de que es una marca mejor que las otras, te regalan la tendencia de comparar tu reloj con los demás relojes. No te regalan un reloj, tú eres el regalado, a ti te ofrecen para el cumpleaños del reloj.
Este texto degranaba hace ya más de 60 años, las preocupaciones a la hora de mantener «con vida» al reloj que descuidadamente te regalan y que en el fondo, como culmina Cortázar en su texto, lo que hacen es ofrecerte a ti como regalo al reloj.
Cortázar señalaba en ese texto cómo con un gesto despreocupado y en el fondo generoso, te cercaban con una nueva preocupación que antes no tenías. Habías adoptado desde entonces y sin quererlo la necesidad de estar pendiente de algo ajeno a ti mismo y que quizás no necesitabas.
Con ese texto como base, hace tiempo que pienso que ahora somos mucho más regalados a nuevos miedos de muchas más cosas. Relojes ultramodernos inteligentes, que mucha gente compr y luce por simple tendencia (todo el mundo lo tiene, ¿no?) más que utilidad. Teléfonos cada vez más intrusivos en nuestro día a día, que se convierten en sumideros de tiempo.
No tenemos que darles cuerda, pero sí alimentar su batería para verla en niveles que no nos estresen si bajan de cierto valor. Nos regalan la imperiosa necesidad de tener que estar al cuidado y pendiente de no dejarlos en casa olvidados encima de cualquier mesa, en la que exalan sus notificaciones y vibraciones para nadie. Faltos de la mirada recurrente cada pocos segundos, que sirve de bálsamo tanto para el que mira como el objeto mirado.
Necesitamos controlar nuestras pulsaciones (¿cómo ha sobrevivido la civilización occidental hasta ahora sin conocer cada individuo ese dato propio en cualquier instante y momento?). Sabemos (y saben) los pasos que damos, los sitios por los que esos pasos nos han llevado y lo que hemos estado haciendo y durante cuanto tiempo. Eres regañado si se te ha solicitado atención y no la has prestado de inmediato. Obviamos los paisajes y los miramos ya no por nuestros ojos si no, por los ojos electrónicos de estos pequeños «picapedreros de tiempo». Capturamos el momento desde su pantalla, y ale a otro sitio que este «ya lo hemos visto».
Desconfiamos de nuestra memoria en pos de estos nuevos residuos de nosotros mismos. Los recuerdos ya no son lo que vimos, si no la foto que sacamos aquel día que vimos algo y la compartimos con gente que quizá ya no conocemos o nunca conocimos.
Y tal día hizo un año y seremos reemplazo de nuevos regalos a nuevos dispositivos que todavía no han creado.



Inhibir la suspensión durante la transferencia de archivos – Esta semana en Plasma
Es increíble el trabajo de promoción que está realizando Nate en su blog, dese hace más del tiempo que puedo recordar. Cada semana hace un resumen de las novedades más destacadas, pero no en forma de telegrama, sino de artículo completo. Su cita semanal no falla y voy a intentar hacer algo que es simple pero requiere constancia. Traducir sus artículos al castellano utilizando los magníficos traductores lo cual hará que: la gente que no domine el inglés esté al día y que yo me entere bien de todo. Bienvenidos pues al primero de la serie «Esta semana en Plasma» que lleva por título «Inhibir la suspensión durante la transferencia de archivos. Espero que os guste y, sobre todo, que pueda mantener el ritmo de publicación de Nate Graham.
Inhibir la suspensión durante la transferencia de archivos – Esta semana en Plasma
Nota: artículo original en Blogs KDE. Traducción realizada utilizando deepl.com. Esta entrada está llena de novedades para Plasma 6.4. Mis comentarios están entre corchetes.
¡Bienvenido a un nuevo número de «Esta semana en Plasma»! Cada semana cubrimos lo más destacado de lo que está sucediendo en el mundo de KDE Plasma y sus aplicaciones asociadas como Discover, System Monitor y más.
Esta semana ha entrado en vigor la «congelación suave de características» de Plasma 6.4, lo que significa que dejamos de incorporar nuevas características a menos que lleven meses en desarrollo y estén casi listas. Así que nos hemos centrado en corregir errores y pulir la interfaz de usuario.
También te habrás dado cuenta de que muchos de los cambios en Plasma de esta semana proceden de KDE Frameworks. Es un buen recordatorio de que estos frameworks apuntalan todo lo que hace KDE – los héroes no reconocidos de la infraestructura que silenciosa y aburridamente hacen posible otro trabajo.
Novedades destacadas
Frameworks 6.15
Los diálogos «Nuevo Archivo» y «Nueva Carpeta» que puedes invocar desde Plasma, Dolphin y otras aplicaciones KDE han sido revisados visualmente. Además, el diálogo de carpetas te permite elegir un icono personalizado desde el mismo diálogo. (Kai Uwe Broulik, enlace 1 y enlace 2) [Realmente parece un cambio atractivo].

La transferencia de archivos en Plasma y aplicaciones KDE ahora inhibe la suspensión, por lo que la transferencia no puede ser inesperadamente interrumpida o cancelada en el medio si el equipo se va a dormir. (Kai Uwe Broulik, enlace) [Esto me parece importantisimo].
Mejoras notables en la interfaz de usuario
Plasma 6.4.0
En la página Aplicaciones del widget Volumen de audio, ahora se mostrará el nombre del medio que se está reproduciendo, siempre que la aplicación lo configure correctamente. Esto resulta especialmente útil para los navegadores web. (Kai Uwe Broulik, enlace) [Y para todos].

En la página de accesos directos de la configuración del sistema, los accesos directos de KWin y Plasma se muestran ahora con nombres más agradables. (Nate Graham, enlace) [Para los que entramos en la etapa de presbicia de nuestras vidas viene genial].
La página Pantalla y monitor de la Configuración del sistema muestra ahora frecuencias de actualización no enteras, como «59,94 Hz». (Xaver Hugl, enlace)
La página Accesibilidad de la Configuración del sistema ahora utiliza un icono más adecuado para la categoría Lector de pantalla. (Christoph Wolk, enlace)

Las ventanas que cometen un error y se olvidan de poner un título ahora no muestran texto en Overview, en lugar de una pequeña burbuja vacía donde debería haber texto. (Nate Graham, enlace)
El widget «Minimizar todas las ventanas» ya no se hace pasar inapropiadamente por un widget «Echar un vistazo al escritorio» mientras está en modo de edición. (Nate Graham, enlace)
Frameworks 6.15
Se ha revisado la infraestructura técnica de cómo Kirigami dibuja los iconos en Plasma y en las aplicaciones KDE basadas en QtQuick, corrigiendo varios problemas visuales relacionados con el resaltado activo que no funcionaba correctamente, especialmente con esquemas de colores oscuros e iconos basados en imágenes. (Arjen Hiemstra, enlace 1, enlace 2 y enlace 3)
Los archivos en ubicaciones de red remotas a los que se accede por su URL (no un montaje local manual) desde Plasma o cualquier aplicación KDE ahora muestran mejor las miniaturas cuando son realmente grandes, y deberían ser más robustos y fiables en general, menos propensos a hacer que la aplicación que los muestra se bloquee (Akseli Lahtinen y John Chadwick, enlace 1 y enlace 2).
Corrección de errores importantes
Plasma 6.3.5
Se ha corregido un caso en el que KWin podía bloquearse al desconectar una base Thunderbolt. (Xaver Hugl, enlace)
Ahora es más fiable interactuar con aplicaciones utilizando el lápiz de una tableta de dibujo. (Xaver Hugl, enlace)
Plasma 6.3.6
Se ha corregido un caso en el que KWin podía bloquearse al dibujar ventanas sin decoración. (Xaver Hugl, enlace)
Las previsualizaciones de temas en la página Colores de la Configuración del Sistema que utilizan la función de tintado completo se muestran ahora correctamente. (Akseli Lahtinen, enlace)
Al utilizar cualquiera de los modos de ordenación automática de los iconos del escritorio, la creación de un nuevo archivo en el escritorio inserta ahora el archivo en su lugar correcto en función del orden de ordenación elegido, en lugar de colocar el nuevo elemento bajo el cursor y restablecer el orden de ordenación a «Manual». (Akseli Lahtinen, enlace)
Plasma 6.4.0
Se ha corregido un caso en el que KWin podía congelarse ocasionalmente durante la reproducción de vídeos de YouTube a pantalla completa en Firefox. (Vlad Zahorodnii, enlace) [Creo que esto le pasa a mi pareja].
Se ha corregido otro caso en el que los discos ópticos aparecían duplicados en el widget Discos y dispositivos. (Bogdan Onofriuchuk, enlace)
La acción «Mover al centro» de KWin vuelve a funcionar independientemente de si la ventana que se está moviendo al centro tiene un cuarto de mosaico. (Vlad Zahorodnii, enlace)
Ya no es posible desplazar graciosamente el texto de las notificaciones de Plasma horizontalmente utilizando un touchpad, ¡haciendo que se deslice fuera de la vista! Ahora no se mueve. (Christoph Wolk, enlace)
Frameworks 6.15
Se ha corregido un error en KConfig que, en determinadas circunstancias, podía impedir la carga de Plasma cuando se compilaba con las afirmaciones activadas. (Akseli Lahtinen, enlace)
Se ha corregido un error en el tema Breeze que hacía que ciertos iconos aparecieran a un tamaño demasiado grande en determinadas aplicaciones GTK. (Christoph Cullmann, enlace)
Se ha corregido el icono del micrófono de Breeze para que no aparezca descentrado en su versión de 22px. (Nate Graham, enlace)
Otra información de errores destacables:
- 1 bug Plasma de muy alta prioridad (igual que teníamos la semana pasada). Lista actual de errores
- 20 fallos de Plasma de 15 minutos (igual que teníamos la semana pasada). Lista actual de fallos
Novedades técnicas y de rendimiento
Plasma 6.3.6
Se ha corregido un problema que impedía que funcionara el ajuste «Preferir precisión del color» al ver vídeos a pantalla completa. (Xaver Hugl, enlace)
Los cálculos del tiempo de transición día/noche de la función Luz nocturna son más precisos gracias al uso de un simulador de tránsito solar específico. (Vlad Zahorodnii, enlace)
Cómo puedes ayudar
KDE se ha convertido en algo importante en el mundo, y tu tiempo y contribuciones nos han ayudado a conseguirlo. A medida que crecemos, necesitamos su apoyo para mantener KDE sostenible.
Puedes ayudar a KDE convirtiéndote en un miembro activo de la comunidad e involucrándote de alguna manera. Cada colaborador marca una gran diferencia en KDE – ¡no eres un número o un engranaje en una máquina!
Tampoco tienes que ser programador. Existen muchas otras oportunidades:
- Clasificar y confirmar informes de errores, tal vez incluso identificar su causa raíz.
- Contribuir al diseño de fondos de pantalla, iconos e interfaces de aplicaciones.
- Diseñar y mantener sitios web
- Traducir elementos de texto de la interfaz de usuario a su propio idioma.
- Promover KDE en su comunidad local
- …¡Y un montón de cosas más!
¡También puedes ayudarnos haciendo una donación! Cualquier contribución monetaria – por pequeña que sea – nos ayudará a cubrir los costes operativos, salarios, gastos de viaje de los colaboradores, y en general a mantener KDE llevando el Software Libre al mundo.
Para obtener una nueva característica de Plasma o una corrección de errores mencionada aquí, siéntase libre de enviar un commit a la solicitud de fusión correspondiente en invent.kde.org.
La entrada Inhibir la suspensión durante la transferencia de archivos – Esta semana en Plasma se publicó primero en KDE Blog.
Sat, May 10th, 2025


The Dark Mod, sigilo 3D legado de Doom 3 – Juegos Linux (XX)
Nueva entrada de la serie de grandes juegos libres. Hoy tenemos entre nosotros un género que no ha aparecido como tal en el blog auqnue si del juego original del que deriva. Se trata del sigilo en tres dimensiones, es decir, el jugador debe evitar a sus enemigos, escondiéndose en las sombras y evitando hacer algún ruido (vía Wikipedia) cambiando totalmente las mecánicas del FPS. Uno de los máximos exponentes de este género el Os presento The Dark Mod, un juego que empezó siendo un mod de Doom 3 inspirado en Thief y que se convirtió en un juego por méritos propios.
The Dark Mod, sigilo 3D legado de Doom 3 – Juegos Linux (XX)
Antes de empezar recordar que ya he tocado muchos de los géneros: estrategia por turnos (The Battle for Wesnoth, Hedgewars), disparos en primera persona (Xonotic, Alien Arena, OpenArena, WarSow), velocidad (Speed Dreams, SuperTuxKart), MMORPG (Ryzom), plataformas (SuperTux), sandbox (Minestest), roguelike (Shattered Pixel Dungeons) simulador (OpenTTD, Simutrans) o estrategia en tiempo real (OpenRa, 0 A.D.) . Así que si no os interesa este, podéis visitar alguno de los enlaces anteriores.
En esta ocasión presento en el blog un género distinto, el sigilo, el cual se caracteriza por ser un subgénero de los juegos de disparos en primera persona (FPS) donde el objetivo no es acabar con los enemigos sino cumplir misiones sin que seas detectado por ellos.
Uno de los máximos exponentes de este género en el mundo Open Source es The Dark Mod, un juego nacido como mod y que por su calidad se convirtió en un juego propio con el paso del tiempo.

Pero mejor que nos lo expliquen los propios desarrolladores:
The Dark Mod fue desarrollado por un sólido grupo de profesionales y aficionados con talento de todo el mundo. La mayoría estaban motivados por su amor a Thief 1 y 2, y vieron el mod como una forma de ofrecer la experiencia de sigilo que deseaban que hubiera sido T3. The Dark Mod se publicó por primera vez como mod para Doom 3 en octubre de 2009. Se convirtió en un juego independiente en octubre de 2013 y, desde entonces, se actualiza con regularidad.
Su última versión es la 2.13 lanzada en marzo de 2024 y su código fuente está bajo Licencia Pública General de GNU y los restantes contendidos están bajo licencias Creative Commons (vía Wikipedia). También es destacable que ha recibido varios premios y menciones, incluyendo el «Mod of the Year» del 2013 de PC Gamer y posiciones destacadas en ModDB.
Las características de The Dark Mod
The Dark Mod es un juego bastante vivo y activo, con una Comunidad que no ha dejado de mejorarlo a lo largo de los años. Sus características principales son:
- Motor gráfico basado en IDTech 4, con mejoras constantes: soporte para Vulkan, mejor rendimiento, nuevos efectos visuales y mejoras en la física y el sonido.
- Efectos de sombreado suave, optimización de texturas, compatibilidad con gamepad ,etc.
- Más de 80 misiones disponibles creadas por la comunidad.
- Escenarios variados tanto en ambientación com en tipo, incluyendo castillos, mansiones, ciudades, prisiones, cuevas y otros entornos oscuros y anacrónicos con elementos medievales y victorianos.
- Variedad de objetos que el jugador puede usar para cumplir sus misiones de sigilo y robo.
- Optimizado para ser jugado en equipos modestos.

Las misiones de The Dark Mod
Una de las características principales de The Dark Mod es su variedad de misiones, lo que lo hace un juego muy jugoso.
Evidentemente, se recomienda a los nuevos jugadores que empiecen con la Misión de Entrenamiento preinstalada y las otras dos misiones incluidas en la descarga del juego, que son introducciones oficiales a la jugabilidad y ambientación de The Dark Mod.
Una vez superadas estas, se recomienda que se descarguen las misiones desde el menú New Mission de The Dark Mod, pero si prefieres descargarlas manualmente puedes hacerlo desde la página de misiones y seguir las siguientes instrucciones:
Para instalar una nueva misión manualmente, descarga el archivo .pk4 (simplemente un archivo .zip con una extensión diferente) que aparece a continuación y colócalo en tu carpeta darkmod\fms. La misión estará disponible la próxima vez que inicies el juego. Más información sobre la instalación de Fan Missions está disponible en nuestra wiki.

¿Cómo conseguir The Dark Mod?
No hay más que visitar la página oficial para ver que hay versión para sistemas GNU/Linux y otra para Windows, aunque hay miembros de la comunidad que han portado el juego a MacOs. Se puede ver el código completo en GitHub.
Además se dispone de la aplicación «Dark Radiant, Mission Editor» para justamente eso, crear nuevas misiones.
¿Puedo participar en su desarrollo?
En su página web no se menciona explícitamente la forma que tenemos de participar en su desarrollo pero si nos vamos a su foro podemos observar que en casi todas las secciones aparece alguna oportunidad para hacerlo.

No obstante la mejor forma de empezar a ayudar en dirigirse al hilo «Can I help?» donde Springheel, uno de los administradores del foro, realizó un hilo donde desgrana cómo ayudar. De esta forma tenemos las siguientes descriptivas opciones, la cuales llevan asociadas el hilo donde participar :
- Puedo grabar vídeo
- Puedo escribir
- Puedo actuar y grabar audio
- Puedo traducir
- Puedo Animar
- Sé C++
- Puedo Editar Imágenes
- I can Take Photos
- No tengo ninguna habilidad
Es decir, si queréis participar no tenéis excusa.
La entrada The Dark Mod, sigilo 3D legado de Doom 3 – Juegos Linux (XX) se publicó primero en KDE Blog.
Fri, May 9th, 2025


Primera actualización de KDE ⚙️ Gear 25.04
La Comunidad KDE es una comunidad responsable y no solo se preocupa en lanzar novedades sino que también en mejorarlas. Me complace presentar la primera actualización de KDE Gear 25.04 que apareció hace casi un mes. Más estabilidad, mejores traducciones y pequeñas mejoras para las aplicaciones de nuestro entornos de trabajo.
Primera actualización de KDE Gear 25.04
A pesar de lo que puedan pensar muchas personas, las aplicaciones no son perfectas. Entre las líneas de código se pueden colar errores de tipografía o que el usuario realice alguna opción que en un principio no estaba prevista por los desarrollador, por poner solo un par de ejemplos de imperfecciones.
Este no es un problema del Software Libre ya que el Software actual funciona de esta manera ya que no se piensa en él como un producto final que se encierra en una caja y se olvida. En la actualidad se sabe que el Software está vivo y sería estúpido ir guardando las mejoras sin dejarlas a disposición del gran público.
Con esto se gana en rapidez y evolución pero puede aumentar el número de errores (por norma general) leves, los cuales son subsanables con pequeñas actualizaciones.
La Comunidad KDE lo tiene claro: grandes lanzamientos cada cuatro meses y actualizaciones mensuales para subsanar errores.

Por ello me congratula compartir con vosotros la primera actualización de KDE ⚙️ Gear 25.04 que nos ofrece más de 180 errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.
Aquí podéis encontrar la lista completa de cambios de KDE Gear 25.04.1, pero por poner unos cuantos ejemplos de los errores que sea han resuelto tenemos:
- Cantor: Corrección de la composición tipográfica LaTeX.
- Dolphin: Corrección de la restauración de carpetas, pestañas y estado de la ventana desde la ejecución anterior .
- Konsole: Corrección del comportamiento de la envoltura de búsqueda en los límites.
Más información: KDE Gear 25.04.01
La entrada Primera actualización de KDE ⚙️ Gear 25.04 se publicó primero en KDE Blog.
Thu, May 8th, 2025


Primera actualización de KDE ⚙️ Gear 25.04
La Comunidad KDE es una comunidad responsable y no solo se preocupa en lanzar novedades sino que también en mejorarlas. Me complace presentar la primera actualización de KDE Gear 25.04 que apareció hace casi un mes. Más estabilidad, mejores traducciones y pequeñas mejoras para las aplicaciones de nuestro entornos de trabajo.
Primera actualización de KDE Gear 25.04
A pesar de lo que puedan pensar muchas personas, las aplicaciones no son perfectas. Entre las líneas de código se pueden colar errores de tipografía o que el usuario realice alguna opción que en un principio no estaba prevista por los desarrollador, por poner solo un par de ejemplos de imperfecciones.
Este no es un problema del Software Libre ya que el Software actual funciona de esta manera ya que no se piensa en él como un producto final que se encierra en una caja y se olvida. En la actualidad se sabe que el Software está vivo y sería estúpido ir guardando las mejoras sin dejarlas a disposición del gran público.
Con esto se gana en rapidez y evolución pero puede aumentar el número de errores (por norma general) leves, los cuales son subsanables con pequeñas actualizaciones.
La Comunidad KDE lo tiene claro: grandes lanzamientos cada cuatro meses y actualizaciones mensuales para subsanar errores.

Por ello me congratula compartir con vosotros la primera actualización de KDE ⚙️ Gear 25.04 que nos ofrece más de 180 errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.
Aquí podéis encontrar la lista completa de cambios de KDE Gear 25.04.1, pero por poner unos cuantos ejemplos de los errores que sea han resuelto tenemos:
- Cantor: Corrección de la composición tipográfica LaTeX.
- Dolphin: Corrección de la restauración de carpetas, pestañas y estado de la ventana desde la ejecución anterior .
- Konsole: Corrección del comportamiento de la envoltura de búsqueda en los límites.
Más información: KDE Gear 25.04.01
La entrada Primera actualización de KDE ⚙️ Gear 25.04 se publicó primero en KDE Blog.


syslog-ng 4.8.2 is now available
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

syslog-ng logo


Quinta actualización de Plasma 6.3
Me alegra compartir con todos vosotros la quinta actualización de Plasma 6.3, iniciando así una serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.
Quinta actualización de Plasma 6.3
No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.
La Comunidad KDE ha publicado la primera actualización de Plasma 6.3, una versión que viene a subsanar los errores más graves de esta nueva versión del escritorio

Así que me congratula en presentar que el pasado martes 6 de mayo de 2025, ocho semanas después de liberar el código de Plasma 6.3 la Comunidad KDE presenta la quinta actualización de errores
- Estilo visual Brisa de Plasma (Kcursorgen): Se ha añadido el archivo de cabecera para QDebug. Código modificado.
- Estilo visual Brisa de Plasma: Se han añadido los archivos de cabecera que faltaban. Código modificado.
- Discover (página de la lista de aplicaciones): Se ha corregido el indicador «Seguimos buscando…». Código modificado, corrige el fallo #485379.
Más información: KDE
Las novedades generales de Plasma 6.3
Aprovecho para realizar un listado de las novedades generales de Plasma 6.3 novedades extraídas de 9to5linux.
- Posibilidad de clonar un panel.
- Posibilidad de establecer atajos de teclado para mover ventanas entre zonas de mosaicos de Custom Tiling en función de la direccionalidad.
- Soporte para recordar el escritorio virtual activo por actividad.
- Página renovada de la tableta gráfica en la configuración del sistema.
- Opción de preferir la precisión del color de la pantalla en KWin.
- Notificaciones de batería baja para auriculares inalámbricos que expongan adecuadamente la información de la batería.
- Nueva configuración el touchpad para que se desactive automáticamente al conectar un ratón.
- Mejor escalado fraccional para todos.
- Los widgets colocados en el escritorio sean ligeramente translúcidos.
- Asignación una contraseña aleatoria por defecto al punto de acceso a la red.
- Nuevo servicio para detectar y avisar a los usuarios con una notificación explicando lo que ocurre cuando el sistema se queda sin memoria y el kernel termina una aplicación.
- Plasma Discover ha sido actualizado para mostrar a los usuarios cuando las aplicaciones han sido empaquetadas directamente por su desarrollador o verificadas por un tercero de confianza.
- Mayor precisión el progreso de la instalación.

- Posibilidad de desactivar temporalmente las reglas de ventana de KWin en lugar de eliminarlas.
- Indicador de agrupación en el widget Administrador de tareas ahora sigue el color de acento actual.
- Los iconos simbólicos apropiados ahora serán sustituidos automáticamente por iconos de aplicaciones en el área de la bandeja del sistema.
- La aplicación Centro de información ahora mostrará todas tus GPUs y el recuento de ciclos de la batería de tu portátil.
- Posibilidad de intercambiar las funciones de los botones del lápiz de la tableta de dibujo.
- Se podrá mostrar la cola de impresión de cada impresora en línea y un spinner ocupado para cualquier impresora que esté imprimiendo en ese momento en el widget Impresoras.
- Se notificará a los usuarios en la pantalla de cierre de sesión cuando reinicien su sistema en el menú del gestor de arranque.
- Eliminado la categoría de menú «Configuración» del lanzador de aplicaciones Kickoff y todo su contenido se ha trasladado a la categoría «Sistema».
La entrada Quinta actualización de Plasma 6.3 se publicó primero en KDE Blog.
Wed, May 7th, 2025

Boletín de noticias de la Free Software Foundation Europe – mayo 2025
Recopilación de algunas de las noticias del boletín mensual de noticias relacionadas con el software libre publicado por la Free Software Foundation Europe

En 2001 la Free Software Foundation Europe (FSFE) fue establecida como una organización sin ánimo de lucro, registrada como asociación («e.V.») bajo la ley alemana. La FSFE es una organización benéfica que permite a los usuarios controlar la tecnología. El software está profundamente involucrado en todos los aspectos de nuestras vidas, por ello, es importante que esta tecnología nos capacite en lugar de que nos restrinja.
El software libre da a todo el mundo el derecho a usar, entender, adaptar y compartir el software. Estos derechos ayudan a respaldar otras libertades fundamentales como la libertad de expresión, prensa y privacidad.
De manera mensual la FSFE publica un boletín de noticias que está traducido al español por un grupo de personas que de manera voluntaria realizan esta labor de difusión de las noticias relacionadas con el software libre.
Este es un extracto de ese boletín mensual de mayo de 2025 al que te puedes suscribir o puedes consultar todos los boletines publicados en esta web:
Cita del mes
Una Ley de Mercados Digitales realmente efectiva provee a las compañías de Software Libre la oportunidad de irrumpir en los mercados que han estado dominados y restringidos por las grandes tecnológicas. Alentamos a las empresas de Software Libre para que aprovechen el impulso para relajarse y crear alternativas de Software Libre también en los dispositivos móviles
Lucas Lasota, Gestor de Programas Legales de la FSFE
Simposio ¿Dinero público? ¡Código Público! en la práctica: ¡la soberanía digital necesita Software libre!
El simposio de la FSFE sobre ¿Dinero Público? ¡Código Público! lo dejó claro: la adquisición e inversión en Software Libre (también conocido como Fuentes Abiertas u Open Source) son fundamentales para la innovación y la soberanía digital. El Software Libre es clave para reducir las dependencias de la administración pública. Estas administraciones, incluidos los municipios, tienen la oportunidad de avanzar en el control y manejabilidad de su infraestructura digital comprometiéndose con el Software Libre a largo plazo. Ha ha llegado el momento de tomar medidas, construir redes, reducir dependencias y establecer la soberanía digital a través del Software Libre.
Restricciones en nuestra libertad para estudiar el software: un caso de estudio legal desde Polonia
El software es un componente importante de la vida moderna, afectando en gran parte de nuestras vidas. Cuando el software está integrado en vehículos, la capacidad de control sobre nuestra tecnología digital se vuelve aún más importante en nombre de la seguridad pública. A pesar de esto, un caso judicial reciente en Polonia pone de relieve cómo la ley y los procedimientos legales pueden trabajar en contra de la misma.
Proyecto Refund4Freedom
Refund4Freedom es un Iniciativa italiana de la FSFE y la Sociedad Italiana de Linux (ILS) , que defiende el derecho de los consumidores a elegir su sistema operativo y a recibir un reembolso por el software preinstalado cuando compran un nuevo dispositivo. El proyecto se iniciará el 29 de mayo con una reunión a distancia por internet, abierto a cualquier entusiasta italiano, voluntario o promotor. Esta iniciativa ayudará a los italianos a reclamar su reembolso, ¡pero, por supuesto, si vives en otro país, puedes hacerlo también! El el proceso podría ser un poco diferente, así que si lo haces y tienes éxito, ¡comparte tu experiencia con nosotros!
Estas noticias son solo una recopilación, pero en la web podrás leer todas estas noticias y muchas más recopiladas por la FSFE y relacionadas con el software libre.