On this day in 1943 Vangelis was born. The very first CD I bought over three decades ago was composed by him: Chariots of Fire. After so many years, I still love his music.

As you can see, I do not have everything by him. I do not like his earliest and latest works that much, but almost everything in between. Unfortunately I could not find everything on CD. For example, I loved “Soil Festivities”, especially since I was a soil engineer during my college years. But not only is it not available on CD (even used), it is also missing from streaming services.

Several times I learned years later that the music I was listening to was actually a movie soundtrack. Chariots of Fire is one of them, as well as Blade Runner. It became one of my favorite movies, and it’s the only movie I have on 4K bluray.

I’m listening to Vangelis right now and expect to listen to a few more of his albums today :-)

Or, on TIDAL: https://listen.tidal.com/album/103208768

Dear Tumbleweed users and hackers,

The latest snapshot is just hot off the press and ready to consume – It’s just the latest in a series of five snapshots (0320, 0321, 0324, 0325, and 0326) published this week. Unlike last week, this week, most changes were more in the background.

The five snapshots brought you these changes:

• Samba 4.22.0
• Linux kernel 6.13.7 & 6.13.8
• Mesa 25.0.2
• Shadow 4.17.4
• Bind 9.20.7
• Gimp 3.0.2
• Poppler 25.03.0
• Timezone 2025b

From what we’ve seen, either in the staging areas or from announcements on the mailing list, these are the topics being worked on:

• Linux kernel 6.14.0
• GCC 15 as distro compiler, see https://build.opensuse.org/staging_workflows/openSUSE:Factory/staging_projects/openSUSE:Factory:Staging:Gcc7
• CMake 4.0
• Python setuptools 78.0
• LLVM 20: breaks build of Mozilla Firefox
• Removal of pcre(1). Please help with that cleanup, port to PCRE2. See https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/BK3SPPFOM3LI6K5PTXPKZMKMIUIPOEXS/
• More work towards proper display-manager service integration, https://en.opensuse.org/openSUSE:DisplayManagerRework
• The removal of the HPC stack has been proposed. See https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/7VAP572DMVET3CPGOSB2OCOFEQ5CPWJE/

A new zypper experimental media backend and support for parallel package downloads have been introduced with the release of libzypp version 17.36.4 and zypper version 1.14.87.

These enhancements, according to an email on the factory mailing list, improve the performance of package management by reducing the time required to fetch packages and metadata.

The update provides two main features: an ability to fetch packages using concurrent connections, and a simplified media backend that improves connection reuse and metadata handling. Both features are currently in an experimental phase and must be manually enabled.

Before the feature is officially enabled by default, parallel package downloading can be enabled by setting an environment variable before executing a zypper operation. This allows multiple packages to be downloaded simultaneously, improving overall speed.

To Enable parallel downloads

env ZYPP_PCK_PRELOAD=1 zypper dup

The number of concurrent downloads can be configured in the zypp.conf file using the following directive:

download.max_concurrent_connections = 5

The default is 5. However, higher values may yield better performance depending on system resources and network conditions.

The new media backend can be enabled with a separate environment variable. The backend eliminates overhead by avoiding metalink fetching and multi-server file splitting. It is optimized for better connection reuse during metadata fetches.

To enable the new media backend

env ZYPP_CURL2=1 zypper ref

While these two features are separate, they are most effective when used together. Using metalink= URLs in .repo files can further improve mirror performance. However, baseurl= remains the preferred setting for production systems due to its trusted key behavior.

The following versions are required to use the new features:

• libzypp version 17.36.4 or newer
• zypper version 1.14.87 or newer

These are available in Tumbleweed and Slowroll. Users can test out these new enhancements on Leap or immutable desktop variants Aeon and Kalpa using Distrobox.

Users of openSUSE-repos on Tumblweed gained mediahandler=curl2 as part of the repository urls as well as preset ZYPP_PCK_PRELOAD=1 via /etc/profile.d/opensuse_repos.sh with the latest openSUSE-repos update.

Leap 15 and 16 users can currently get the zypper update with these enhancements from the development repository.

To install the updated packages, users can switch to a root shell with sudo su - and run zypper in <package-name>. Unfortunatelly calling sudo zypper does not processs /etc/profile.d/ files and the variable ZYPP_PCK_PRELOAD=1 is unset. Users who are used to call sudo zypper can create an alias or use pass the variable manually (see the env ZYPP_PCK_PRELOAD=1 example) . This cumbersome part will be gone once the parallel download feature is mature and gets enabled by default in zypper.

