Data breaches and cyber threats are becoming increasingly common and securing your personal and professional information has never been more critical.

Users transitioning from Windows to Linux through the Upgrade to Freedom campaign can use openSUSE’s tools to protect sensitive data, which include full disk encryption (FDE).

Full disk encryption during installation ensures maximum security. It safeguards all data on your hard drive by encrypting it and makes it unreadable without an decryption key. This level of protection is vital for preventing unauthorized access if your laptop or desktop is lost or stolen.

FDE with openSUSE is both user-friendly and powerful. The setup with advanced security features is easy.

For users seeking feature parity with Windows BitLocker, openSUSE offers Full Disk Encryption (FDE) secured by a TPM2 chip or a FIDO2 key. This advanced setup enhances security by storing encryption keys within the TPM, which ensures that only a trusted system configuration can unlock the disk. For a step-by-step guide on enabling this feature, read the Quickstart in Full Disk Encryption with TPM and YaST2 article.

Here’s a step-by-step guide to set up FDE on your system:

Step 1: Download and Boot openSUSE

• Visit get.opensuse.org to download the latest version of openSUSE Leap or Tumbleweed.
• Create a bootable USB drive using tools like balenaEtcher or another image writer.
• Restart your computer and boot from the USB drive to begin the installation process.

Step 2: Configure Encryption During Installation

• Once the installer starts, select your preferred language and keyboard layout.
• In the partitioning setup, choose Guided Setup with Encrypted LVM.
• Set a strong passphrase for encryption. This passphrase will be required every time the system boots. Use a mix of upper and lower case letters, numbers and special characters for optimal security.
• Proceed with the installation as directed by the installer.

Step 3: Verify Encryption Settings

After installation is complete and the system restarts, you’ll be prompted to enter your encryption passphrase. Once entered, openSUSE tools will decrypt the disk and boot normally. To confirm encryption is active:

• Open a terminal or console.
• Run the command lsblk -f to verify that your disk is listed with the encryption type (e.g., crypto_LUKS).

The output might look something similar to the following:

NAME        FSTYPE      FSVER LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                     
├─sda1      ext4        1.0     4a83v1e1-e8d2-4e38-815d-fd79j194f5   25G    30%    /
└─sda2      swap        1           d2e18c23-9w4b-4d26-p1s2-cm2sd64tx9de                
sdb                                                                                     
└─sdb1      crypto_LUKS 1           10bb2vca-81r4-418b-a2c4-e0f6585f2c7a                
  └─luks    ext4        1.0         8a9wka1b-7e9c-1a1f-a9f7-3c82x1e4e87f   150G    10%    /mnt/data

Step 4: Regular Backups

While FDE protects your data, it does not prevent data loss from hardware failure or accidental deletion. Regularly back up your data to an encrypted external drive or a secure cloud service to ensure its safety.

Post-Installation Encryption If you want to encrypt an existing partition after installation, visit the openSUSE wiki page about encryption.

Enhanced Security for Modern Challenges

Setting up full disk encryption on openSUSE not only protects your data but also aligns with the Upgrade to Freedom campaign’s mission of empowering users to maintain control over their hardware and privacy. By combining open-source software with good security practices, openSUSE ensures that users can confidently embrace a more secure digital future.

For additional guidance and community support, visit the openSUSE forums or join discussions at your local Linux user group.

Please be aware that some hardware configurations may require additional drivers or BIOS settings adjustments for full disk encryption to fully function properly. Check your device’s compatibility and update your firmware before proceeding.

The Reproducible-openSUSE (RBOS) project, which is a proof-of-concept fork of openSUSE, has reached a significant milestone after demonstrating a usable Linux distribution can be built with 100% bit-identical packages.

Reproducible builds ensure software can be rebuilt in an identical, bit-for-bit manner anywhere at any time using the same tools. This means that someone rebuilding the software from the same source code will get exactly the same results.

Why is this important? Because it’s a crucial aspect for supply-chain security.

This milestone for RBOS, led by openSUSE member Bernhard Wiedemann, advances software supply-chain security.

Reproducible builds allow us to confirm that the binaries used are correct, which ensures software has not been tampered with during the build process. By comparing identical outputs from different build environments, developers can detect issues such as accidental errors or malicious alterations. Without it, developers have to trust the build-process blindly or review binary-diffs manually, which is hard and time consuming.

