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 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

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 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.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.

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

References

• darkhttpd GitHub Repository
• darkhttpd v1.14 version tag (version that was reviewed)
• darkhttpd v1.15 release (fixed version)

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

WebAssembly (abbreviated Wasm) is a portable binary instruction format. It has gained popularity for its portability as a compilation target that enables deployment on the web for both client and server applications.

We can leverage the portability of Wasm to run Wasm workloads alongside Linux containers by combining crun and Podman. crun supports running Wasm workload by using WasmEdge, Wasmtime, or Wasmer runtimes. While Podman defaults to runc, runc, and crun can be used interchangeably.

WasmEdge is a lightweight, high-performance, and extensible WebAssembly runtime for cloud-native and edge applications. WasmEdge was recently added to openSUSE Tumbleweed and this can give us support for Wasm workloads on containers if we enable an experimental feature in crun.

Now that we have WasmEdge in openSUSE Tumbleweed and crun experimental support for Wasm workloads we can run WebAssembly workloads on Podman. This new feature was introduced into Podman in Tumbleweed and also a new package. The blog post shows how to use it.

Preparing our environment

We first need to install crun as runc in the default OCI runtime for Podman.

zypper in crun

Once crun is installed check if you have Wasm support.

$ crun -v
crun version 1.9
commit: a538ac4ea1ff319bcfe2bf81cb5c6f687e2dc9d3
rundir: /run/user/1000/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL

In the above output, we can see that crun supports WasmEdge (+WASM:wasmedge).

Preparing our application

We are going to create a simple “Hello” application in Rust.

First, ensure you have Rust and WasmEdge installed.

zypper in rust wasmedge

Now let’s create our “Hello” application in Rust.

$ cargo new hello --bin
$ cd hello

Change the message in src/main.rs to Hello WebAssembly! or any other message you want.

Now let’s compile our application, but the target machine will be Wasm.

$ cargo build --target wasm32-wasi

We can now execute the binary we just compiled and check that it works as expected.

$ wasmedge run target/wasm32-wasi/debug/hello.wasm
Hello WebAssembly!

You have successfully built your Wasm application.

Creating a Wasm container

With our Wasm binary in hand, let’s add it to a container.

Create a file named Containerfile and add the following to it:

FROM scratch
COPY target/wasm32-wasi/debug/hello.wasm /
CMD ["/hello.wasm"]

Let’s build our Wasm container with Buildah.

$ buildah build --platform=wasi/wasm -t hello-wasm .

You should have a Wasm container by now.

Running a Wasm workload

Let’s run our Wasm container with Podman.

$ podman run --rm hello-wasm
Hello WebAssembly!

Great, we have a working Wasm container.

Conclusion

WebAssembly is a fairly recent topic, but it has gained a lot of attention because you can reuse most of what you already know or use and easily port applications.

Running a native Wasm container is another example of how portable this format is.

Results from a use case survey gave some insightful information about how people perceive openSUSE Slowroll.

Some view it as a replacement for openSUSE Leap, but recent news about a clear course set for Leap should help to explain that Slowroll has a different path.

Slowroll is an experimental distribution introduced in 2023. It was designed as a variant of openSUSE Tumbleweed when the future of openSUSE Leap was not yet clear.

The main characteristic of this distribution is a slower rolling release compared to Tumbleweed.

Some users might find value in this balance between rapid updates of Tumbleweed and a traditional stable release like openSUSE Leap. After all, the purpose and principles of open-source software is to promote software freedom, enable users to freely study, modify, and distribute software for any purpose; Slowroll is doing all of the above.

Slowroll integrates big updates every one month or so along with continuous bug fixes and security updates as they are available.

The idea behind Slowroll is to offer a distribution that improves stability without losing access to new features in the base packages such as the kernel, desktop environments and packaging. These slower update cycles allow for more extensive testing and validation of packages before their inclusion. Think of Slowroll as more of a skip than a Leap.

Regarding Slowrolls relationship with openSUSE Leap, it’s important to note that Slowroll is not a replacement for Leap. Rather, it provides an alternative for users seeking more up-to-date software at a slower pace than Tumbleweed, but much faster than Leap. This is particularly relevant in the context of the future branch of the SUSE Linux Enterprise distribution transitioning to ALP (Adaptive Linux Platform). The development of Slowroll originated from discussions among openSUSE developers about the future of the openSUSE Leap distribution, but has no other relation to the Leap release.

Slowroll is still rather new and is based on openSUSE Tumbleweed packages.

While Slowroll is a significant addition to the openSUSE family, it caters to users choosing a slightly slower up-to-date software system. The name Slowroll was chosen to reflect its slower update cycle and has been retained after a community voting process​.