BookStack has recently released version 23.10.1 of their software. This update brings several fixes and changes to improve the user experience.

One notable addition is the inclusion of “Norwegian Nynorsk” as a language option for users. This expands the accessibility of BookStack to a wider range of users who speak this language.

Another improvement is the addition of a JavaScript public event for customizing codemirror instances. This feature allows users to have more control over their coding experience within BookStack.

Additionally, the update includes handling that allows users to jump to headers and sections within collapsible sections. This enhances the navigation experience within the software and makes it easier for users to find the information they need.

BookStack v23.10.1 also introduces support for PHP 8.3, ensuring compatibility with a newer version of PHP.

Several fixes have also been implemented in this release. The header bar no longer peeks through on the markdown editor’s fullscreen mode, providing a seamless writing experience. Additionally, the incorrect color usage for editor toolbox active tabs has been fixed, improving the visual consistency of the software.

The Incus team has announced the release of Incus 0.4, the latest version of their system container and virtual machine manager. This release is particularly significant as it marks the last release of Incus to feature changes coming from LXD, as Incus has now become fully independent.

Incus 0.4 introduces several exciting new features, including a built-in keep-alive mode in the client tool, improvements to certificate/trust store management, new OVN configuration keys, and the ability to directly create CephFS filesystems. Additionally, Incus 0.4 brings significant improvements to both OpenFGA and OVN handling, setting the infrastructure in place for upcoming new features.

One of the standout features of Incus 0.4 is the new keep-alive support in the CLI client. Users can set a keepalive configuration key on a remote in ~/.config/incus/config.yml, defining how long to keep a background connection with the Incus server. This feature significantly reduces latency and provides up to a 30% performance improvement for use cases that involve a lot of incus commands, such as Ansible.

Another notable addition in Incus 0.4 is the description field for certificate entries. This brings certificate entries in line with other Incus objects and enhances the overall user experience.

The incus config trust list command has also been reworked in this release to show more useful columns by default, including the description column. These columns are now configurable, providing users with more control over their configurations.

In terms of infrastructure improvements, Incus 0.4 introduces OVN SSL keys as server configuration. This allows users to specify SSL certificates and keys to access OVN, taking precedence over any keys found in /etc/ovn/.

Additionally, CephFS filesystems can now be directly created in Incus. Users can set the cephfs.create_missing config key to true and specify the OSD pool to consume, allowing Incus to create a new CephFS filesystem.

Users of LXD are also advised that access to the community image server (images: remote) will be phased out over a period of around 5 months. It is recommended that LXD users running non-Ubuntu images start planning their migration to Incus.

For more details on this release, including the complete changelog, documentation, and available packages, please visit the Incus website.

K3s has released version v1.29.0+k3s1, an update to its lightweight, highly available Kubernetes distribution. This release includes several important changes and updates, including an upgrade to Kubernetes v1.29.0. However, before upgrading, users are advised to read the Urgent Upgrade Notes from Kubernetes.

There are two important changes to note in this release. The first is the removal of the experimental rotate-keys subcommand, due to changes in Kubernetes upstream for KMSv2. This subcommand may be added back in future releases. The second change is the removal of the multi-cluster-cidr flag, as support for this alpha feature has been completely removed from Kubernetes upstream.

Other notable changes in this release include fixing an overlapping address range, updating the stable channel to November 2023, adding runtime classes for wasm/nvidia/crun, and bumping containerd/runc to v1.7.10-k3s1/v1.1.10. Additionally, there are updates to containerd, removal of GA feature-gates, improvements to code coverage, and an update to flannel.

Embedded component versions in this release include Kubernetes v1.29.0, Kine v0.11.0, SQLite 3.42.0, Etcd v3.5.9-k3s1, Containerd v1.7.11-k3s2, Runc v1.1.10, Flannel v0.24.0, Metrics-server v0.6.3, Traefik v2.10.5, CoreDNS v1.10.1, Helm-controller v0.15.4, and Local-path-provisioner v0.0.24.

In a significant development for the PostgreSQL database server, incremental backup support has been successfully implemented and merged into the latest version, PostgreSQL 17. Spearheaded by Robert Haas, the implementation comprises three key components. Firstly, a background process named the walsummarizer continuously reads the Write-Ahead Log (WAL) to generate small WAL summary files containing vital information for determining which parts of the database require backing up. Secondly, the pg_basebackup tool now features an incremental backup mode, necessitating a backup manifest from a prior full backup. It reads WAL summary files between the previous full backup and the incremental backup to identify changed relation files. Lastly, a new utility, pg_combinebackup, validates and combines a full backup with one or more incremental backups to create a synthetic full backup or data directory.

To execute an incremental backup, users can leverage the new replication command UPLOAD_MANIFEST to upload the manifest for the prior backup, which could be a full backup or another incremental backup. The BASE_BACKUP command with the INCREMENTAL option is then employed to take the backup, and the pg_basebackup tool includes an --incremental=PATH_TO_MANIFEST option to trigger this behavior. Incremental backup files closely resemble regular full backups, but some relation files are replaced with those having names like INCREMENTAL.${ORIGINAL_NAME}. The backup_label file is also modified to indicate its status as an incremental backup. This feature is anticipated to be available in PostgreSQL 17, slated for release in September, promising an array of exciting changes for users of the database server.