https://download.opensuse.org/repositories/zypp:/Head/

The parallel downloads should allow systems on slow or high-latency connections to make better use of available bandwidth. Metadata refreshes become more efficient with the new backend. These improvements also reduce setup time in CI/CD pipelines and automated environments.

The following are some benchmark results listed in the email on the factory mailing list:

Scenario                                           Time
--------------------------------------------  --------
Download 100MB / ~250 packages
Default (MultiCurl)                               68.7 sec
New Backend (ZYPP_CURL2=1)                        29.6 sec
Parallel Downloads (ZYPP_PCK_PRELOAD=1)           13.1 sec

Download 1.02GB / 407 packages into empty rootfs
Default (MultiCurl)                               281.1 sec
New Backend (ZYPP_CURL2=1)                        208.5 sec
Parallel Downloads (ZYPP_PCK_PRELOAD=1)           119.6 sec

These results show significant improvements in real-world scenarios with total execution time reduced by more than 50 percent in some cases.

Although still experimental, these options are available now for users who wish to enable and test them.

Users who’d like to provide feedback can respond to the mailing list thread or submit a bug report against libzypp bugzilla component.

The more feedback the sooner the feature can be made official.

Tutorial

Watch our tutorial on the openSUSE YouTube channel showing its use and setup.

As political winds shift across the globe, the digital world is not immune to the turbulence. Governments and organizations across the globe are reassessing their dependencies, especially those tied to large, centralized tech firms.

While headlines paint a world splintering along geopolitical lines, the open-source community is quietly doing what it has always done best; building global tools for global freedom.

A recent example of this is an EU OS initiative—a European blueprint for a locked-down, KDE Plasma-based Linux distribution aimed at public-sector use.

Though technically not a new operating system, EU OS serves as a proof-of-concept for deploying a Linux system.

The project put together info on government deployments like LiMux in Germany and GendBuntu in France, and endorses the public money, public code philosophy.

However, there is a case for broader OS inclusion without piggybacking a popular EU sovereignty narrative.

While this naming is trying to address a narrative, a multiple Linux distributions should be integrated into any government’s strategy.

The current Fedora+KDE direction is mature, but relying on one distro and one desktop environment introduces avoidable risks. Instead, it would be wise for all governmnets to embrace alternatives like Aeon with GNOME, alongside another immutable Plasma-based choice of Kalpa.

Why? Security. Different distributions and desktops reduce the risk of a single point of failure. If vulnerabilities emerge, they won’t simultaneously impact every system.

Another reason is tailored user experience. GNOME offers a simple interface for general office users, while KDE’s power-user features may be more appropriate for technical users.

As immutable OSes with transactional updates, Aeon and Kalpa share the same robust core stemming from Tumbleweed updates, which offer rollback, system integrity and layered deployments with seamless updates. Both Aeon and Kalpa were designed from the ground up for modern, containerized and cloud-hybrid environments.

The broader idea needing discussion for governments goes beyond what a distro standard is. In an age of ransomware, cloud lock-in, and surveillance capitalism, it’s time to move beyond traditional desktop OS thinking.

The open-source world already has the tools to move forward with a new way of thinking:

• Immutability with transactional updates (MicroOS, Aeon, Kalpa, Kinoite)
• Declarative system configuration (Agama, Ansible)
• Desktop options for varying user needs (GNOME, KDE Plasma, Xfce)
• Open identity and authentication standards (LDAP, OpenID)
• Transparent package formats (Flatpak, RPM)

Let’s not get lost in the flags, logos or headlines. While politics shift and trade alliances fray, the open-source movement remains one of the most stable, borderless, and collaborative human endeavors on the planet.

If you’re looking for freedom, look no further than this space — it’s been enduring longer than the EU’s own monetary standard.

The future of tech doesn’t need to be American. It doesn’t need to be Chinese. It needs to be open.

This is part of a series on Upgrade to Freedom where we offer reasons to transition from Windows to Linux.

Last December, the CD shop where I bought most of my collection closed its doors for good. I had seen it coming — the owner had been gradually winding down the business in preparation for retirement — but after nearly 30 years of shopping there, it was still a tough moment.

This logo belongs to Periferic Records - Stereo Kft.. Back in the nineties, during my university years, I used to look for this logo at concerts, always hoping to spot a bearded man selling an incredible selection of CDs. Imagine my surprise when, in 2002, I attended a concert and discovered that the organizer was none other than that same bearded man — who also happened to be one of my second cousins!