In practice, reproducible-builds have found dozens of bug from race-conditions to compiling for incompatible CPUs with flags like via -march=native. Since Linux is a major component that operates the Internet, which is not only servers and routers but also client machines, improving security is vital.

The nice people at the nlnet foundation’s NGI0 Entrust fund sponsor open-source initiatives that improve the security of the internet. Wiedemann took on this 4-month-long project to create a fork of openSUSE that has 100% bit-reproducible packages. So far ring0 (aka bootstrap) and ring1 with 3,300 software packages have all successfully been patched and tested. Overall, the 16,000 source packages in openSUSE Factory have around 300 packages with issues left and information about this can be found in the following links:

• https://en.opensuse.org/openSUSE:Reproducible_openSUSE
• https://en.opensuse.org/openSUSE:Reproducible_openSUSE/Part1
• https://en.opensuse.org/openSUSE:Reproducible_openSUSE/Part2

Approximately 40 patches were needed and some more were completed before this project. Usually half of these patches are upstreamed.

With this, it is now possible to do a change in a toolchain package, rebuild everything and see exactly what changed as a result of the change.

RBOS does not receive security updates, so it is not recommended for productive use; it does however demonstrate how a full-bit-reproducible OS could be produced.

As patches make their way into openSUSE Factory, it should become easier to create a refresh in a year or two. Maybe it will become so little effort that each of the monthly Slowroll snapshots can be adapted into an RBOS-snapshot.

Ongoing work on a git-based OBS workflow could further support this effort, as tools like ‘git rebase’ can streamline and automate the process of integrating and updating patches.

How to test:

Grab the altimagebuild VM image with:

wget https://download.opensuse.org/repositories/home:/bmwiedemann:/reproducible:/distribution:/ring1/standard/src/altimagebuild-1-1.1.src.rpm

or

wget https://rb.zq1.de/RBOS/ring1/_build.standard.x86_64/altimagebuild/altimagebuild-1-1.1.x86_64.rpm

and run it as documented in https://en.opensuse.org/openSUSE:Reproducible_openSUSE/Part2#How_to_run_a_VM

Where does reproducible builds not help?

• bugs + backdoors in the source (e.g. xz-5.6.0) need source-code reviews
• backdoors in used build tools can be found with diverse-double-compilation = https://dwheeler.com/trusting-trust/ or be avoided with bootstrapping = https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/. Both of these methods only help if you have reproducible builds.

The milestone RBOS reached is an ongoing effort to provide more transparent, verifiable and secure software.

Dear Tumbleweed users and hackers,

From an engineering point of view, this week was exciting. Hopefully, you have seen on news.opensuse.org that the default LSM has been switched from AppArmor to SELinux for new installations. This has been a long ongoing effort. It took quite some time as we did not just want to release it onto users (as default) before we trusted it to work, with policies that make sense out of the box. There might still be rough edges, and there are almost certainly some policy issues to be uncovered in the next weeks with more workloads running on it. Considering MicroOS and Aeon have been configured with SELinux as their LSM for quite some time, there is also high confidence in this. And bringing MicroOS, Aeon and Tumbleweed closer together makes for easier administrative switching for those distributions, as they all behave equally.

Of course, that’s not all that changed this week though – we have published 4 snapshots (0206, 0207, 0209, and 0211), bringing you these changes:

• sssd 2.10.2
• pam_pkcs11 0.6.13: smartcard auth for PAM, CVE fix
• KDE Gear 24.12.2
• GNOME Shell 47.4
• KDE Plasma 6.3.0
• GIMP 3.0.0 RC3
• SELinux is the default LSM for new installs; AppArmor can still be selected during the installation process

The developers have submitted these changes, which are currently tested in the staging areas and by openQA:

• Pipewire 1.3.82
• Linux kernel 6.13.2
• Reworked kernel-firmware package, allowing them to be updated in smaller chunks
• Zypper 1.14.84: aborts dup in case of repositories not being available
• cURL 8.12.1
• Qemu 9.2.1
• PostgreSQL 12 is EOL and will be removed from the repository
• Boost 1.87
• glibc 2.41: please help work out the errors in https://build.opensuse.org/project/show/openSUSE:Factory:Staging:O
• Python 3.13 as the default Python interpreter: Pending issues can be seen at https://build.opensuse.org/project/show/openSUSE:Factory:Staging:A

