All posts by corbet

Villa: Will the new judicial ruling in the Vizio lawsuit strengthen the GPL?

Post Syndicated from corbet original https://lwn.net/Articles/958682/

Luis Villa writes
about the recent ruling
in the Software Freedom Conservancy’s
GPL-violation lawsuit against Vizio, wherein the judge refused to agree
that the SFC lacks standing to sue.

In some sense, not much has changed: if you were obligated to
comply with the GPL two weeks ago, you have the same obligations
today. If you didn’t have obligations then, you don’t have them
now.

What has changed is who can enforce those obligations. Two weeks
ago, we mostly believed that enforcement could only come from the
authors of the code. Those folks rarely had time, money, or
interest for litigation, and they might also face a lot of pressure
from their peers and employers to avoid litigation.

If this ruling holds up at the end of the case, the number of
potential enforcers just went way up.

Please welcome Daroc Alden

Post Syndicated from corbet original https://lwn.net/Articles/958444/

When, at the beginning of November, we posted an open position at LWN, we were only so
hopeful; experience has shown that finding writers who are both capable of
and interested in writing our sort of material is a challenging task. This
time, though, hope was justified: we got a surprising number of
applications from highly qualified applicants. The hardest part of the
task has, instead, been narrowing down the choice to a hiring decision.

We are pleased to announce that Daroc Alden has just joined LWN’s staff.

Daroc is a programmer from New England, where they live with their
spouse and their cat. They graduated with a Master’s degree in Computer
Science from the University of New Hampshire. In their spare time, they
enjoy fiction writing and musicals. They are especially interested in
programming language theory and implementation.

Daroc will be taking on some of the load of keeping LWN interesting while
helping us to expand our content mix in the areas that our readers are
interested in. Please give them your support as they come up to speed
within our operation. We are looking forward to having Daroc as part of a
reinforced and more energetic LWN going forward.

Kicinski: netdev in 2023

Post Syndicated from corbet original https://lwn.net/Articles/958518/

Networking maintainer Jakub Kicinski (along with several collaborators) has
put up a summary of
what happened in the kernel’s network stack
during 2023.

Throughout those releases netdev patch handlers (DaveM, Jakub,
Paolo) applied 7243 patches, and the resulting pull requests to
Linus described the changes in 6398 words. Given the volume of work
we cannot go over every improvement, or even cover networking
sub-trees in much detail (BPF enhancements… wireless work on WiFi
7…). We instead try to focus on major themes, and developments we
subjectively find interesting.

Wine 9.0 released

Post Syndicated from corbet original https://lwn.net/Articles/958443/

Version
9.0
of the Wine Windows-compatibility system has been released.
“This release represents a year of development effort and over 7,000
individual changes. It contains a large number of improvements that are
listed below. The main highlights are the new WoW64 architecture and the
experimental Wayland driver.
”

A glitch in the merge window

Post Syndicated from corbet original https://lwn.net/Articles/958424/

On January 13, Linus Torvalds let
it be known
that he had lost power due to the bad weather in the US
Pacific Northwest. As of this writing, he has not yet resurfaced, so the
6.8 merge window has ground to a halt.

There’s apparently about 100k people without power, and I doubt our
neighborhood is the priority, so I expect to be without power for
some time still. I hope I’m wrong, but a few years ago it took more
than a week to restore power due to all the downed trees. It’s
hopefully nowhere near that, but..

Security updates for Tuesday

Post Syndicated from corbet original https://lwn.net/Articles/958416/

Security updates have been issued by Gentoo (KTextEditor, libspf2, libuv, and Nettle), Mageia (hplip), Oracle (container-tools:4.0, gnutls, idm:DL1, squid, squid34, and virt:ol, virt-devel:rhel), Red Hat (.NET 6.0, krb5, python3, rsync, and sqlite), SUSE (chromium, perl-Spreadsheet-ParseXLSX, postgresql, postgresql15, postgresql16, and rubygem-actionpack-5_1), and Ubuntu (binutils, libspf2, libssh2, mysql-5.7, w3m, webkit2gtk, and xerces-c).

OpenSUSE Leap 16 is coming

Post Syndicated from corbet original https://lwn.net/Articles/958319/

The openSUSE project has confirmed
that there will be a successor to openSUSE Leap 15, but is not sharing
a lot of details at this point.

The transition to Leap 16 is not just a numerical step-up but
symbolizes a significant path forward in technology and user
experiences. The future of openSUSE Leap is based on the innovative
concept of SUSE’s Adaptable Linux Platform.

The Adaptable Linux Platform powers the next-generation openSUSE
Leap, Leap Micro, and SUSE solutions. It makes distributions more
adaptable and suitable for cloud-native workloads while also being
capable of handling a rapid pace of innovation.

