All posts by jzb

Red Hat Enterprise Linux 10 released

Post Syndicated from jzb original https://lwn.net/Articles/1021827/

Red Hat has announced
the release of Red Hat Enterprise Linux (RHEL) 10. A blog post
accompanying the release provides details on some of the more notable
features, such as encrypted DNS, a developer preview of RHEL 10
for RISC-V,
and image
mode
for RHEL using bootc.

Image mode for RHEL lets you deploy your OS as a bootc image to your
hardware, virtual machine or cloud, and then layer your app on top of
it. That’s a far less complex operation than traditional packaged
deployments, and it gives developers and image maintainers a common
experience and total control over their environment.

RHEL 10 includes the 6.12.0 kernel, GCC 14.2, GNU
Binutils 2.41, GNU C Library (glibc) 2.39, Python 3.12,
Perl 5.40, and more. See the release
notes
for a full list of changes. LWN covered
CentOS Stream 10 in December, which provided an early look
at what would be in the RHEL 10 release.

Go cryptography security audit (The Go Blog)

Post Syndicated from jzb original https://lwn.net/Articles/1021745/

Roland Shoemaker has published a blog post about a
recent security audit of the cryptography packages shipped as part of
the Go standard library. The audit, performed by the Trail of Bits security firm,
uncovered one low-severity vulnerability in the legacy Go+BoringCrypto
integration, as well as a handful of informational findings.

During the review, there were a number of questions about our
cgo-based Go+BoringCrypto integration, which provides a FIPS 140-2
compliant cryptography mode for internal usage at Google. The
Go+BoringCrypto code is not supported by the Go team for external use,
but has been critical for Google’s internal usage of Go.

The Trail of Bits team found one vulnerability and one non-security relevant bug,
both of which were results of the manual memory management required to
interact with a C library. Since the Go team does not support usage of
this code outside of Google, we have chosen not to issue a CVE or Go
vulnerability database entry for this issue, but we fixed it in the Go 1.25 development
tree
.

The entire report is available
as a PDF for those who enjoy a little light security reading.

An Asahi Linux 6.15 progress report

Post Syndicated from jzb original https://lwn.net/Articles/1021484/

The Asahi Linux
project, which supports Linux on Apple Silicon Macs, has published a
progress report ahead of the 6.15 kernel’s release.

We are pleased to announce that our graphics driver userspace API
(uAPI) has been merged into the Linux kernel. This major milestone
allows us to finally enable OpenGL, OpenCL and Vulkan support for
Apple Silicon in upstream Mesa. This is the only time a graphics
driver’s uAPI has been merged into the kernel independent of the
driver itself, which was kindly allowed by the kernel graphics
subsystem (DRM) maintainers to facilitate upstream Mesa enablement
while the required Rust abstractions make their way upstream. We are
grateful for this one-off exception, made possible with close
collaboration with the kernel community.

Oniux: kernel-level Tor isolation for Linux applications

Post Syndicated from jzb original https://lwn.net/Articles/1021354/

The Tor project has announced
the oniux utility which provides Tor network isolation, using Linux
namespaces, for third-party applications.

Namespaces are a powerful feature that gives us the ability to
isolate Tor network access of an arbitrary application. We put each
application in a network namespace that doesn’t provide access to
system-wide network interfaces (such as eth0), and instead provides a
custom network interface onion0.

This allows us to isolate an arbitrary application over Tor in the
most secure way possible software-wise, namely by relying on a
security primitive offered by the operating system kernel. Unlike
SOCKS, the application cannot accidentally leak data by failing to
make some connection via the configured SOCKS, which may happen due to
a mistake by the developer.

The Tor project cautions that oniux is considered experimental as
the software it depends on, such as Arti and
onionmasq,
are still new.

[$] The future of Flatpak

Post Syndicated from jzb original https://lwn.net/Articles/1020571/

At the Linux Application
Summit
(LAS) in April, Sebastian Wick said that, by many metrics, Flatpak is doing great. The Flatpak
application-packaging format is popular with upstream developers, and
with many users. More and more applications are being published in the
Flathub application store, and the
format is even being adopted by Linux distributions like
Fedora. However, he worried that work on the Flatpak project itself
had stagnated, and that there were too few developers able to review
and merge code beyond basic maintenance.

Podman 5.5.0 released

Post Syndicated from jzb original https://lwn.net/Articles/1021217/

Version
5.5.0
of the Podman container-management tool has been
released. Notable features include the addition of a podman machine cp command to copy files into a running Podman
VM
, a podman artifact extract command to copy
contents of an OCI
artifact
to disk, and a --mount=artifact option to mount
OCI artifacts into containers. See the release announcement for a full
list of improvements and bug fixes.

Security updates for Wednesday

Post Syndicated from jzb original https://lwn.net/Articles/1021199/

