Nightly arm64 syslog-ng container builds are now available
Recently we enabled nightly syslog-ng builds and container builds for arm64. It means that from now on, you can run the latest syslog-ng on 64bit ARM platforms. For this test, I used a Raspberry Pi 3 running the latest Raspberry Pi OS. As I use Podman everywhere else (I am an openSUSE / Fedora guy), I also installed it here for container management.
Read more at https://www.syslog-ng.com/community/b/blog/posts/nightly-arm64-syslog-ng-container-builds-are-now-available

syslog-ng logo
Tumbleweed – Review of the weeks 2025/11 & 12
Dear Tumbleweed users and hackers,
We did it! We reached the ‘week of the Linux desktop’! Maybe not every desktop out there is updated to the latest release yet, but at least we have seen the two major Desktop Environments updated in the last two weeks. That’s just some of the few things that have happened over the last two weeks, which resulted in 12 published snapshots (0306, 0307, 0308, 0310, 0311, 0313, 0314, 0315, 0316, 0317, 0318, and 0319).
the most relevant changes included in these snapshots were:
- Emacs 30.1
- Mozilla Firefox 136.0 & 136.0.1
- GNOME 48.0
- KDE Gear 24.12.3
- KDE Plasma 6.3.3
- KDE Frameworks 6.12.0
- Samba 4.21.4
- Mesa 25.0.1
- Perl 5.40.1
- RPM 4.20.1
- Linux kernel 6.13.6
- Apache 2.4.63
- SELinux 3.8.1
- GStreamer 1.26.0
- systemd 257.4
- git 2.49.0
- gimp 3.0.0 final release
- Python 3.13 has become the primary interpreter. /usr/bin/python3.13 refers to this now.
- GCC 15: GCC 15 provides the libraries (e.g., libgcc_s1, libstdc++), while GCC 14 is still the used compiler.
With such an immense list, it’s surprising there is still work left to be done – but everybody is really active and it’s a pleasure to see things fly through the staging areas. Things currently being worked on include:
- Shadow 4.17.4
- Texlive 2025
- LLVM 20
- Mesa 25.0.2
- pcre is scheduled for removal (please help move everything to pcre2)
- GCC 15 as default compiler (See Staging:Gcc7)
Invitation to openSUSE.Asia Summit 2025 - Faridabad, India
29th – 31st August 2025
About openSUSE.Asia Summit
We are excited to announce that the openSUSE.Asia Summit 2025 will be held in Faridabad, India. This annual event brings together passionate users, developers, and contributors from across the open-source community, particularly openSUSE and FLOSS enthusiasts.
Previous summits have been widely attended by participants from India, China, Indonesia, Taiwan, Japan, South Korea, and more.
Since its inception in Beijing (2014), the openSUSE.Asia Summit has served as a hub for open-source contributors to meet, share knowledge, and engage in discussions about openSUSE and other technologies running on it.
After a few years of virtual events due to the pandemic, we’re excited to once again meet in person and foster communication in a dynamic, collaborative environment.
This year’s summit will focus on:
- Knowledge exchange
- Hands-on workshops
- Creating valuable connections
📢 Note: We will not accept virtual talks this year – only in-person presentations.
📅 The Summit Dates
Mark your calendars! The openSUSE.Asia Summit 2025 will take place from 29th to 31st August 2025, at a premier location in Faridabad, India.
🎉 We also have an exciting excursion for speakers planned on 31st August 2025. More details to be shared soon.
Additionally, consider attending:
Both events are hosted by The Linux Foundation and will take place nearby before our summit.