Stawinski: How We Executed a Critical Supply Chain Attack on PyTorch

Post Syndicated from corbet original https://lwn.net/Articles/958318/

John Stawinski IV describes,
in detail, how he and a partner were able to compromise the security of the
heavily used PyTorch project.

Our exploit path resulted in the ability to upload malicious
PyTorch releases to GitHub, upload releases to AWS, potentially add
code to the main repository branch, backdoor PyTorch dependencies –
the list goes on. In short, it was bad. Quite bad.

As we’ve seen before with SolarWinds, Ledger, and others, supply
chain attacks like this are killer from an attacker’s
perspective. With this level of access, any respectable
nation-state would have several paths to a PyTorch supply chain
compromise.

[$] Rust and C filesystem APIs

Post Syndicated from corbet original https://lwn.net/Articles/958072/

As the Rust-for-Linux project
advances, the kernel is gradually
accumulating abstraction layers that enable Rust code to interface with the
existing C code. As the discussion around the set of filesystem
abstractions
posted by Wedson Almeida Filho in December shows, though,
there is some tension between two approaches to the design of those
abstractions. The approach favored by most of the kernel’s C programmers
looks set to win out, but this is a discussion that is likely to return as
the use of Rust in the kernel grows.

[$] The first half of the 6.8 merge window

Post Syndicated from corbet original https://lwn.net/Articles/957188/

The 6.8 merge window has gotten off to a relatively slow start; reasons for
that include a significant scheduler performance regression that Linus
Torvalds stumbled
into
and has spent time tracking down. Even so, 4,282 non-merge
changesets have found their way into the mainline repository for the 6.8
release as of this writing. These commits have brought a number of
significant changes and new features.

Information on the SourceHut outage

Post Syndicated from corbet original https://lwn.net/Articles/958125/

Users of SourceHut will have noticed that the site has been unreachable;
Drew DeVault has now posted a report on
what is happening
(it’s a distributed denial-of-service attack) and
what is being done to recover.

We deal with ordinary DDoS attacks in the normal course of
operations, and we are generally able to mitigate them on our
end. However, this is not an ordinary DDoS attack; the attacker
posesses considerable resources and is operating at a scale beyond
that which we have the means to mitigate ourselves. In response,
before we could do much ourselves to understand or mitigate the
problem, our upstream network provider null routed SourceHut
entirely, rendering both the internet at large, and SourceHut
staff, unable to reach our servers.

OpenSSH announces DSA-removal timeline

Post Syndicated from corbet original https://lwn.net/Articles/958048/

For those of you still using DSA keys with SSH: the project has announced
its plans to remove support for that algorithm around the beginning of
2025.

The only remaining use of DSA at this point should be deeply legacy
devices. As such, we no longer consider the costs of maintaining
DSA in OpenSSH to be justified. Moreover, we hope that OpenSSH’s
final removal of this insecure algorithm accelerates its
deprecation in other SSH implementations and allows maintainers of
cryptography libraries to remove it too.

[$] The kernel “closure” API

Post Syndicated from corbet original https://lwn.net/Articles/957187/

The data structure known as a “closure” first found its way into the
mainline kernel with the addition of bcache in the 3.10 development
cycle. With the advent of bcachefs in
6.7, though, it acquired a second user and was moved to the kernel’s
lib directory, making it available to other kernel users as well.
The documentation of closures in the source is better than that of many
things in the kernel, but there is still room for a gentler introduction.

Stable kernel 4.14.336

Post Syndicated from corbet original https://lwn.net/Articles/957351/

The 4.14.336 stable kernel update has been
released with a small handful of fixes; this is the end of the line for the
4.14 stable series:

This is the LAST 4.14.y kernel to be released. It is now
officially end-of-life. Do NOT use this kernel version anymore,
please move to a newer one, as shown on the kernel.org releases
page.

All users of the 4.14 kernel series must upgrade. But then, move
to a newer release. If you are stuck at this version due to a
vendor requiring it, go get support from that vendor for this
obsolete kernel tree, as that is what you are paying them for 🙂

Stable kernel 4.14.336 (and others)

Post Syndicated from corbet original https://lwn.net/Articles/957351/

The 4.14.336 stable kernel update has been
released with a small handful of fixes; this is the end of the line for the
4.14 stable series:

This is the LAST 4.14.y kernel to be released. It is now
officially end-of-life. Do NOT use this kernel version anymore,
please move to a newer one, as shown on the kernel.org releases
page.

All users of the 4.14 kernel series must upgrade. But then, move
to a newer release. If you are stuck at this version due to a
vendor requiring it, go get support from that vendor for this
obsolete kernel tree, as that is what you are paying them for 🙂

Update: 6.6.11 and 6.1.72 have also now been released.