Fri, Jan 26th, 2024

openSUSE Tumbleweed Monthly Update - January

Welcome to the monthly update for openSUSE Tumbleweed for January 2024. This will be the new format going forward as recommended by those contributing to the marketing efforts of openSUSE. These updates will highlight major changes, improvements and key issues addressed in openSUSE Tumbleweed snapshots throughout the month. The aim is to keep the community and users informed about the developments and updates of the distribution. Should readers desire a more frequent amount of information about openSUSE Tumbleweed snapshots, readers are advised to subscribe to the openSUSE Factory mailing list.

New Features and Enhancements

  • Linux Kernel: Updates to versions 6.6.7, 6.6.9, 6.6.10, 6.6.11 and 6.7.1.
    • Fixes have been applied for memory management and security vulnerabilities, enhancing overall system safety.
    • Support for new hardware models
      • PCI: Adds ACS quirks for more Zhaoxin Root Ports, enhancing compatibility and performance for Zhaoxin’s CPUs and motherboards.
      • ALSA (Advanced Linux Sound Architecture): Added driver properties for cs35l41 for Lenovo Legion Slim 7 Gen 8 series, and introduced support for additional Dell models without _DSD, along with fixes for HP Envy X360 13-ay0xxx’s mute and mic-mute LEDs, indicating broader compatibility for sound hardware in laptops.
      • LEDs: The ledtrig-tty module receives updates to the free allocated ttyname buffer on deactivation, impacting how LED triggers are handled for terminal activities.
  • Mozilla Firefox: Updates to version 121.0 and 121.0.1
    • The update resolves a bug that caused Firefox to hang when loading sites with column-based layouts, enhancing stability and performance.
    • Fixes applied to ensure rounded corners for videos and proper closure of Firefox that prevents USB security key conflicts with other applications.
  • KDE Frameworks: Update for version 5.114.0.
    • Significant updates include fixes in Extra CMake Modules, introduction of holidays in Kenya observed by KHolidays, and quality settings adjustments for AVIF in KImageFormats.
    • Key improvements in KIO for handling malformed Exec entries, accessibility enhancements in Kirigami, and stability fixes in KJobWidgets to prevent potential use-after-free errors.
  • Mesa: Updates to 23.3.3
    • Focus on Python 3.6 build fixes and enhancements in driver support.
    • The release introduces NVK, a new Vulkan driver for NVIDIA hardware, which marks a step forward in support for NVIDIA GPUs, yet it remains in the experimental phase.
    • Improved graphics performance and compatibility Asahi and RADV and enhancements of OpenGL ES and Vulkan capabilities
    • Introduces critical updates like the requirement of libvulkan1 for Mesa-dri to support zink/swrast driver fallbacks, which further improves the overall user experience with graphics applications and games.
  • systemd: Updates to version 254.8
    • Reverts patches related to udev device node updates and workarounds for issues. Took a cautious approach to fixing reported bugs and ensuring stability in device management systems.
    • Adjustments to udev ensure the proper existence and ownership of %_modulesloaddir, facilitating smoother module installation by other packages, thereby improving system configuration and module management.
  • PHP: Updated from version 8.2.14 to 8.2.15,
    • Fix for a false positive SSA integrity verification failure and a resolution for Autoconf warnings during cross-compilation.
    • The CLI built-in web server now correctly handles timeouts when using router scripts in conjunction with max_input_time.
    • Fixes a crash when using stream_wrapper_register with FFI\CData and interaction issues between FFI::new and observers.
    • IntlDateFormatter now correctly accepts ‘C’ as a valid locale.
    • A hanging issue in the Hash extension for large strings with sha512 is resolved.
  • GStreamer: Updates to version 1.22.8
    • Addressing vulnerabilities within the AV1 video codec parser.
    • Fixes include resolving a potential deadlock in the avdec video decoder with FFmpeg 6.1
    • Improvements in reverse playback and seeking in qtdemux for files with raw audio streams
    • Enhancements to the GstPlay and GstPlayer libraries
    • Updates to the Cerbero build tool to address python 3.12 string escape warnings
  • Samba : Updates to version 4.19.4
    • Addresses issues like the inability of net changesecretpw to set the machine account password with an empty secrets.tdb,
    • Improves documentation generation with respect to XML_CATALOG_FILES environment variable.
    • Resolved issues where smbd did not detect ctdb public IPv6 addresses for multichannel exclusion, and the force user = localunixuser setting was ineffective when allow trusted domains = no.
    • Addressed critical vulnerabilities and bugs, such as visible Deleted Object tombstones in AD LDAP to normal users CVE-2018-14628, and various smbget authentication and functionality fixes, enhancing security and user experience.