📍 Venue: MRIIRS, Faridabad, India
We are proud to host the openSUSE.Asia Summit 2025 at: Manav Rachna International Institute of Research and Studies (MRIIRS), located in Faridabad, Haryana, India.
🏛️ About the Venue
- Location: Sector 43, Faridabad, Haryana, India
- Accessibility: Easily accessible by public transport and close to major hubs in the Delhi-NCR region
- Nearby City: Just a short distance from New Delhi, making it easy for attendees to travel
📌 Stay tuned for more details on:
- Exact session halls
- Accommodation options near the venue
🌍 Why Faridabad?
Faridabad, a major city in NCR (National Capital Region), is a rapidly growing tech hub with a vibrant educational ecosystem.
✈️ Reasons to Attend in Faridabad:
- Strategic Location: Easy access from Delhi Airport (IGI) and well-connected public transport
- Thriving Tech Ecosystem: A growing IT and tech industry, making Faridabad an ideal summit location
- Cultural & Culinary Experience: Enjoy the rich history, culture, and cuisine of Delhi-NCR
📌 Explore More:
🏰 Explore Delhi While You’re in India!
While you’re attending the openSUSE.Asia Summit 2025, take some time to explore:
✨ Historical Landmarks:
- Red Fort
- Qutub Minar
-
India Gate
</p>
🍽️ Indian Cuisine:
- Butter Chicken
- Samosas
- Chai!
📌 Plan Your Travel:
🎤 Call for Speakers
📢 We are officially opening the Call for Speakers in June 2025!
We invite open-source enthusiasts, developers, and thought leaders to share their insights at the summit. More information on the submission process will be available soon.
🎯 Interested in speaking? Check our openSUSE events page for updates: openSUSE Events Page
Choose Freedom, Not Trialware
A few weeks ago, a customer walked into a Best Buy, which is a well-known retailer in North America that sells computers, appliances and gadgets of all kinds.
On a mission to buy a new laptop for a family member, the customer sought something simple, reliable and future-proof. After browsing through the selection, a solid Lenovo laptop stood out; it had good hardware, decent battery life and no unnecessary gimmicks.
As the customer approached the checkout and began paying for the new laptop, the salesperson turned and asked an unexpected question:
“Would you like to prepay for Windows?”
The customer blinked in surprise.
“These computers you are displaying don’t include Windows?”
“No,” the salesperson responded. “Windows comes with a 30-day trial offer.”
Without hesitation, the customer responded firmly:
“Absolutely not. I’m putting Linux on it.”
The salesperson hesitated, as if hearing this statement for the first time.
What many people don’t realize is that in certain regions, antitrust laws require manufacturers to sell computers with an option not to preinstall Windows. This is a response to decades of monopolistic practices, where users were forced to pay for a Microsoft license whether they wanted it or not. Some manufacturers have introduced Linux-preinstalled models or “no OS” options, though these remain relatively niche. In regions without such regulations, like the U.S., Windows-free computers are still uncommon outside of specialized retailers and business contracts.
Some stores (depending on the country) are legally required to offer a refund for the cost of the Windows license if the customer chooses not to use it. This is, however, rarely advertised. Many people don’t even know they have a choice or that there is a choice for freedom.
For a new laptop, install a Linux distribution like openSUSE’s Leap, Slowroll, Tumbleweed, Kalpa, Aeon or others.
What You Can Do
If you’re in the market for a new computer, don’t let the assumption of Windows dictate your purchase. Here’s how you can take control of your computing experience:
- Ask for a non-Windows option: Many stores don’t advertise it, but some models are available without a preinstalled OS.
- Request a Windows refund: If your country has consumer protection laws, you might be entitled to a refund for the Windows license if you don’t use it.
- Download and install openSUSE: Head to get.opensuse.org and choose the version that best fits your needs. Leap for long-term stability or Tumbleweed for the latest rolling updates.
- Enjoy a system without restrictions: No licensing fees, no activation headaches, and no locked-down software.
Linux has always been there, unlocked and ready to go.
So the next time you walk into a store looking for a new computer, remember; you have a choice. And that choice can be freedom.
This is part of a series on Upgrade to Freedom where we offer reasons to transition from Windows to Linux.
SUSE extends eLearning discount to openSUSE Members
SUSE, the main sponsor of the openSUSE Project, is offering a discount on its eLearning platform for members looking to enhance their skills in SUSE technologies.
The eLearning offers a variety of training courses that could be useful to openSUSE users, including Linux administration, Kubernetes, security and systems management.
A couple members from the community reached out to Tori Easterly inquiring about the possibility for members to receive a discount or a more accessible pricing option for those interested in enhancing their skills. As a result, SUSE extended a 20 percent discount.
Enterprise-level training allows people to learn at their own pace and convenience. The courses cover Linux fundamentals, automation and cutting-edge technologies like Kubernetes and container management. The eLearning provides unlimited access to all SUSE IT courses, spanning Linux, Systems Management, Security, Edge Computing and more. As IT evolves rapidly, the curriculum is frequently updated to reflect the latest advancements in SUSE technologies.
openSUSE Project members can get 20 percent off SUSE eLearning courses using the Coupon Code TRAIN2025 upon checkout.
Introducing the develop branch of the syslog-ng git repo
For many years, the development of syslog-ng happened on the master branch in Git. However, if you follow that branch, you might have noticed that there has not been much activity on it lately. That is because we introduced a new branch in git called “develop”.

