Hírolvasó

The SUSE Security Team has announced the removal of the Deepin Desktop from openSUSE due to violations of the project's packaging policy.

The discovery of the bypass of the security whitelistings via the deepin-feature-enable package marks a turning point in our assessment of Deepin. We don't believe that the openSUSE Deepin packager acted with bad intent when he implemented the "license agreement" dialog to bypass our whitelisting restrictions. The dialog itself makes the security concerns we have transparent, so this does not happen in a sneaky way, at least not towards users. It was not discussed with us, however, and it violates openSUSE packaging policies. Beyond the security aspect, this also affects general packaging quality assurance: the D-Bus configuration files and Polkit policies installed by the deepin-feature-enable package are unknown to the package manager and won't be cleaned up upon package removal, for example. Such bypasses are not deemed acceptable by us.

The combination of these factors led us to the decision to remove the Deepin desktop completely from openSUSE Tumbleweed and from the future Leap 16.0 release. In openSUSE Leap 15.6 we will remove the offending deepin-feature-enable package only. It is a difficult decision given that the Deepin desktop has a considerable number of users. We firmly believe the Deepin packaging and security assessment in openSUSE needs a reboot, however, ideally involving new people that can help get the Deepin packages into shape, establish a relationship with Deepin upstream and keep an eye on bugfixes, thus avoiding fruitless follow-up reviews that just waste our time. In such a new setup we would be willing to have a look at all the sensitive Deepin components again one by one.

The announcement goes into detail about the bypass of openSUSE packaging policy and the history of security reviews of Deepin components. It also offers guidance on continuing to use Deepin Desktop on openSUSE.

Following its recent introduction on tech@ [See earlier article], David Gwynne (dlg@) has committed bpflogd(8) to the tree:

Read more…

OpenSSL 3.0 performs significantly worse than alternative SSL libraries, forcing organizations to provision more hardware just to maintain existing throughput. This raises important questions about performance, energy efficiency, and operational costs.

Examining alternatives—BoringSSL, LibreSSL, WolfSSL, and AWS-LC—reveals a landscape of trade-offs. Each offers different approaches to API compatibility, performance optimization, and QUIC support. For developers navigating the modern SSL ecosystem, understanding these trade-offs is crucial for optimizing performance, maintaining compatibility, and future-proofing their infrastructure.

For the past two decades, as more USENIX conferences have joined the USENIX calendar by focusing on specific topics that grew out of ATC itself, attendance at ATC has steadily decreased to the point where there is no longer a critical mass of researchers and practitioners joining us. Thus, after many years of experiments to adapt this conference to the ever-changing tech landscape and community, the USENIX Board of Directors has made the difficult decision to sunset USENIX ATC.

Many important technologies first saw the light of day at this event.

Following its recent introduction on tech@ [See earlier article], David Gwynne (dlg@) has committed lldpd(8) to the tree:

Read more…

Damien Miller (djm@) has completed the planned [See previous articles] removal of DSA signature support from OpenSSH:

The editors would like to encourage our readers to arrange a proper wake for this one.
Please keep going until we can be quadruply sure it's all gone.

Version 1.0.0 of Mission Center, a system-monitoring application, has been released. Notable changes in this release include the addition of SMART data for SATA and NVMe devices, display of per-process network usage, as well as a redesigned Apps Page that provides more information about applications and processes. Mission Center's backend application for obtaining system data has been renamed from the Gatherer to Magpie, and is now available as a standalone executable and libraries that can be used by other applications.

Linux systems can have large filesystems; trying to keep up with the stream of fanotify filesystem-monitoring notifications for them can be a struggle. Fanotify is one of a few ways to monitor accesses to filesystems provided by the kernel. Song Liu led a discussion on how to improve in-kernel filtering of fanotify events to a joint session of the filesystem and BPF tracks at the 2025 Linux Storage, Filesystem, Memory-Management, and BPF Summit. He wants to combine the best parts of a few different approaches to efficiently filter filesystem events.