Security Updates

This month’s updates include critical security patches across various packages. Notable security improvements were integrated into the Firefox, systemd, Samba and PHP updates and more.

Bug Fixes

Contributing to openSUSE Tumbleweed

Your contributions and feedback make openSUSE Tumbleweed better with every update. Whether reporting bugs, suggesting features, or participating in community discussions, your involvement is highly valued.

Conclusion

We will continue to refine and enhance this format. We look forward to another exciting year of development and community engagement with openSUSE Tumbleweed. See you all at FOSDEM next week. Happy computing!

Thu, Jan 25th, 2024

Testing kernels with sporadic issues until heisenbug shows in openQA

This is a follow up to my previous post about How to test things with openQA without running your own instance, so you might want to read that first.

Now, while hunting for bsc#1219073 which is quite sporadic, and took quite some time to show up often enough so that became noticeable and traceable, once stars aligned and managed to find a way to get a higher failure rate, I wanted to have a way for me and for the developer to test the kernel with the different patches to help with the bisecting and ease the process of finding the culprit and finding a solution for it.

I came with a fairly simple solution, using the --repeat parameter of the openqa-cli tool, and a simple shell script to run it:

```bash
$ cat ~/Downloads/trigger-kernel-openqa-mdadm.sh
# the kernel repo must be the one without https; tests don't have the kernel CA installed
KERNEL="KOTD_REPO=http://download.opensuse.org/repositories/Kernel:/linux-next/standard/"

REPEAT="--repeat 100" # using 100 by default
JOBS="https://openqa.your.instan.ce/tests/13311283 https://openqa.your.instan.ce/tests/13311263 https://openqa.your.instan.ce/tests/13311276 https://openqa.your.instan.ce/tests/13311278"
BUILD="bsc1219073"
for JOB in $JOBS; do 
	openqa-clone-job --within-instance $JOB CASEDIR=https://github.com/foursixnine/os-autoinst-distri-opensuse.git#tellmewhy ${REPEAT} \
		_GROUP=DEVELOPERS ${KERNEL} BUILD=${BUILD} FORCE_SERIAL_TERMINAL=1\
		TEST="${BUILD}_checkmdadm" YAML_SCHEDULE=schedule/qam/QR/15-SP5/textmode/textmode-skip-registration-extra.yaml INSTALLONLY=0 DESKTOP=textmode\
		|& tee jobs-launched.list;
done;

There are few things to note here:

  • the kernel repo must be the one without https; tests don’t have the CA installed by default.
  • the --repeat parameter is set to 100 by default, but can be changed to whatever number is desired.
  • the JOBS variable contains the list of jobs to clone and run, having all supported architecures is recommended (at least for this case)
  • the BUILD variable can be anything, but it’s recommended to use the bug number or something that makes sense.
  • the TEST variable is used to set the name of the test as it will show in the test overview page, you can use TEST+=foo if you want to append text instead of overriding it, the --repeat parameter, will append a number incrementally to your test, see os-autoinst/openQA#5331 for more details.
  • the YAML_SCHEDULE variable is used to set the yaml schedule to use, there are other ways to modify the schedule, but in this case I want to perform a full installation

Running the script

  • Ensure you can run at least the openQA client; if you need API keys, see post linked at the beginning of this post
  • replace the kernel repo with your branch in line 5
  • run the script $ bash trigger-kernel-openqa-mdadm.sh and you should get the following, times the --repeat if you modified it
1 job has been created:
 - sle-15-SP5-Full-QR-x86_64-Build134.5-skip_registration+workaround_modules@64bit -> https://openqa.your.instan.ce/tests/13345270

Each URL, will be a job triggered in openQA, depending on the load and amount of jobs, you might need to wait quite a bit (some users can help moving the priority of these jobs so it executes faster)

The review stuff:

Looking at the results

  • Go to https://openqa.your.instan.ce/tests/overview?distri=sle&build=bsc1219073&version=15-SP5 or from any job from the list above click on Job groups menu at the top, and select Build bsc1219073
  • Click on “Filter”
  • type the name of the test module to filter in the field Module name, e.g mdadm, and select the desired result of such test module e.g failed (you can also type, and select multiple result types)
  • Click Apply
  • The overall summary of the build overview page, will provide you with enough information to calculate the pass/fail rate.

A rule of thumb: anything above 5% is bad, but you need to also understand your sample size + the setup you’re using; YMMV.

Ain’t nobody got time to wait

The script will generate a file called: jobs-launched.list, in case you absolutely need to change the priority of the jobs, set it to 45, so it runs higher than default priority, which is 50 cat jobs-launched.list | grep https | sed -E 's/^.*->\s.*tests\///' | xargs -r -I {} bash -c "openqa-cli api --osd -X POST jobs/{}/prio prio=45; sleep 1"

The magic

The actual magic is in the schedule, so right after booting the system and setting it up, before running the mdadm test, I inserted the update_kernel module, which will add the kernel repo specified by KOTD_REPO, and install the kernel from there, reboot the system, and leave the system ready for the actual test, however I had to add very small changes:

---
 tests/kernel/update_kernel.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/kernel/update_kernel.pm b/tests/kernel/update_kernel.pm
index 1d6312bee0dc..048da593f68f 100644
--- a/tests/kernel/update_kernel.pm
+++ b/tests/kernel/update_kernel.pm
@@ -398,7 +398,7 @@ sub boot_to_console {
 sub run {
     my $self = shift;
 
-    if ((is_ipmi && get_var('LTP_BAREMETAL')) || is_transactional) {
+    if ((is_ipmi && get_var('LTP_BAREMETAL')) || is_transactional || get_var('FORCE_SERIAL_TERMINAL')) {
         # System is already booted after installation, just switch terminal
         select_serial_terminal;
     } else {
@@ -476,7 +476,7 @@ sub run {
         reboot_on_changes;
     } elsif (!get_var('KGRAFT')) {
         power_action('reboot', textmode => 1);
-        $self->wait_boot if get_var('LTP_BAREMETAL');
+        $self->wait_boot if (get_var('FORCE_SERIAL_TERMINAL') || get_var('LTP_BAREMETAL'));
     }
 }
 

Likely I’ll make a new pull request to have this in the test distribution, but for now this is good enough to help kernel developers to do some self-service and trigger their own openQA tests, that have many more tests (hopefully in parallel) and faster than if there was a person doing all of this manually.

Special thanks to the QE Kernel team, who do the amazing job of thinking of some scenarios like this, because they save a lot of time.

Revamping the Request Build Status Page and Introducing the Dark Mode

The beginning of the year has started strong in OBS. We are glad to be back to you in a new year with a blog post full of interesting updates, most of them improving our Request page. Take a seat, a fresh breath, and enjoy! We started the redesign of the request workflow in August 2022. Then, in September 2022, we focused on the support of multi-action submit requests. We continued in October 2022 with...

Tue, Jan 23rd, 2024

Native MacOS source in syslog-ng

You know that support for MacOS is important when every third visitor at the syslog-ng booth of Red Hat Summit asks if syslog-ng works on MacOS. With the upcoming syslog-ng version 4.6.0, syslog-ng not only compiles on MacOS, but it also collects local log messages natively. From this blog you can learn how to compile syslog-ng yourself, options of the MacOS source, and also a bit of history.

https://www.syslog-ng.com/community/b/blog/posts/native-macos-source-in-syslog-ng

syslog-ng logo

The syslog-ng Insider 2024-01: HTTP; Cloudflare; systemd-journal; Humio / Logscale;

The January syslog-ng newsletter is now on-line:

  • Why use a http()-based destination in syslog-ng?
  • An overview of Cloudflare’s logging pipeline
  • Working with multiple systemd-journal namespaces in syslog-ng
  • Logging to Humio / Logscale simplified in syslog-ng

It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2024-01-http-cloudflare-systemd-journal-humio-logscale

syslog-ng logo

Call for Hosts Begins for openSUSE Conference

The openSUSE Project is asking interested people to submit a call for hosts for the openSUSE Conference 2025.

This event is a cornerstone of the openSUSE community and aims to bring together a diverse group of users, developers and enthusiasts to share, learn and collaborate. The aim is not only to strengthen the existing community but also to welcome new members into the fold.

Having the conference in different locations allows the project to be more accessible to people and can help with increasing awareness about the openSUSE Project and open source. While the project is unable to commit to a host being selected based on the project’s available funds, participants in the community encourage people/groups to provide a submission. This will let members of the community discover areas where the project can have a conference if funding allows it.

What We Are Looking For

Hosting the openSUSE Conference is an opportunity to showcase your community and city. The project seeks passionate teams who can address the following key criteria in their submissions:

  • New Attendees: Strategies to attract and engage new participants.
  • Accessibility: Ensuring the venue and events are accessible to all.
  • Community Involvement: Hosts must attend community meetings and provide regular updates if selected.
  • Cost Efficiency: Detailed budget plan showing the total cost to run the event.
  • Community Growth Goal: A plan to make the conference as successful as previous ones in gaining new members.
  • Engaging Educational Institutions: Technical universities and educational bodies willing to host an openSUSE Conference is an ideal demographic for a submission.
  • Bidding Process: Similar to the Debian Conference Bidding Process proposals will be submitted via openSUSE Wiki pages. There is a potential that it can be followed by a community voting process.
  • Submission Period: Please refer to the openSUSE Conference wiki for detailed timeline and submission deadline.
  • Season Flexibility: The event can be planned for any season, allowing flexibility for the hosts.

How to Submit Your Proposal

  • Prepare Your Proposal: Detailing how you’ll address the above criteria.
  • Submit on openSUSE Wiki: Create a dedicated page for your bid on the openSUSE Wiki and use the template provided at en.opensuse.org/openSUSE:Call_for_hosts to assist with developing the proposal.
  • Community Voting: The final selection will involve a voting process by the openSUSE community.

Why Host the openSUSE Conference?

Hosting the openSUSE Conference can spotlight your local community. It’s an opportunity to contribute to the growth of the project.

More Information and Submission Guidelines

Visit the conference checklist for more information on guidelines to help host an openSUSE Conference.

The

The openSUSE Project is asking interested people to submit a call for hosts for the openSUSE Conference 2025.

This event is a cornerstone of the openSUSE community and aims to bring together a diverse group of users, developers and enthusiasts to share, learn and collaborate. The aim is not only to strengthen the existing community but also to welcome new members into the fold.

Having the conference in different locations allows the project to be more accessible to people and can help with increasing awareness about the openSUSE Project and open source. While the project is unable to commit to a host being selected based on the project’s available funds, participants in the community encourage people/groups to provide a submission. This will let members of the community discover areas where the project can have a conference if funding allows it.

What We Are Looking For

Hosting the openSUSE Conference is an opportunity to showcase your community and city. The project seeks passionate teams who can address the following key criteria in their submissions:

  • New Attendees: Strategies to attract and engage new participants.
  • Accessibility: Ensuring the venue and events are accessible to all.
  • Community Involvement: Hosts must attend community meetings and provide regular updates if selected.
  • Cost Efficiency: Detailed budget plan showing the total cost to run the event.
  • Community Growth Goal: A plan to make the conference as successful as previous ones in gaining new members.
  • Engaging Educational Institutions: Technical universities and educational bodies willing to host an openSUSE Conference is an ideal demographic for a submission.
  • Bidding Process: Similar to the Debian Conference Bidding Process proposals will be submitted via openSUSE Wiki pages. There is a potential that it can be followed by a community voting process.
  • Submission Period: Please refer to the openSUSE Conference wiki for detailed timeline and submission deadline.
  • Season Flexibility: The event can be planned for any season, allowing flexibility for the hosts.

How to Submit Your Proposal

  • Prepare Your Proposal: Detailing how you’ll address the above criteria.
  • Submit on openSUSE Wiki: Create a dedicated page for your bid on the openSUSE Wiki and use the template provided at en.opensuse.org/openSUSE:Call_for_hosts to assist with developing the proposal.
  • Community Voting: The final selection will involve a voting process by the openSUSE community.

Why Host the openSUSE Conference?

Hosting the openSUSE Conference can spotlight your local community. It’s an opportunity to contribute to the growth of the project.

More Information and Submission Guidelines

Visit the conference checklist for more information on guidelines to help host an openSUSE Conference.

The [openSUSE Project(https://www.

The [openSUSE Project(https://www.opensuse.org/) is asking interested people to submit a call for hosts for the openSUSE Conference 2025. This event is a cornerstone of the openSUSE community and aims to bring together a diverse group of users, developers and enthusiasts to share, learn and collaborate. The aim is not only to strengthen the existing community but also to welcome new members into the fold.

Having the conference in different locations allows the project to be more accessible to people and can help with increasing awareness about the openSUSE Project and open source. While the project is unable to commit to a host being selected based on the project’s available funds, participants in the community encourage people/groups to provide a submission. This will let members of the community discover areas where the project can have a conference if funding allows it.

What We Are Looking For

Hosting the openSUSE Conference is an opportunity to showcase your community and city. The project seeks passionate teams who can address the following key criteria in their submissions:

  • New Attendees: Strategies to attract and engage new participants.
  • Accessibility: Ensuring the venue and events are accessible to all.
  • Community Involvement: Hosts must attend community meetings and provide regular updates if selected.
  • Cost Efficiency: Detailed budget plan showing the total cost to run the event.
  • Community Growth Goal: A plan to make the conference as successful as previous ones in gaining new members.
  • Engaging Educational Institutions: Technical universities and educational bodies willing to host an openSUSE Conference is an ideal demographic for a submission.
  • Bidding Process: Similar to the Debian Conference Bidding Process proposals will be submitted via openSUSE Wiki pages. There is a potential that it can be followed by a community voting process.
  • Submission Period: Please refer to the openSUSE Conference wiki for detailed timeline and submission deadline.
  • Season Flexibility: The event can be planned for any season, allowing flexibility for the hosts.

How to Submit Your Proposal

  • Prepare Your Proposal: Detailing how you’ll address the above criteria.
  • Submit on openSUSE Wiki: Create a dedicated page for your bid on the openSUSE Wiki and use the template provided at en.opensuse.org/openSUSE:Call_for_hosts to assist with developing the proposal.
  • Community Voting: The final selection will involve a voting process by the openSUSE community.

Why Host the openSUSE Conference?

Hosting the openSUSE Conference can spotlight your local community. It’s an opportunity to contribute to the growth of the project.

More Information and Submission Guidelines

Visit the conference checklist for more information on guidelines to help host an openSUSE Conference.

Mon, Jan 22nd, 2024

darkhttpd: timing attack and local leak of HTTP basic auth credentials

This report deals with HTTP basic auth issues in the darkhttpd project. Darkhttpd is a minimal HTTP web server implemented in the C programming language, for serving static files. The version under review was 1.14.

A version 1.15 bugfix release containing a bugfix and an additional warning message is available.

Basic Auth Timing Attack (CVE-2024-23771)

The issue is found in darkhttpd.c line 2272. Here the HTTP basic authentication string supplied by a client is compared against the secret configured via the --auth command line parameter. For this comparison a regular strcmp() function call is used.

Since strcmp() performs an efficient linear comparison, it will terminate earlier if the first bytes of the supplied authentication string don’t match compared to if they do match. This difference in runtime can be used for timing attacks to try and find out the correct authentication credentials to access the web server.

To fix this, a constant-time string comparison function needs to be used that always takes the same amount of computation time for the comparison independently of how many bytes of the provided data match the actual authentication secret. An example for such a function is the CRYPTO_memcmp() function provided by the openSSL library.

Darkhttp does not support SSL encrypted traffic by itself. When darkhttpd is used for unencrypted http:// over the Internet then it could be argued that the authentication data will be sent unencrypted over an untrusted channel anyway. If darkhttpd is used behind a reverse proxy that uses SSL and thus uses a secure channel, then a major security property will be violated by this issue though.

Bugfix

After discussing the available options with him, the upstream author decided to implement a custom constant-time string comparison algorithm to address the issue. This algorithm is a rather simple xor operation over the complete range of bytes.

Local Leak of Authentication Parameter in Process List (CVE-2024-23770)

The only way to configure the HTTP basic auth string in darkhttpd is to pass it via the --auth command line parameter. On Linux all local users can view the parameters of other programs running on the system. This means if there are other users or programs running in different security domains, then these can obtain the authentication credentials for the web server.

To fix this an alternative mechanism needs to be provided to pass the authentication credentials in a safe way. Typically this can be solved by using an environment variable or a protected configuration file. If the existing --auth command line switch is kept around, then the fact that this leaks the authentication credentials on Linux systems should be documented.

Bugfix

The upstream author decided to only document the security implications by adding a warning to the command line usage output.

Review Summary

Apart from these HTTP basic authentication related issues, I have not found any problematic spots in the code base of darkhttpd. I focused on the potential for log file spoofing, escaping the web root via crafted URLs and memory corruption, e.g. through specifying bad byte ranges in HTTP headers. The code is robust in these areas.

Timeline

2024-01-12 I reported the findings to the upstream author emikulic@gmail.com, offering coordinated disclosure.
2024-01-13 The author confirmed the security issues but declined a formal embargo period.
2024-01-15 I requested two CVEs from Mitre to track the two findings found during the review.
2024-01-18 After some discussions about the bugfixes, the author published the new version 1.15 containing the changes.
2024-01-25 Mitre assigned the CVEs.

References

Fri, Jan 19th, 2024

openSUSE Tumbleweed – Review of the week 2024/03

Dear Tumbleweed users and hackers,

As we can see in the number of larger and smaller things going through the staging process, the holiday season is over. To get all the changes out to the users, we have published six snapshots (0112, 0114…0118) this week.

The main changes delivered were:

  • Linux kernel 6.6.11
  • Pipewire 1.0.1
  • Samba 4.19.4
  • Mozilla Firefox 121.0.1
  • Systemd 254.8
  • KDE Frameworks 5.114.0
  • ffmpeg 6.1.1
  • Bash 5.2.26
  • elfutils 0.190
  • gnutls 3.8.3
  • Wine 9.0

The staging projects currently show the community working on these changes:

  • RPM 4.19.1: getting closer to be ready. packagers: please ensure to read/understand Ana’s announcement at https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/HG2JKUIKDTWQQIQSA43A4VWHX7YKJQT3/
  • rpm-config-SUSE: enable full ksym() dependencies in Tumbleweed
  • Mesa 23.3.3
  • Linux Kernel 6.7
  • QEmu 8.2.0
  • dbus-broker: a big step forward; upgrades seem to be an issue that need to be addressed
  • Ruby 3.3: all buld fails have been fixed/have a fix submitted. QA should happen next week.
  • libxml 2.12.x: slow progress
  • openSSL 3.2.0
  • c-ares 1.21.0: nodejs build fails have been resolved, but a new cycle has formed: appstream-glib, c-ares, curl, googletest, nghttp2, python311