syslog-ng logo
The syslog-ng Insider 2025-03: EPEL 10; Elasticsearch; Active Roles
The March syslog-ng newsletter is now on-line:
-
Test syslog-ng on EPEL 10!
-
Collecting Active Roles logs centrally using the syslog-ng Windows Agent
-
syslog-ng OSE 4.8.1 is now in EPEL 10, quick fix for Elasticsearch
It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2025-03-epel-10-elasticsearch-active-roles

syslog-ng logo
Below: World Writable Directory in /var/log/below Allows Local Privilege Escalation (CVE-2025-27591)
Table of Contents
- 1) Introduction
- 2) Symlink Attack in
/var/log/below/error_root.log - 3) Further Issues
- 4) Bugfix
- 5) CVE Assignment
- 6) Hardening Suggestions
- 7) Timeline
- 8) References
1) Introduction
Below is a tool for recording and displaying system data
like hardware utilization and cgroup information on Linux. In January 2025,
Below was packaged and submitted to openSUSE Tumbleweed. Below runs as a
systemd service with root privileges. The SUSE security team monitors
additions and changes to systemd service unit files in openSUSE Tumbleweed, and
through this we noticed problematic log directory permissions applied in
Below’s code.
The version we reviewed in this context was v0.8.1 and this report is based on that version.
Upstream released a bugfix in version v0.9.0 and a security advisory on GitHub.
2) Symlink Attack in /var/log/below/error_root.log
Below’s systemd service runs with full root privileges. It attempts to
create a world-writable directory in /var/log/below. Even if the directory
already exists, the Rust code ensures that it receives
mode 0777 permissions:
if perm.mode() & 0o777 != 0o777 {
perm.set_mode(0o777);
match dir.set_permissions(perm) {
Ok(()) => {}
Err(e) => {
bail!(
"Failed to set permissions on {}: {}",
path.to_string_lossy(),
e
);
}
}
}
This logic leads to different outcomes depending on the packaging on Linux distributions:
- in openSUSE Tumbleweed the directory was packaged with
01755 permissions (below.spec line 73), thus causing
the
set_permissions()call to run, resulting in a directory with mode 0777 during runtime. - in Gentoo Linux the directory is created with mode 01755 resulting in the
same outcome as on openSUSE Tumbleweed (below.ebuild).
Where the 01755 mode is exactly coming from is not fully clear, maybe the
cargobuild process assigns these permissions during installation. - in Fedora Linux the directory is packaged with 01777 permissions, thus the
set_permissions()code will not run, because theifcondition masks out the sticky bit. The directory stays at mode 01777 (rust-below.spec). - the Arch Linux AUR package (maybe wrongly) does not
pre-create the log directory. Thus the
set_permissions()code will run and create the directory with mode 0777.
Below creates a log file in /var/log/below/error_root.log and assigns mode
0666 to it. This (somewhat confusingly) happens via
a log_dir variable, which has been changed
to point to the error_root.log file. The 0666 permission assignment to the
logfile happens in logging::setup(), also
accompanied by a somewhat strange comment in the code.
A local unprivileged attacker can stage a symlink attack in this location and
cause an arbitrary file in the system to obtain 0666 permissions, likely
leading to a full local root exploit, if done right, e.g. by pointing the
symlink to /etc/shadow. Even if the file already exists it can be removed
and replaced by a symlink, because of the world-writable directory
permissions. The attack is thus not limited to scenarios in which the file has
not yet been created by Below.
We believe the actual intention of this code might have been to assign mode
01777 (i.e. carrying a sticky bit). The sticky bit is neither contained in
the if condition nor in the set_permissions() call, though. With the
sticky bit set the Linux kernel’s protected_symlinks logic, which is enabled
on most Linux distributions, would protect from symlink attacks.
3) Further Issues
Even on Fedora Linux, where /var/log/below has “safe” 01777 permissions,
there is a time window during which problems can arise. As long as
below.service has not been started, another local user can pre-create
/var/log/below/error_root.log and e.g. place a FIFO special file there. This
will pose a local DoS against the below service, since it will fail to open the
path and thus fail to start.
If /var/log/below were to be deleted for any reason, then Below would still
recreate it using the bad 0777 mode permissions, which can also happen on
distributions that initially package /var/log/below using permissions that
do not trigger the set_permissions() call in Below’s code.
Below applies many world-writable and world-readable permissions under
/var/log/below. This seems a strange choice. For some reason the internal
state data of Below is also stored within the log directory in
/var/log/below/store. The data is fully world-readable, which could result
in information leaks, if Below stores system information there that would not
otherwise be accessible to unprivileged local users. We did not check if this
applies, though. By pre-creating this directory before below.service runs
for the first time, an unprivileged user can control all of its contents,
possibly violating the integrity of Below in various ways.
The world-writable logfile error_root.log makes no sense to us as well. Why
should arbitrary users in the system be able to modify the log data of
Below? This allows log spoofing by local users. Even making the logfile
world-readable is considered bad style by some people these days. Why
/var/log/below should be world-writable in the first place is also
unclear to us. Ideally only root or a dedicated below service user should
be allowed to write there.
4) Bugfix
Upstream published a bugfix in commit 10e73a21d67 which is
part of Below v0.9.0. The commit basically removes all
problematic permission assignments from the code, stating that these
directories are better setup by systemd. This seems to refer to an added
systemd directive LogsDirectory=below in the below.service file.
With this change no world-writable directories or files should turn up in
/var/log/below anymore, and the most severe issues from this report are
addressed. The possible matter of world-readable log and store files remains,
though.
We did not get any details from upstream about the design decisions in Below that led to this issue or about any further changes that upstream intends to perform to improve security in this area.
5) CVE Assignment
Upstream assigned CVE-2025-27591 for this issue.
6) Hardening Suggestions
It could be considered to apply hardening directives in Below’s systemd service unit that prevent some attack types. Most prominently, restricting write access for the daemon to a range of well known locations comes to mind.
7) Timeline
| 2025-01-20 | We noticed the issue and started tracking it privately in bsc#1236109. |
| 2025-01-20 | We shared the information with Meta via its security bug report system, offering coordinated disclosure. |
| 2025-01-21 | We received an initial automated reply from Meta. |
| 2025-02-21 | We received an update that the report would be forwarded to the appropriate engineering team. |
| 2025-02-26 | We were awarded a bug bounty for the report but did not receive any details about the publication, bugfix or CVE assignment. We will donate the bug bounty to open source projects and other non-profit organizations. |
| 2025-02-26 | Our Below packager updated the openSUSE Tumbleweed package to the newly released version v0.9.0, which happened to already contain the bugfix for the issue. |
| 2025-02-27 | We identified commit 10e73a21d67 as the likely bugfix and inquired with upstream once more about technical details and whether this is the complete bugfix they intended to apply. |
| 2025-02-28 | We received an automated reply about the bugfix status of the issue. |
| 2025-03-03 | We received a confirmation that commit 10e73a21d67 is the intended bugfix and that further steps (including a possible CVE assignment) are handled internally. |
| 2025-03-03 | We inquired whether it is okay for us to publish the full report at this time. |
| 2025-03-07 | We did not get a response about publication from upstream so far. Since the bugfix was public but not clearly marked as a security issue we shared this report with the linux-distros mailing list, suggesting an embargo of 5 days before general publication. |
| 2025-03-08 | Michel Lind, a member of the linux-distros mailing list who is also a Meta engineer, involved upstream internally about the impending disclosure. |
| 2025-03-08 | Upstream reached out to us stating that a GitHub security advisory on the issue is planned in the following week. They also shared the CVE assignment with us. They asked us to postpone publication on our end until that happens. |
| 2025-03-10 | We responded that postponing publication is okay with us. We also pointed out that the linux-distros mailing list has a maximum embargo period of 14 days, which limited the maximum postponement to 2025-03-21. |
| 2025-03-12 | Upstream published a GitHub advisory. Thus general publication could happen on the date originally proposed by us on the linux-distros mailing list. |
8) References
Zsolt Audio Turns 40 This Year
Last weekend, I was welcomed to a special event in an industrial area of Budapest. Zsolt Audio – one of the best known high-end audio manufacturers in Hungary – turns 40 this year, and Zsolt Huszti, the founder, started a series of events celebrating this in the showroom next to his “factory”. We listened to some fun stories from the past 40 years, and also to music on some of his latest devices.
The first time I heard about Heed Audio was in 2011, when one of my friends brought me along to an open house event. Sadly, that was the last time I met that friend before his passing, but that’s a different story. I’m happy that he introduced me to Heed Audio right before leaving us…
At that time, we listened to the Enigma 5 speakers, and to me, it was love at first sight. I mean, first listening… :-) I decided that these are the speakers I want to listen to. And almost a decade later, this dream finally became true. And while the Enigma 5 is no longer produced, you can still find some info about it at the bottom of this page: https://heedaudio.com/loudspeakers/

