All posts by jake

Security updates for Friday

Post Syndicated from jake original https://lwn.net/Articles/951801/

Security updates have been issued by Debian (webkit2gtk), Fedora (microcode_ctl, pack, and tigervnc), Slackware (gimp), SUSE (frr, gcc13, go1.20, go1.20-openssl, go1.21, go1.21-openssl, libnbd, libxml2, python-Pillow, python-urllib3, and xen), and Ubuntu (intel-microcode and openvpn).

[$] Faster kernel testing with virtme-ng

Post Syndicated from jake original https://lwn.net/Articles/951313/

Building new kernels and booting into them is an unavoidable—and
time-consuming—part of kernel development. Andrea Righi works for
Canonical on the Ubuntu kernel team, so he does a lot of that and wanted to
find a way to speed up the task. To that end, he has been working
on virtme-ng, which is a
way to boot a new kernel in a virtual machine, and it does
so quickly. He came to the 2023
Linux Plumbers Conference
(LPC) in Richmond, Virginia to introduce the
project to a wider audience.

[$] Using Common Lisp in Emacs

Post Syndicated from jake original https://lwn.net/Articles/951090/

Lisp
is one of the oldest programming languages still in use today, but it has
evolved in multiple directions over its more than 60-year history. Two of
the more prominent descendants, Common Lisp and Emacs Lisp (or Elisp),
are fairly closely related at some level, but there is still something of a
divide between them. Some recent discussion in the emacs-devel mailing
list have shown that some elements from Common Lisp are not completely
welcome in
Elisp—at least in the code that is maintained by the Emacs project itself.

Kernel prepatch 6.7-rc1

Post Syndicated from jake original https://lwn.net/Articles/951201/

Linus Torvalds has released
6.7-rc1, thus closing the merge window
for this release. It is the largest merge window ever, but some of that
was due to the bcachefs history that came with merge of that filesystem.

But 6.7 is pretty
big in other ways too, with

12678 files changed, 838819 insertions(+), 280754 deletions(-)

which is also bigger than those historically big releases [4.9, 5.8 and
5.13]. And that’s
not due to bcachefs, that’s actually mainly due to ia64 removal and a
lot of GPU support (notably lots of AMD GPU header files again – lots
and lots of lines, but there’s support for new nvidia cards too).

Security updates for Friday

Post Syndicated from jake original https://lwn.net/Articles/951066/

Security updates have been issued by Fedora (community-mysql, matrix-synapse, and xorg-x11-server-Xwayland), Mageia (squid and vim), Oracle (dnsmasq, python3, squid, squid:4, and xorg-x11-server), Red Hat (fence-agents, insights-client, kernel, kpatch-patch, mariadb:10.5, python3, squid, squid:4, tigervnc, and xorg-x11-server), Scientific Linux (bind, firefox, java-1.8.0-openjdk, java-11-openjdk, kernel, libssh2, python-reportlab, python3, squid, thunderbird, and xorg-x11-server), SUSE (go1.21), and Ubuntu (linux-gke and linux-iot).

[$] Reducing patch postings to linux-kernel

Post Syndicated from jake original https://lwn.net/Articles/950567/

The linux-kernel mailing list famously gets an enormous amount of email on a
daily basis; the volume is so high that various email providers try to
rate-limit it, which can lead to huge backlogs on the sending
side and, of course, delayed mail. Part of the reason there is so much
traffic is that nearly every patch gets copied to the mailing list, even
when it may be unnecessary to do so. A proposed change
would start shunting some of that patch email aside and, as might be
guessed, has both supporters and detractors, but the discussion does
highlight some of the
different ways the mailing list is used by kernel developers.

[$] Progress in wrangling the Python C API

Post Syndicated from jake original https://lwn.net/Articles/950457/

There has been a lot of action for the Python C API in the last month or
so—much of it organizational in nature. As predicted in our late September article on using the “limited”
C API in the standard library, the core developer sprint in October was the
scene of some discussions about the API and the plans for it. Out
of those discussions have come two PEPs, one of which describes the API,
its purposes, strengths, and weaknesses, while the other would establish a C
API working group to coordinate and oversee the development and maintenance
of it.

Security updates for Monday

Post Syndicated from jake original https://lwn.net/Articles/950413/