From that moment on, I became a regular at the shop. The owner was a publisher of some of my favorite music, including Hungarian progrock and piano albums. Some standout names: After Crying, Vedres Csaba, and Solaris. While the shop specialized in progrock — with a selection unlike anywhere else — it also offered a wide variety of other genres.

When I received my first big paycheck, I went straight to the store and bought dozens of CDs. Today, streaming services like TIDAL and Spotify have recommendation engines, but back then, nothing could beat the personalized recommendations from the shop’s staff. More than once, I walked out with a free CD as a bonus, one of which became an all-time favorite: Townscream – Nagyvárosi Ikonok.

Unlike many music shops that play background music on low-quality systems, Stereo had StandArt speakers from Heed Audio. These speakers, almost as old as the shop itself, created an immersive listening experience. Though I often rushed in just to pick up an order, on the rare occasion that I had time, I would linger to listen — sometimes discovering new music to take home.

The website still exists, and you can get an ever shorter list of available CD titles by e-mail. In December, I spent most of my free time going through their list of albums, listening to samples on TIDAL and YouTube — nearly 1,500 albums in total. Through this process, I found some rare gems, including one CD I bought purely for its intriguing title: God-Sex-Money. Well, actually the description, “Recommended for Wakeman/Emerson fans,” sealed the deal :-)

Even now, whenever I’m near the old shop, I instinctively start walking toward it — only to remember that an important part of my life is gone forever. But it lives on in my CD collection and my memories.

Table of Contents

• 1) Introduction
• 2) wait3() as a Side Channel in Setuid Programs
• 3) File Existence Test (CVE-2024-0149)
• 4) Bugfix
• 5) CVE Assignment
• 6) Other Packages
• 7) Timeline
• 8) References

1) Introduction

nvidia-modprobe is a setuid-root helper utility for the proprietary Nvidia GPU display driver that loads kernel modules and creates character devices required for userspace GPU access. Normally, drivers do this via udev. However, kernel licensing restrictions prohibit Nvidia’s proprietary kernel module from generating uevents, which are required for udev to work. Therefore this special helper is needed.

We reviewed nvidia-modprobe as part of our whitelisting process, which requires an audit for all newly introduced setuid binaries in openSUSE. The version we reviewed was 550.127.05 and this report is based on that version. Upstream released a bugfix in version 550.144.03 and a security advisory.

2) wait3() as a Side Channel in Setuid Programs

The wait3() system call allows the calling process to obtain status information for child processes, similar to waitpid(). Unlike waitpid(), wait3() also returns resource usage information. The measurements returned by this call include CPU time, memory consumption and lower-level information such as the number of minor and major page faults that occurred during the child’s runtime. See also man 2 getrusage.

Perhaps surprisingly, wait3() also works for setuid sub-processes, leaking quite a bit of information about the behavior of the target program, which is running with elevated privileges.

A convenient way to try this out is GNU Time, a small utility that spawns a target process and prints the output of wait3(), for example:

/usr/bin/time -v nvidia-modprobe

3) File Existence Test (CVE-2024-0149)

In the case of nvidia-modprobe, we can leverage wait3() for a file existence test.

When executed with the option -f NVIDIA-CAPABILITY-DEVICE-FILE (an arbitrary path), nvidia-modprobe performs the following steps:

• attempt to open the supplied path as root
  • if the path does exist:
    • read one or more lines
    • parse each line (implemented safely)
    • exit silently, return code 0
  • if the path does not exist:
    • exit silently, return code 0

It turns out that reading the first line of the supplied path sometimes causes a minor page fault. The number of page faults is not perfectly constant across multiple executions, depending on whether the page mapped by the kernel is dirty or not. However, if the file does not exist, it cannot be read, and therefore no page faults will be triggered. We can execute nvidia-modprobe repeatedly, calculate the median number of page faults, and infer whether the supplied path exists or not, even if the caller does not have the necessary file system permissions.

Simplified example:

$ /usr/bin/time -q --format=%R nvidia-modprobe -f /root/.bash_history
80

$ /usr/bin/time -q --format=%R nvidia-modprobe -f /root/does/not/exist
79

The output fluctuates, but it only takes a few repetitions to get a reliable signal from the median.

4) Bugfix

Upstream published a bugfix. This commit limits the queried path to files below /proc/driver/nvidia before attempting to read from it, eliminating the information leak.

5) CVE Assignment

Upstream assigned CVE-2024-0149 for this issue.

6) Other Packages

