Brief items

An important Exim security release

There are, it seems, 21 vulnerabilities in the Exim email server that have been fixed in the 4.94.2 release; at least some of these are remotely exploitable for root access. "The current Exim versions (and likely older versions too) suffer from several exploitable vulnerabilities. These vulnerabilities were reported by Qualys via security@exim.org back in October 2020. Due to several internal reasons it took more time than usual for the Exim development team to work on these reported issues in a timely manner." See this advisory from Qualys for the details.

Full Story (comments: 8)

Security quotes of the week

Unless the UK moves towards a "one rule for politicians, another for everyone else"-approach, if Boris can have end-to-end encrypted crypto, so can we.

— Alec Muffett notes that Boris Johnson apparently uses WhatsApp and Signal, thus enjoying the end-to-end encryption he is trying to ban

Security researchers Ralf-Philipp Weinmann of Kunnamon, Inc. and Benedikt Schmotzle of Comsecuris GmbH have found remote zero-click security vulnerabilities in an open-source software component (ConnMan) used in Tesla automobiles that allowed them to compromise parked cars and control their infotainment systems over WiFi. It would be possible for an attacker to unlock the doors and trunk, change seat positions, both steering and acceleration modes - in short, pretty much what a driver pressing various buttons on the console can do. This attack does not yield drive control of the car though.

— kunnamon.io

Comments (none posted)

Kernel release status

The 5.13 merge window is open; it can be expected to close on May 9. See this article for a summary of the first half of this merge window.

Stable updates: 5.12.1, 5.11.18, 5.10.34, and 5.4.116 were released on May 2. The 5.12.2, 5.11.19, 5.10.35, 5.4.117, and 4.19.190, updates are in the review process; they are due on May 7.

Comments (none posted)

The TAB report on the UMN affair

The Linux Foundation Technical Advisory Board has issued its report on the submission of (intentionally and unintentionally) buggy patches from the University of Minnesota.

This report summarizes the events that led to this point, reviews the "Hypocrite Commits" paper that had been submitted for publication, and reviews all known prior kernel commits from UMN paper authors that had been accepted into our source repository. It concludes with a few suggestions about how the community, with UMN included, can move forward.

The recommendations include establishing an internal review process for patches submitted by the community and the creation (by the TAB in cooperation with researchers) of a "best practices" document for researchers working with the kernel community.

(LWN editor Jonathan Corbet played a small part in the writing of this report).

Comments (33 posted)

Quotes of the week

I think people have this incorrect picture that "shared libraries are inherently good". They really really aren't. They cause a lot of problems, and the advantage really should always be weighed against those (big) disadvantages.

Pretty much the only case shared libraries really make sense is for truly standardized system libraries that are everywhere, and are part of the base distro.

— Linus Torvalds

However, these days, many if not most developers aren't capable of the discipline needed to maintained the ABI stability needed for shared libraries to work well. I can think several packages where if you used shared libraries, the major version number would need to be bumped at every releases, because people don't know how to spell ABI, never mind be able to *preserve* ABI. Heck, it's the same reason that we don't promise kernel ABI compatibility for kernel modules!

— Ted Ts'o

Life hack: everybody misspells 'miscellaneous', which is why we have the very special kernel rule that we always shorten that word to "misc".

— Linus Torvalds

Comments (73 posted)

Distribution quotes of the week

This means that becoming a Fedora Packager requires some training (usually done by oneself) and it requires commitment for working through the process of becoming a packager. Similar processes are needed to add packages in Debian and some other Linux distributions also.

It is a lot of work, and it is probably something we should be more upfront with (we mainly forget because most of us 'joined the club' years ago).

— Stephen John Smoogen (Thanks to José Abílio Matos)

For all other intents and purposes, Copr, the Outer Rim, is the place to be. It's fun there, a bit of a Kessel run.

— Bryce Carson

Comments (none posted)

QEMU 6.0.0 released

Version 6.0.0 of the QEMU hardware emulator is out. "This release contains 3300+ commits from 268 authors." This release includes a lot of new emulations; see the announcement for a short list or the changelog for details.

Comments (none posted)

Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

The Red Hat Developer Blog has posted an introduction to the rr debugger. "rr records trace information about the execution of an application. This information allows you to repeatedly replay a particular recording of a failure and examine it in the GNU Debugger (GDB) to better investigate the cause. In addition to replaying the trace, rr lets you run the program in reverse, in essence allowing you 'rewind the tape' to see what happened earlier in the execution of the program."

Comments (19 posted)

Development quote of the week

This is a case for an underappreciated reverse-engineering technique: guesswork. Hardware designers are logical engineers. If we can understand how Apple approached the hardware design, we can figure out where these hidden features should be in the command stream. We’re looking for conspicuous gaps in our understanding of the hardware, like looking for black holes by observing the absence of light.

— Alyssa Rosenzweig (Thanks to Paul Wise)

Comments (8 posted)

Michlmayr: Growing open-source projects with a stable foundation

Martin Michlmayr has put together a primer on managing open-source projects through their growth cycle, specifically with the help of a support foundation, and published the results as a 67-page PDF file.

Starting an open source project is easy. Running a successful project, on the other hand, comes with a lot of work and responsibilities, especially if the project attracts a large user base. While open source projects come in all shapes and forms, most projects encounter a similar set of growth issues throughout their life cycles. Because of this, various organizations have arisen to help projects handle these problems; these organizations are generally known as FOSS foundations. This primer covers non-technical aspects that the majority of projects will have to consider at some point. It also explains how FOSS foundations can help projects grow and succeed.

He has also posted a separate research report [PDF] on foundations that support open-source projects.

Comments (1 posted)