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

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.

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

We are aware that the time between Agama releases is usually too long. Recently, we committed to increase the frequency, although it means having smaller releases. You know, "release early, release often".

Agama 5 includes some changes we have been working on for some time, like a translated web interface or a software patterns selector. Additionally, it introduces a change in the storage area to not reuse pre-existing swap partitions. And last but not least, now you can boot Agama Live via PXE.

Translated web interface​

Until now, Agama web interface was only available in English. However, this new release allows you to select a different language and it is now available in another four languages: Dutch, Japanese, Spanish and Swedish. Kudos to Natasha Ament, Yasuhiko Kamata, Victor hck and Luna Jernberg for this first round of translations. Much appreciated!

If you are interested, please, consider helping with the translations. The openSUSE localization guide might be a good starting point. 😉

You can check the pull request #796 if you are interested in the technical details.

Bear in mind that selecting a different language does not affect the system you are installing. For that matter, we have started to work on a better "Localization" page that will allow selecting a language, a keyboard layout and a timezone for the system to install.

Patterns selection​

An important feature that we have been postponing for some time is customizing the software selection. We do not want to bring back complex and specific concepts, like system roles, so we decided to start with a prototype that shows the list of available software patterns.

Agama 5 ships a new software patterns selector, as shown in the screenshot below, although it is still a work in progress. However, it is even more important the discussion we have opened about this topic in the openSUSE Factory mailing list. Please do not hesitate to join if you have anything to say.

Technical details? You can find them in #792, #762, #770 and #772.

Do not reuse pre-existing swap partitions​

When proposing a storage layout, Agama reuses pre-existing swap partitions. This behavior was introduced in YaST just for backward compatibility with old versions and was inherited by Agama. However, we decided that Agama should stop doing this because it is confusing. Now, pre-existing swap partitions are not reused.

Check #806 for further details and screenshots.

Booting via PXE​

Since the earlier releases of Agama Live, it became clear that we needed a way to boot the installer using PXE. Recently, we started to build the images you need for that. The agama-live package contains some notes about how to grab them from openSUSE Build Service.

This feature relies on Kiwi, so it can be used by anyone who commits to create a real installation media based on Agama in the future. After all, Agama Live was built for demonstration purposes.

Other changes​

• Add a label in the storage section to indicate whether a Btrfs system will be transactional (#789).
• Set more restrictive permissions to the archive generated by the agama logs store command (#812).
• Update to Patternfly 5.1 (#800).

Trying Agama 5​

The best way to try Agama is to download one of the two variants (ALP or openSUSE) of the Agama Live devel ISO. This image is built in the systemsmanagement:Agama:Devel OBS project and is updated each time we release a new version.

Are you interested in the bleeding edge? The ISO in the systemsmanagement:Agama:Staging OBS project is for you because it is built automatically from the code on Agama's Git repository.

What's next​

Agama 6 is already under development and we expect to have another version ready by the end of November. For that release, we expect more changes in the internationalization area, support for the SUSE Customer Center and the possibility of selecting how to make space for your new system. Additionally, we are working on making it easier to tweak Agama's configuration.

We appreciate opinions and feedback. Feel free to contact the YaST team at the YaST Development mailing list, our #yast channel at Libera.chat or even the Agama project at GitHub.

Stay tunned!

We are aware that the time between Agama releases is usually too long. Recently, we committed to increase the frequency, although it means having smaller releases. You know, “release early, release often”.

Agama 5 includes some changes we have been working on for some time, like a translated web interface or a software patterns selector. Additionally, it introduces a change in the storage area to not reuse pre-existing swap partitions. And last but not least, now you can boot Agama Live via PXE.

Translated web interface

Until now, Agama web interface was only available in English. However, this new release allows you to select a different language and it is now available in another four languages: Dutch, Japanese, Spanish and Swedish. Kudos to Natasha Ament, Yasuhiko Kamata, Victor hck and Luna Jernberg for this first round of translations. Much appreciated!

If you are interested, please, consider helping with the translations. The openSUSE localization guide might be a good starting point. :wink:

You can check the pull request #796 if you are interested in the technical details.

Bear in mind that selecting a different language does not affect the system you are installing. For that matter, we have started to work on a better “Localization” page that will allow selecting a language, a keyboard layout and a timezone for the system to install.

Patterns selection

An important feature that we have been postponing for some time is customizing the software selection. We do not want to bring back complex and specific concepts, like system roles, so we decided to start with a prototype that shows the list of available software patterns.

Agama 5 ships a new software patterns selector, as shown in the screenshot below, although it is still a work in progress. However, it is even more important the discussion we have opened about this topic in the openSUSE Factory mailing list. Please do not hesitate to join if you have anything to say.

Technical details? You can find them in #792, #762, #770 and #772.

Do not reuse pre-existing swap partitions

When proposing a storage layout, Agama reuses pre-existing swap partitions. This behavior was introduced in YaST just for backward compatibility with old versions and was inherited by Agama. However, we decided that Agama should stop doing this because it is confusing. Now, pre-existing swap partitions are not reused.

Check #806 for further details and screenshots.

Booting via PXE

Since the earlier releases of Agama Live, it became clear that we needed a way to boot the installer using PXE. Recently, we started to build the images you need for that. The agama-live package contains some notes about how to grab them from openSUSE Build Service.

This feature relies on Kiwi, so it can be used by anyone who commits to create a real installation media based on Agama in the future. After all, Agama Live was built for demonstration purposes.

Other changes

• Add a label in the storage section to indicate whether a Btrfs system will be transactional (#789).
• Set more restrictive permissions to the archive generated by the agama logs store command (#812).
• Update to Patternfly 5.1 (#800).

Trying Agama 5

The best way to try Agama is to download one of the two variants (ALP or openSUSE) of the Agama Live devel ISO. This image is built in the systemsmanagement:Agama:Devel OBS project and is updated each time we release a new version.

Are you interested in the bleeding edge? The ISO in the systemsmanagement:Agama:Staging OBS project is for you because it is built automatically from the code on Agama’s Git repository.

What’s next

Agama 6 is already under development and we expect to have another version ready by the end of November. For that release, we expect more changes in the internationalization area, support for the SUSE Customer Center and the possibility of selecting how to make space for your new system. Additionally, we are working on making it easier to tweak Agama’s configuration.

We appreciate opinions and feedback. Feel free to contact the YaST team at the YaST Development mailing list, our #yast channel at Libera.chat or even the Agama project at GitHub.

Stay tunned!