Security updates have been issued by Debian (chromium, open-vm-tools, openjdk-17, pmix, and trafficserver), Fedora (netconsd, podman, suricata, and usd), Oracle (.NET 6.0, .NET 7.0, binutils, ghostscript, java-1.8.0-openjdk, kernel, and squid), SUSE (apache-ivy, gstreamer-plugins-bad, kernel, nodejs12, opera, poppler, rubygem-activesupport-5.2, tiff, util-linux, and virtualbox), and Ubuntu (krb5).

[$] Implicit keyword arguments for Python

Post Syndicated from jake original https://lwn.net/Articles/949435/

Python functions can use both positional and keyword arguments; the latter
provide a certain level of documentation for an argument and its meaning,
while allowing them to be given in any order in a call. But it is often
the case that the name of the local variable to be passed is the same as
the keyword, which can lead to overly repetitive argument lists, at least
in some eyes. A recent proposal to shorten the syntax for calls with
these duplicate names seems to be gaining some steam—a Python Enhancement
Proposal (PEP) is forthcoming—though there are some who find it to be an
unnecessary and unwelcome complication for the language.

[$] Rust code review and netdev

Post Syndicated from jake original https://lwn.net/Articles/949270/

A fast-moving patch set—seemingly the norm for Linux networking
development—seeks to add some Rust abstractions for physical layer
(PHY) drivers. Lots of
review has been done, and the patch set has been reworked
frequently in response to those comments. Unfortunately, the Rust-for-Linux developers are
having trouble keeping up with that pace. There
is, it would appear, something of a disconnect between the two communities’
development practices.

Security updates for Monday

Post Syndicated from jake original https://lwn.net/Articles/949238/

Security updates have been issued by Debian (distro-info, distro-info-data, gst-plugins-bad1.0, node-browserify-sign, nss, openjdk-11, and thunderbird), Fedora (chromium, curl, nghttp2, and xorg-x11-server-Xwayland), Gentoo (Dovecot, Rack, rxvt-unicode, and UnZip), Mageia (apache, bind, and vim), Red Hat (varnish:6), SUSE (nodejs12, opera, python-bugzilla, python-Django, and vorbis-tools), and Ubuntu (exim4, firefox, nodejs, and slurm-llnl, slurm-wlm).

[$] Home Assistant: ten years of privacy-focused home automation

Post Syndicated from jake original https://lwn.net/Articles/947843/

Many home-automation devices come with their own mobile app or cloud
service. However, using multiple apps or services is
inconvenient, so it’s (purposely) tempting to only buy devices from the same
vendor, but this can lead to lock-in. One project that lets
users manage home-automation devices from various vendors without lock-in
is Home Assistant. Over its
ten-year existence, it has developed into a user-friendly home-automation
platform that caters to both technically inclined and less tech-savvy
people.

[$] Defining open hardware

Post Syndicated from jake original https://lwn.net/Articles/945870/

Open-source hardware (or open hardware) refers to hardware that is
developed in a manner similar to open-source software. There’s a widely
accepted definition of open-source hardware, but it is probably not as well
known as its open-source-software counterpart. In addition, there is a popular
certification program that hardware makers can use to indicate which of
their devices meets that criteria. But there are some vendors that are
showing more enthusiasm than others in participating in the process—or in
producing
open hardware at all.

[$] Remote execution in the GNOME tracker

Post Syndicated from jake original https://lwn.net/Articles/947288/

While the vulnerability itself is pretty run-of-the-mill, the recently disclosed
GNOME vulnerability has a number of interesting facets. The problem lies
in a library that reads files in a fairly obscure format, but it turns out
that files in that format are routinely—automatically—processed by GNOME if
they are downloaded to the local system. That turns a vulnerability in a
largely unknown library into a one-click remote-code-execution flaw for
the GNOME desktop.

[$] Progress on no-GIL CPython

Post Syndicated from jake original https://lwn.net/Articles/947138/

Back at the end of July, the Python steering council announced
its intention to approve the proposal to make the global interpreter lock
(GIL) optional over the next few Python releases. The details of that
acceptance are still being decided on, but work on the feature is
proceeding—in discussion form at least. Beyond that, though, there are
efforts underway to solve that hardest of problems in computer
science, naming, for the no-GIL version.