Security updates have been issued by AlmaLinux (emacs, firefox, gnutls, java-17-openjdk, java-21-openjdk, osbuild-composer, python39:3.9, and thunderbird), Arch Linux (screen), Debian (varnish), Fedora (chromium), Gentoo (Atop, FreeType, and Spidermonkey), Mageia (java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk, java-latest-openjdk and postgresql15, postgresql13), Oracle (389-ds-base, emacs, firefox, kernel, libsoup, libtiff, mod_auth_openidc:2.3, nodejs:20, nodejs:22, osbuild-composer, python39:3.9, qemu-kvm, ruby, ruby:3.1, ruby:3.3, and thunderbird), Red Hat (.NET 8.0, .NET 9.0, avahi, buildah, corosync, delve and golang, exiv2, expat, firefox, ghostscript, gimp, git, grafana, gvisor-tap-vsock, java-21-openjdk, kernel, kernel-rt, libarchive, libjpeg-turbo, libsoup, libsoup3, libxslt, mod_auth_openidc, nginx, nginx:1.22, nginx:1.24, nodejs22, nodejs:20, nodejs:22, opentelemetry-collector, osbuild-composer, perl, php, php:8.2, php:8.3, podman, python-jinja2, redis, redis:7, rhc, ruby:2.5, skopeo, sqlite, thunderbird, tomcat, tomcat9, valkey, vim, xorg-x11-server-Xwayland, xterm, xz, yelp, and yggdrasil), Slackware (screen), SUSE (apparmor, dirmngr, gimp, golang-github-prometheus-node_exporter, java-11-openj9, java-17-openj9, java-21-openj9, libxmp-devel, python311-Django4, rabbitmq-server313, rke2, and transfig), and Ubuntu (abseil and open-vm-tools).

Nextcloud claims Google is being anticompetitive

Post Syndicated from jzb original https://lwn.net/Articles/1021016/

Nextcloud provides an
open-source collaboration platform called Nextcloud Hub, which includes file-sharing and syncing
features. The company has written
a blog post explaining that Google has revoked a critical permission
from the Nextcloud Files app for Android that allows it to sync files
to Nextcloud Hub.

Google is stating security concerns as a reason for revoking the
permission. This is hard to believe for us. Nextcloud has had this
feature since its inception in 2016, and we have never heard about any
security concerns from Google about it. Moreover, several Big Tech
apps as well as Google’s own still have this. What we think: Google
owning the platform means they can and are giving themselves
preferential treatment.

Despite multiple appeals since mid-2024, Google has refused to
reinstate the permission, blocking automated Nextcloud file uploads
for millions of users.

The Nextcloud
app
available via F-Droid does not have this limitation, but the
post notes that that is not an option for many users.

Multiple security issues in Screen

Post Syndicated from jzb original https://lwn.net/Articles/1020901/

The SUSE Security Team has published
an article detailing several security
issues
it has uncovered with GNU Screen. This includes
a local root exploit when Screen is shipped setuid-root, as it is in
some Linux and BSD distributions. The security team also reports problems
in coordinating disclosure
with the upstream Screen project.

We are not satisfied with how this coordinated disclosure developed,
and we will try to be more attentive to such problematic situations
early on in the future. This experience also sheds light on the
overall situation of Screen upstream. It looks like it suffers from a
lack of manpower and expertise, which is worrying for such a
widespread open source utility. We hope this publication can help to
draw attention to this and to improve this situation in the future.

The article includes a table
of operating systems, screen versions, and which vulnerabilities they
may be affected by.

Guix project migrating to Codeberg

Post Syndicated from jzb original https://lwn.net/Articles/1020885/

The Guix project has announced
that it is migrating all of its Git repositories, as well as bug
tracking and patch tracking, from Savannah to the Codeberg Git forge.

As a user, the main change is that your channels.scm
configuration files, if they refer to the
git.savannah.gnu.org URL, should be changed to refer to
https://codeberg.org/guix/guix.git once migration is
complete. But don’t worry: guix pull will tell you
if/when you need to update your config files and the old URL will
remain a mirror for at least a year anyway.

The motivation for the move, which is spelled out in a Guix
Consensus Document
(GCD), is to improve the contribution
experience and improve quality assurance efforts. Migration of Git
repositories should be completed by June 7, though they will
continue to be mirrored on Savannah until “at least” May 2026. LWN covered Guix in February 2024.

[$] The last of YaST?

Post Syndicated from jzb original https://lwn.net/Articles/1020408/

The announcement
of the openSUSE Leap 16.0 beta contained something of a
surprise—along with the usual set of changes and updates, it
informed the community of the retirement of “the traditional YaST
stack
” from Leap. The YaST (“Yet another Setup Tool”)
installation and configuration utility has been a core part of the
openSUSE distribution since its inception
in 2005, and part of SUSE Linux since 1996. It will not, immediately,
be removed from the openSUSE Tumbleweed rolling-release
distribution, but its future is uncertain and its fate is up to the larger
community to decide.

Albertson: OSL’s path to sustainability

Post Syndicated from jzb original https://lwn.net/Articles/1020668/