The romantics out there probably already know that tomorrow February 14 is “I Love Free Software” day. But I thought I’d give it a mention anyway, as a reminder to celebrate software freedom, which can’t be taken for granted.

Also this February marks the 20th anniversary of me installing SUSE Linux 9.2 with KDE 3 and making it my default operating system – which it has been ever since. And for some 15 years it’s been my only PC operating system. Previously I had made failed attempts at switching to GNU/Linux with Ubuntu 4.10 and Fedora Core 3, but SUSE with KDE on top in all its glory was love at first sight.

Throughout this time I’ve been active in the community to varying degrees, maintaining opensuse-guide.org, doing translations of openSUSE and KDE, supporting users on forums and IRC, beta testing, bug reports, doing Kommander scripts for easy codec installation and Compiz installation, promoting the distro and other less technical tasks.

It hasn’t been all clear sailing though, there have been many uphill battles along the way, such as ximian influence, ZMD package management disaster, Microsoft patent deal, KDE 4.0 (dot oh), layoffs affecting among lots others one of my all-time favourite SUSE developers Beineri, ALP, a whole series of acquisitions by more or less dubious parent companies and probably more struggles that I’ve forgotten.

Thanks to everyone in this community and I hope to be with you for another twenty years.

Tumbleweed is planning to adopt SELinux as the default Linux Security Module (LSM) for new installations in the nearterm.

The transition was announced on the mailing list in July and marks a significant development for the rolling release. A new announcement on the factory mailing list yesterday confirmed that starting with Tumbleweed snapshot 20250211. This change also applies to the openSUSE Tumbleweed minimalVM, which will ship with SELinux enabled by default.

“Users installing openSUSE Tumbleweed via the ISO image will see SELinux in enforcing mode as default option in the installer,” wrote SELinux Security Engineer Cathy Hu in the email announcement. “If the user prefers to use AppArmor instead of SELinux, they are able to change the selection to AppArmor manually in the installer.”

Tumbleweed has used AppArmor as its default LSM. This marks a shift in the default Mandatory Access Control (MAC) system for new installations as SELinux replaces AppArmor as the default choice. SELinux will be enabled in enforcing mode by default only for new installations. Existing installations will not be affected by the change and will retain the option to select AppArmor during installation if they prefer.

The switch to install SELinux by default is in early implementation and aligns with a decision to grow adoption of SELinux for both SUSE and openSUSE. It’s expected to increase security by confining more services by default. SELinux is known for its rich security features and widespread use in enterprise environments.

The move is expected to bring tighter access controls to Tumbleweed. Users may encounter bugs or issues, but openQA tests for Tumbleweed have played a key role in identifying and resolving potential problems in the early adoption phase.

Contributors were encouraged to report any bugs that arise and can refer to the SELinux bug report guide for help.

There is no plan to change the kernel configuration yet, with the installer handling SELinux activation on new installations.

The community response to this change has been largely positive, though some users, particularly those who rely on highly customized AppArmor profiles, expressed concerns. AppArmor will continue to be supported and users can opt to install it manually if desired.

The change will not affect the Leap 15.x release. The first boot might take a little time. Expect updates for SELinux to roll out with fixes and tweeks over the next several weeks.

Tumbleweed has adopted SELinux as the default Linux Security Module (LSM) for new installations after a recent snapshot.

The transition was announced on the mailing list in July and marks a significant development for the rolling release. A new announcement on the factory mailing list yesterday confirms this to take place with the release of Tumbleweed snapshot 20250211. This change also applies to the openSUSE Tumbleweed minimalVM, which will ship with SELinux enabled by default.

“Users installing openSUSE Tumbleweed via the ISO image will see SELinux in enforcing mode as default option in the installer,” wrote SELinux Security Engineer Cathy Hu in the email announcement. “If the user prefers to use AppArmor instead of SELinux, they are able to change the selection to AppArmor manually in the installer.”