Source: Phoronix.

Gitea has announced the release of version 1.21.3. This update includes 18 merged pull requests and fixes for a security vulnerability. Users are strongly encouraged to update to this version for important bug fixes.

One notable improvement in this release is that it is built with the latest released version of Golang to resolve the announced CVE with Golang. The specific CVE addressed is CVE-2023-48795.

The problem that was fixed in this release was contributed by @wxiaoguang.

For those interested in updating to Gitea 1.21.3, the software can be downloaded from the downloads page. The installation guide provides more information on how to install the update.

For a full list of changes in Gitea 1.21.3, refer to the Changelog.

openSUSE Tumbleweed and MicroOS have made some significant changes to their boot loader and full disk encryption (FDE) capabilities. The new image now uses systemd-boot as the boot loader and implements full disk encryption based on systemd. This update aims to improve the security of the distribution while simplifying the design.

systemd-boot

The previous boot loader used by openSUSE, GRUB2, is feature-rich but complex and slow to develop. The openSUSE package for GRUB2 contains over 200 patches, some of which have been present for many years. While GRUB2 supports various systems and file systems, the introduction of UEFI made many of its features redundant, as the system firmware already provided similar functionalities.

As a result, more straightforward boot loaders focused on UEFI, such as gummiboot, emerged. Eventually, this code was integrated into systemd and renamed systemd-boot. Compared to GRUB2, systemd-boot is much simpler and serves as a small EFI binary that presents a menu with different boot loader entries and delegates the execution to the selected kernel.

systemd-boot can also work with unified kernel images (UKI) that aggregate the kernel, command line, and initrd into a single unit. openSUSE plans to support UKIs in the future.

openSUSE has been planning to provide systemd-boot as an alternative to GRUB2 for some time, and in August 2023, Tumbleweed started supporting systemd-boot. The yast-bootloader tool also gained support for systemd-boot for new installations.

While supporting another boot loader comes with challenges, such as decreased support for different architectures and compatibility issues with btrfs file systems, openSUSE is actively working on addressing these problems.

Full Disk Encryption

openSUSE has also introduced support for full disk encryption based on systemd. While GRUB2 already supported unlocking LUKS volumes, systemd offers some additional features, such as partial support for LUKS2 encryption and integration with TPM2 devices.

The TPM2 (Trusted Platform Module 2) is a cryptographic device that can unlock secrets only when certain conditions related to the system’s state are met. The TPM2 will unlock the secret if the system is in a known good state, ensuring that the firmware, boot loader, kernel, and initrd have not been tampered with.

To take advantage of TPM2 for FDE, openSUSE has developed a policy that instructs the TPM2 to decrypt a secret only if certain platform configuration registers (PCR) contain the expected values. The PCR values are measured during the boot process, and any changes to the system will result in different PCR values, preventing the secret from being decrypted.

openSUSE has also improved the prediction of PCR values using the pcr-oracle tool, which can encrypt a key under a set of PCR values that can change. This allows for flexible unlocking mechanisms and better system integrity checks.

Using systemd for Disk Encryption

While GRUB2 is still functional for FDE, the use of systemd-boot provides an alternative architecture that works with any boot loader that follows the Boot Loader Specification (BLS). With systemd-boot, the kernel and initrd are placed in the unencrypted EFI system partition (ESP), and the unlock of the sysroot (where the system is located) is done from inside the initrd using systemd-cryptsetup options.

To support this new architecture, openSUSE provides a MicroOS image named kvm-and-xen-sdboot that showcases the new FDE capabilities. This image includes systemd-boot, sdbootutil scripts for synchronizing boot entries, pcr-oracle for predicting PCR values, disk-encryption-tool for encrypting the sysroot device, and dracut-pcr-signature, a dracut module that loads predictions into the initrd from the ESP.

The tools work together to ensure a secure and seamless boot process. The VM with a virtual TPM2 device measures the executed code and data, extending the PCR values. systemd-boot then reads the correct boot entry, and the disk-encryption-tool script encrypts the sysroot device. Finally, the jeos-firstboot modules handle the enrollment of FIDO2 keys and provide recovery key information.

Future Improvements

While the current implementation is a sound proof of concept, there are several areas for improvement. The disk-encryption-tool should be integrated into the installer, and the jeos-firstboot modules should also live in the installer or be merged with the functionality provided by the encryption tool. Separating system keys from user keys and enabling the use of TPM2 and FIDO2 keys simultaneously are also potential improvements.

Additionally, openSUSE aims to work with upstream projects, such as systemd and GRUB2, to incorporate the current tools and features. The diagnosis of TPM2 rejection for unlocking the LUKS2 key could be improved, and the integration of multiple encrypted disks should be validated and enhanced.

Ultimately, openSUSE is considering the use of unified kernel images and further standardization to simplify the architecture. The generation and registration of new keys, as well as the selection of PCR values, may be automated or better documented to streamline the process.