The Zsolt Audio show room
At the event last Saturday, we learned a lot about the company’s future plans, some of which is quite interesting. Zsolt had some ground-breaking ideas, but I’m not in the position to share those publicly. However, we also listened to a few devices that are already available or will be available soon.
The Heed Audio Asterisk is a really simple stereo amplifier. Nothing fancy, just three line inputs, and it can drive a pair of speakers. However, it can do its job really well. Connected to the amplifier, we could listen to a pair of bookshelf speakers. They are tiny and still under development, but could already fill the show room with a loud and clear voice. The amplifier is already available: https://www.bartimexaudio.hu/Heed-Audio-Asterisk

The Heed Audio Asterisk
I love the sound of the Enigma 5 speakers. They do a fantastic job with most of the music I listen to. You can easily draw a map of instruments you are listening to in 3D. I did it a couple of times, and they turned out to be pretty accurate when compared to photos taken during recordings. Unlike the Enigma 5, the reincarnation of the StandArt speakers we listened to are not omnidirectional. You cannot expect the same level of spatial sound. However, speakers directed at you reproduce the atmosphere of a (prog)rock concert much better. At the event, we also listened to some Rammstein, which was pure joy on these speakers. They were driven by a Heed Obelisk integrated amplifier, a slightly more modern version of what I use at home. As you could guess from this description, these speakers are not meant to replace the Enigmas, but rather complement them.

