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
withFFI\CData
and interaction issues betweenFFI::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 emptysecrets.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 theforce user = localunixuser
setting was ineffective whenallow 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.
- Addresses issues like the inability of
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
- xorg-x11-server 21.1.11 and xwayland 23.2.4: These updates addressed multiple CVEs, improving security and stability in the display server protocols. A list of this CVEs can be found in the security advisory.
- gnutls 3.8.3: CVE-2024-0553 was a vulnerability that allows timing attacks in RSA-PSK, risking data leak and a fix for CVE-2024-0567 was made, which is a flaw in cockpit’s certificate validation that enables remote denial of service attacks.
- java-11-openjdk 11.0.22.0: Multiple CVEs. CVE-2024-20919, CVE-2024-20926 , CVE-2024-20921, CVE-2024-20918, CVE-2024-20945, CVE-2024-20952
- samba 4.19.4: CVE-2018-14628 an authenticated but unprivileged attacker could have discovered the names and preserved attributes of deleted objects in the LDAP store.
- python-Jinja2 3.1.3: CVE-2024-22195 was a flaw where the xmlattr filter improperly allows space-containing keys, enabling attackers to inject harmful attributes through user inputs.
- rdma-core 49.1: Although specific CVEs addressed in the update were not mentioned, the update is part of regular maintenance to ensure stability and security.
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 useTEST+=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 selectBuild 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.gfailed
(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
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
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
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