Considering the relatively obscure nature of this side channel attack, we decided to briefly look into a couple of other packages exhibiting similar usage patterns:

• shadow
  • chsh: negative
• util-linux
  • mount -T: negative
  • umount: negative
• v4l-linux: positive, but does not require wait3(), and the issue was already known (CVE-2020-1369).

Even though we did not find additional instances of this problem, and the severity of this vulnerability is rather low, it’s still one of many pitfalls to keep in mind when writing or auditing setuid programs.

7) Timeline

8) References

• nvidia-modprobe GitHub repository
• Nvidia security advisory
• Bugfix commit 83b777c
• getrusage(2)

Table of Contents

• 1) Introduction
• 2) Synce4l Synchronous Ethernet Daemon
• 3) Fwupd 2.0 D-Bus and Polkit Changes
• 4) Tuned Revisited
• 5) iio-sensor-proxy Revisited
• 6) systemd-sysupdated D-Bus Service
• 7) AppArmor aa-notify Polkit Policy
• 8) Conclusion
• 9) References

1) Introduction

Winter time is coming to an end (at least in the northern hemisphere, where most of the SUSE security team members are located), and with this we want to take a look back at what happened during the last three months in our team. We have already posted about a number of bigger topics that kept us busy over the winter:

• privilege separation issues in SSSD
• problematic return values in pam-u2f
• authentication bypass in dde-api-proxy
• authentication bypass in pam_pkcs11
• admittance of kio-admin into openSUSE
• problematic log directory permissions in Below
• file existence test in nvidia-modprobe

As usual in the spotlight series, in this post we want to give an insight into some of our work beyond these reports: reviews that did not lead to significant security findings, but still kept us busy and in some cases also led to upstream improvements. The topics again mostly involve Polkit authentication and D-Bus APIs, but we also looked proactively into a piece of networking software that raised our interest.

2) Synce4l Synchronous Ethernet Daemon

Our team is monitoring changes and additions to openSUSE Tumbleweed, most notably systemd services that newly appear in packages. The synce4l package raised our interest, because it contains a daemon which is running with full root privileges and is also networked. The package implements synchronous Ethernet, a low level protocol that basically maintains a shared clock between multiple hosts in an Ethernet subnet.

The project is implemented in the C programming language and consists of about 7.000 lines of code. The sensitivity of C programs to memory handling issues, the fact that the synce4l daemon runs as root and the niche topic of synchronous Ethernet is a mixture that makes it an interesting code review target.

We reviewed the source code in early January and fortunately couldn’t find any issues in it. The attack surface on the network is rather small. Even though by default there is no trust established between participants of the protocol, there is only an integer value exchanged between nodes. Corruption of this value cannot negatively influence a system running synce4l (beyond the protocol itself, naturally). The daemon also creates a UNIX domain socket in /tmp, but access to it is limited to root. The project employs a good coding style and we did not have any concerns left when we were finished with the review.

3) Fwupd 2.0 D-Bus and Polkit Changes

In January the openSUSE maintainer for fwupd packaged the major version 2.0 update, which required a follow-up audit by our team. fwupd is part of most Linux distributions and provides mechanisms to automatically upgrade firmware on the system. The fwupd daemon runs as root and implements a D-Bus interface with Polkit authentication. We have already reviewed it many times when changes to these interfaces have occurred.

Even though this time fwupd has received a major version update, there have only been moderate changes to the D-Bus and Polkit aspects of the software. Generally, the implementation of the D-Bus interface in fwupd is more on the complex side. Polkit authentication is implemented properly, but it is only applied to a subset of the D-Bus methods offered by the daemon. This means that one has to carefully differentiate between the methods that require Polkit authentication, and the ones that don’t require any authentication at all. This is what we did during the review; fortunately we couldn’t find any problems with the unauthenticated methods.

One notable feature that has been added in this fwupd release allows it to run its own dedicated D-Bus instance, likely for lean and mean environments or for use in early boot scenarios, when no system D-Bus is available. When this feature is in use then no Polkit authentication will be performed, likely because no Polkit daemon is present either in this situation. This mode will only be active when the environment variable FWUPD_DBUS_SOCKET is passed to the daemon, however, and should not be reachable in regular installations of fwupd.

There was one new Polkit action org.freedesktop.fwupd.emulation-load, which was allowed for users in a local session without authentication. The corresponding D-Bus method accepts JSON data, either directly or placed in a compressed archive which is passed to the daemon. This is used to load “hardware emulation data” into fwupd. This sounded like a strong privilege for a regular user to have, and thus we inquired upstream if this lax authentication setting was actually necessary. The outcome was that we could raise the authentication requirement to auth_admin, thereby improving security in fwupd.