A StandArt reincarnation
This was just the first event of a promising series. I’m looking forward to listening to even more stories and music!
Tumbleweed – Review of the week 2025/10
Dear Tumbleweed users and hackers,
This week felt quite busy; lots of things going through staging, but luckily, most things passed rather easy from what I’ve seen. At this point, a big “thank you” to the package maintainers taking care of such a smooth process. Tumbleweed could not be rolling at its speed without your help.
Seven snapshots were published (0227…0305) during this week. The most relevant changes included are:
- KDE Plasma 6.3.2
- Postfix 3.10.1
- libzypp/zypper updates with experimental ‘parallel download’ capabilities.
- Linux kernel 6.13.5
- glibc 2.41
- QEmu 9.2.2
- GNOME Shell 47.5
The next snapshots to come will bring even larger changes, namely:
- Python 3.13 as primary python interpreter. /usr/bin/python3 will be switched to version 3.13. This will require a rather large Tumbleweed rebuild to ensure the python3-* symbols move to the correct packages.
- GCC 15: We will run the well-tested 2-phase approach from previous years: first, switch the used libraries to the ones generated by gcc15 (the phase we are currently working on), then later switch to GCC 15 being the compiler.
- Mozilla Firefox 136.0
- KDE Gear 24.12.3
- Mesa 25.0.1
- RPM 4.20.1
- Perl 5.40.1