Tumbleweed has used AppArmor as its default LSM. This marks a shift in the default Mandatory Access Control (MAC) system for new installations as SELinux replaces AppArmor as the default choice. SELinux will be enabled in enforcing mode by default only for new installations. Existing installations will not be affected by the change and will retain the option to select AppArmor during installation if they prefer.

The switch to install SELinux by default is going through implementation and aligns with a decision to grow adoption of SELinux for both SUSE and openSUSE. It’s expected to increase security by confining more services by default. SELinux is known for its rich security features and widespread use in enterprise environments.

The move is expected to bring tighter access controls to Tumbleweed. Users may encounter bugs or issues, but openQA tests for Tumbleweed have played a key role in identifying and resolving potential problems in the early adoption phase.

Contributors were encouraged to report any bugs that arise and can refer to the SELinux bug report guide for help.

There is no plan to change the kernel configuration yet, with the installer handling SELinux activation on new installations.

The community response to this change has been largely positive, though some users, particularly those who rely on highly customized AppArmor profiles, expressed concerns. AppArmor will continue to be supported and users can opt to install it manually if desired.

The change does not affect the Leap 15.x release. The first boot might take a little time. Expect updates for SELinux to roll out with fixes and tweeks over the next several weeks.

Developers of the openSUSE community continue their commitment toward improving legal compliance and software transparency with the release of the Cavil Legal Text dataset on Hugging Face.

This dataset is designed to enhance automated legal text classification, which reduces manual review efforts and improves accuracy in identifying legal snippets within software projects.

“Open sourcing the dataset is cooler than just open sourcing the weights to a model fine-tuned by us because everyone can use it to make their own versions based on whatever open weight model they want,” said Sebastian Riedel, one of the developers behind the project.

The Cavil Legal Text dataset supports Cavil, which is a system built to automate the extraction and classification of potential legal texts in software packages. By leveraging AI, Cavil minimizes false positives when detecting license information, copyright statements and compliance-related content; this ensures that legal experts can focus on critical cases rather than sorting through large amounts of irrelevant data.

With 150,000 labeled samples, the dataset is instrumental in training AI models to distinguish between legal and non-legal text with a high degree of accuracy. It enables legal review workflows by improving text classifications, pattern matching and reduces the dependency of human intervention.

Cavil consists of three key parts: a user-friendly web application with a REST API, a job queue for handling background tasks like pattern matching and analysis, and an AI-powered text classification server that continually improves its ability to recognize legal texts. All these components interact seamlessly through PostgreSQL and HTTP; this allows human experts and lawyers to efficiently validate software licenses at scale.

Currently, Cavil employs a Character-level Convolutional Neural Network (CNN) model in production due to its efficiency and compatibility with existing infrastructure. However, an alternative approach using fine-tuned LLMs is under exploration. The LLM-lawyer experiment suggests that large language models could provide more adaptable and context-aware classifications with less frequent retraining.

The dataset is licensed under GPL-2.0-or-later and is freely available on Hugging Face for researchers, developers, and compliance teams to explore and contribute. Open-source contributors can refine AI classification models, propose new legal text patterns, and support the ongoing improvement of automated legal compliance in software projects.

Those interested can explore the dataset on Hugging Face, read the Cavil documentation, experiment with Llama-3 through the Llama-Lawyer repository, and contribute to openSUSE’s compliance efforts through GitHub.

The promising new package management tool Myrlyn now includes a much-requested feature: repository configuration. Users can now easily manage their repos, adjust priorities, enable auto-refresh, and even add well-known community repositories like packman, openh264, libdvdcss, and NVIDIA; all with Myrlyn’s streamlined UI!

Key Features:

• View repo details, including priority, auto-refresh status, and URL.
• Modify repo settings directly from the interface.
• Add custom repos with libzypp variables like $releasever.
• Select community repos automatically tailored for Leap, Tumbleweed or Slowroll.
• Enable read-only mode for non-privileged users.

Some users have been exclusively managing their systems with Myrlyn, which showcases its reliability. Myrlyn was developed during Hack Week 24 and is a standalone Qt-based package manager, free from YaST dependencies.

Ready to configure your repos? Head to Extras → Configure Repositories (Ctrl+Shift+O) and give it a spin!