4) Tuned Revisited

tuned has seen quite a number of changes recently, which also led to a local root exploit finding in November. We received yet another review request in January due to further changes in the area of D-Bus configuration and Polkit actions.

Security-wise there was not much interesting to find in these changes. A number of Polkit actions have been renamed, and tuned optionally provides a drop-in replacement for the UPower D-Bus interface now. We accepted the changes without further ado.

5) iio-sensor-proxy Revisited

iio-sensor-proxy is another package that we already reviewed in the past but that popped up again in January due to changes in its D-Bus configuration. The package provides a D-Bus interface for different hardware sensors like ambient light sensor, accelerometer or proximity sensor. During the review we found that a newly added net.hadess.SensorProxy.Compass.ClaimCompass D-Bus method was unauthenticated, while other similar methods required Polkit authentication.

We reported the issue privately to upstream. The lack of authentication was confirmed and upstream fixed the issue. We did not request a CVE or publish a dedicated report about this, because the impact of the issue is assumed to be low. Such smaller findings still show the usefulness of code reviews that can lead to improvements in upstream code and configuration before software is shipped to openSUSE users.

6) systemd-sysupdated D-Bus Service

In February we received a request to review an experimental systemd component called sysupdated. When reading the program description one could be inclined to think that systemd is now on a quest to replace package managers. The main purpose of this daemon is only to keep container assets and other images up-to-date, however.

sysupdated comes with a larger D-Bus interface protected - in parts - by Polkit. Some read-only properties and method calls are available without Polkit authentication. Systemd components rely on shared code to implement D-Bus services and Polkit authentication. Compared to the last time we had a look into these shared routines, it felt as if the complexity increased quite a lot in this area. You can have a look at this Bugzilla comment to get an impression of the complexities that are involved there these days. One reason for the increased complexity could be the addition of the Varlink IPC mechanism, which can also use Polkit for authentication.

Despite the perceived complexity in the D-Bus and Polkit handling, we couldn’t find any problematic aspects in the implementation. There was one decision to be made about the Polkit action org.freedesktop.sysupdate1.update. The authentication requirements for it are by default set to auth_admin:auth_admin:yes, meaning that users in a local session can update assets managed by sysupdated without authentication. This is also documented in the upstream Polkit policy. This only allows to update assets to the most recent version, not to any specific version nor to downgrade the version. It also doesn’t allow to install any new assets. For this reason we allow updates without authentication in our Polkit easy profile while the other profiles have been hardened to require admin authentication.

7) AppArmor aa-notify Polkit Policy

In February a request arrived to whitelist Polkit actions used by the aa-notify helper which has been added to the AppArmor package. This utility is a graphical program similar to setroubleshoot for SELinux, and allows to identify AppArmor violations and modify the AppArmor profile to allow actions that have been denied.

The two Polkit actions that needed reviewing allow to execute a Python script found in
/usr/lib/python3.11/site-packages/apparmor/update_profile.py via pkexec using a specific command line parameter. This script performs the task of actually modifying the AppArmor profile according to the provided input files. Due to the nature of the script there is no way to execute it safely without admin authentication. This is reflected in the Polkit action settings, which always require auth_admin authorization.

The implementation of the script is a bit peculiar in some ways, and some parts also seem incomplete. The one aspect that was important to check here was that the script must not act in dangerous ways on the file system, e.g. by using unsafe temporary files or by writing to locations that are under control of unprivileged users. We could not find issues of this kind at the time we reviewed it.

As the script can only be invoked with admin credentials and since there is no legit use case to lower this authentication requirement, we did not dig a lot deeper here and accepted the new Polkit policy. We want to keep an eye on this script, however, since it has some potential to be changed in ways that could harm the local system security.

8) Conclusion

Once more, we hope that with this post we have been able to give you some additional insights into our daily review work for openSUSE and SUSE products. Feel free to reach out to us if you have any questions about the content discussed in this article. We expect the spring issue of the spotlight series to be available in about three months from now.

9) References

• synce4l review bug
• fwupd 2.0 review bug
• tuned review bug
• iio-sensor-proxy review bug
• systemd-sysupdated review bug
• AppArmor aa-notify review bug

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

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)

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:

• Open Source Summit India
• Open Compliance Summit

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:

• Incredible India
• Delhi Tourism

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

• Travel India

🎤 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