Lance Albertson writes that the
Oregon State University Open Source Lab has been funded for the next
year, following his announcement in April
that the future of OSL was in jeopardy. OSL is now focusing on
becoming self-sustainable long term.

The recent support was amazing for our immediate team needs. But
for the OSL to thrive long-term, we need a sustainable financial
foundation. This is crucial, as the university expects units like ours
to become self-sufficient beyond this current year.

So, our big focus this next year is locking in ongoing support –
think annualized pledges, different kinds of regular income, and other
recurring help. This is vital, especially with potential new data
center costs and hardware needs. Getting this right means we can stop
worrying about short-term funding and plan for the future: investing
in our tech and people, growing our awesome student programs, and
serving the FOSS community. We’re looking for partners, big and small,
who get why foundational open source infrastructure matters and want
to help us build this sustainable future together.

GNOME Foundation announces new executive director

Post Syndicated from jzb original https://lwn.net/Articles/1020619/

The GNOME Foundation has announced
the hiring of Steven Deobald as its new executive director.

Steven has been a GNOME user since 2002 and has been involved in
numerous free software initiatives throughout his career. His
professional background spans technical leadership, cooperative
business development, and nonprofit work. Having worked with projects
like XTDB and Endatabas, he brings valuable
experience in open source product development. Based in Halifax,
Canada, Steven is well-positioned to collaborate with our global
community across time zones.

[$] Debian’s AWKward essential set

Post Syndicated from jzb original https://lwn.net/Articles/1019898/

The Debian project has the concept of essential
packages
, which provide the bare minimum functionality considered
absolutely necessary (or “essential”) for a system to
function. Packages tagged as essential, and the packages that are
required by the set of essential packages, are always installed as
part of a Debian system. However, Debian’s packaging rules do not
require developers to explicitly declare dependencies on that set of
packages (the essential set) but they can simply rely on the fact that those
will always be present. That means that changing the essential set, as
the project may wish to do occasionally, is more complicated than it
should be. This came to light recently when a Debian developer asked
what might be required to remove mawk to slim down
the project’s container images.

Deepin Desktop removed from openSUSE

Post Syndicated from jzb original https://lwn.net/Articles/1020407/

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.

Security updates for Wednesday

Post Syndicated from jzb original https://lwn.net/Articles/1020404/

Security updates have been issued by Fedora (incus and nodejs20), Red Hat (freetype, kernel, kernel-rt, libsoup, libtiff, redis, redis:6, and thunderbird), SUSE (apparmor, chromium, grafana, ImageMagick, java-11-openjdk, java-17-openjdk, libsoup, libsoup2, libxslt, opensaml, rabbitmq-server, rubygem-rack-1_6, sqlite3, and thunderbird), and Ubuntu (kernel, libfcgi, libraw, libsoup2.4, linux, linux-aws, linux-aws-5.15, linux-gcp, linux-gke, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-intel-iotg, linux-intel-iotg-5.15, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-igx, linux-oracle, linux-oracle-5.15, linux-raspi, linux, linux-aws, linux-aws-5.4, linux-azure-5.4, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm, linux-kvm, linux-oracle, linux-oracle-5.4, linux, linux-aws, linux-aws-6.8, linux-gcp, linux-gcp-6.8, linux-gke, linux-gkeop, linux-hwe-6.8, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-oem-6.8, linux-oracle, linux-oracle-6.8, linux, linux-aws, linux-aws-hwe, linux-gcp, linux-gcp-4.15, linux-hwe, linux-kvm, linux-oracle, linux, linux-aws, linux-gcp, linux-gcp-6.11, linux-hwe-6.11, linux-lowlatency, linux-lowlatency-hwe-6.11, linux-oracle, linux-raspi, linux-aws-fips, linux-fips, linux-gcp-fips, linux-azure, linux-azure, linux-azure-4.15, linux-azure, linux-azure-5.15, linux-azure-fde, linux-azure-fde-5.15, linux-azure, linux-azure-6.11, linux-azure-6.8, linux-azure-fips, linux-intel-iot-realtime, linux-realtime, linux-oem-6.11, linux-raspi, linux-realtime, python, python-scrapy, and ruby-carrierwave).

Mission Center 1.0.0 released

Post Syndicated from jzb original https://lwn.net/Articles/1020269/

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.

Celebrating 20 Years of the OASIS Open Document Format

Post Syndicated from jzb original https://lwn.net/Articles/1019672/

The Document
Foundation
is celebrating
the 20th anniversary of the ratification of the Open Document Format
(ODF) as an OASIS
standard.

Two decades after its approval in 2005, ODF is the only open
standard for office documents, promoting digital independence,
interoperability and content transparency worldwide. […]

To celebrate this milestone, from today The Document Foundation
will be publishing a series of presentations and documents on its blog
that illustrate the unique features of ODF, tracing its history from
the development and standardisation process through the activities of
the Technical Committee for the submission of version 1.3 to ISO and
the standardisation of version 1.4.