lwn.net

Debian typically uses code names to refer to its releases, starting with the Toy Story character names used (mostly) instead of numbers. The "Buster" release is due on July 6 and you will rarely hear it referred to as "Debian 10". There are some other code names used for repository (or suite) names in the Debian infrastructure; "stable", "testing", "unstable", "oldstable", and sometimes even "oldoldstable" are all used as part of the sources for the APT packaging tool. But code names of any sort are hard to keep track of; a discussion on the debian-devel mailing list looks at moving away from, at least, some of the repository code names.

Stable kernels 5.1.16, 4.19.57, and 4.14.132 have been released. They all contain important fixes and users should upgrade.

Security updates have been issued by Debian (pdns), Fedora (kernel and kernel-headers), Mageia (cgit and firefox), Oracle (libssh2 and qemu-kvm), Red Hat (openstack-ironic-inspector, openstack-tripleo-common, and qemu-kvm-rhev), Scientific Linux (libssh2 and qemu-kvm), SUSE (bzip2, cronie, libtasn1, nmap, php7, php72, python-Twisted, and taglib), and Ubuntu (thunderbird and znc).

A problem with the way that OpenPGP public-key certificates are handled by key servers and applications is wreaking some havoc, but not just for those who own the certificates (and keys)—anyone who has those keys on their keyring and does regular updates will be affected. It is effectively a denial of service attack, but one that propagates differently than most others. The mechanism of this "certificate flooding" is one that is normally used to add attestations to the key owner's identity (also known as "signing the key"), but because of the way most key servers work, it can be used to fill a certificate with "spam"—with far-reaching effects.

Security updates have been issued by Arch Linux (firefox, firefox-developer-edition, libarchive, and vlc), CentOS (firefox, thunderbird, and vim), Debian (firefox-esr, openssl, and python-django), Fedora (glpi and xen), Mageia (thunderbird), openSUSE (ImageMagick, irssi, libheimdal, and phpMyAdmin), Red Hat (libssh2 and qemu-kvm), Scientific Linux (firefox, thunderbird, and vim), SUSE (389-ds, cf-cli, curl, dbus-1, dnsmasq, evolution, glib2, gnutls, graphviz, java-1_8_0-openjdk, and libxslt), and Ubuntu (python-django).

CPU scheduling is a difficult task in the best of times; it is not trivial to pick the next process to run while maintaining fairness, minimizing energy use, and using the available CPUs to their fullest potential. The advent of increasingly complex system architectures is not making things easier; scheduling on asymmetric systems (such as the big.LITTLE architecture) is a case in point. The "turbo" mode provided by some recent processors is another. The TurboSched patch set from Parth Shah is an attempt to improve the scheduler's ability to get the best performance from such processors.

GnuPG contributors Robert J. Hansen (rjh) and Daniel Kahn Gillmor (dkg) were victims of a certificate spamming attack over the past week. This attack exploited a defect in the OpenPGP protocol itself in order to "poison" rjh and dkg's OpenPGP certificates. Anyone who attempts to import a poisoned certificate into a vulnerable OpenPGP installation will very likely break their installation in hard-to-debug ways. Poisoned certificates are already on the SKS keyserver network. There is no reason to believe the attacker will stop at just poisoning two certificates. Further, given the ease of the attack and the highly publicized success of the attack, it is prudent to believe other certificates will soon be poisoned.

This attack cannot be mitigated by the SKS keyserver network in any reasonable time period. It is unlikely to be mitigated by the OpenPGP Working Group in any reasonable time period. Future releases of OpenPGP software will likely have some sort of mitigation, but there is no time frame. The best mitigation that can be applied at present is simple: stop retrieving data from the SKS keyserver network. (Thanks to Kareem Khazem)

Forbes reports that Google has launched a new website, fuchsia.dev, with documentation and source for Fuchsia OS, including the Zircon microkernel. "Zircon was previously known as Magenta and it was designed to scale to any application from embedded RTOS (Real-Time Operating Systems) to mobile and desktop devices of all kinds. As a result, there has been much speculation that Fuchsia will be the natural successor to Android and Chrome OS, combining capabilities of both with backwards compatibility to run legacy applications built on either. In short, this thing is designed to run on anything from 32-bit or 64-bit ARM cores to 64-bit X86 processors and it has a potential to be rather disruptive."

Security updates have been issued by Debian (expat, golang-go.crypto, gpac, and rdesktop), Fedora (chromium, GraphicsMagick, kernel, kernel-headers, pdns, and xen), openSUSE (chromium, dbus-1, evince, libvirt, postgresql96, tomcat, and wireshark), Oracle (thunderbird and vim), Scientific Linux (thunderbird), Slackware (irssi), SUSE (gvfs), and Ubuntu (linux-lts-xenial, linux-aws, linux-azure and linux-oem, linux-oracle, linux-raspi2, linux-snapdragon).

The Mageia distribution has released version 7. "Mageia 7 comes with a huge variety of desktops and window managers, improved support for Wayland and for hybrid graphics cards. On a more fun note, an effort was made to enhance gaming in Mageia, so there are many new upgrades and additions to the game collection." See the release notes for details.

The 5.2-rc7 kernel prepatch is out for testing. "All small and fairly uninteresting. Arch updates, networking, core kernel, filesystems, misc drivers. Nothing stands out - just read the appended shortlog."

Over on Opensource.com, FreeDOS founder Jim Hall writes about the origin of the MS-DOS replacement on the 25th anniversary of FreeDOS. "While I announced the project as PD-DOS (for "public domain," although the abbreviation was meant to mimic IBM's "PC-DOS"), we soon changed the name to Free-DOS and later FreeDOS. I started working on it right away. First, I shared the utilities I had written to expand the DOS command line. Many of them reproduced MS-DOS features, including CLS, DATE, DEL, FIND, HELP, and MORE. Some added new features to DOS that I borrowed from Unix, such as TEE and TRCH (a simple implementation of Unix's tr). I contributed over a dozen FreeDOS utilities By sharing my utilities, I gave other developers a starting point. And by sharing my source code under the GNU General Public License (GNU GPL), I implicitly allowed others to add new features and fix bugs."

On his blog, Kees Cook looks at some graphs of package hardening efforts in Ubuntu and Debian, noting that they have nearly completely flattened out over the last few years. He wonders what might be the next hardening feature on the horizon and speculates some on that: "What new compiler feature adoption could be measured? I think there are still a few good candidates… How about enabling -fstack-clash-protection (only in GCC, Clang still hasn’t implemented it). Or how about getting serious and using forward-edge Control Flow Integrity? (Clang has -fsanitize=cfi for general purpose function prototype based enforcement, and GCC has the more limited -fvtable-verify for C++ objects.) Where is backward-edge CFI? (Is everyone waiting for CET?)"

Part of the kernel's job is to arbitrate access to the available hardware resources and ensure that every process gets its fair share, with "its fair share" being defined by policies specified by the administrator. One resource that must be managed this way is I/O bandwidth to storage devices; if due care is not taken, an I/O-hungry process can easily saturate a device, starving out others. The kernel has had a few I/O-bandwidth controllers over the years, but the results have never been entirely satisfactory. But there is a new controller on the block that might just get the job done.

Security updates have been issued by Debian (expat and mupdf), Fedora (drupal7-uuid, php-brumann-polyfill-unserialize, and php-typo3-phar-stream-wrapper2), openSUSE (thunderbird), Oracle (thunderbird and vim), SUSE (glibc), and Ubuntu (poppler).

The bpf() system call allows user space to load a BPF program into the kernel for execution, manipulate BPF maps, and carry out a number of other BPF-related functions. BPF programs are verified and sandboxed, but they are still running in a privileged context and, depending on the type of program loaded, are capable of creating various types of mayhem. As a result, most BPF operations, including the loading of almost all types of BPF program, are restricted to processes with the CAP_SYS_ADMIN capability — those running as root, as a general rule. BPF programs are useful in many contexts, though, so there has long been interest in making access to bpf() more widely available. One step in that direction has been posted by Song Liu; it works by adding a novel security-policy mechanism to the kernel.

Greg Kroah-Hartman has released the 4.14.131, 4.9.184, and 4.4.184 stable kernels. Each contains a single patch that fixes a problem in the TCP SACK panic fixes that was commonly seen by the Steam gaming community.

Security updates have been issued by Fedora (drupal7-uuid, php-brumann-polyfill-unserialize, and php-typo3-phar-stream-wrapper2), openSUSE (ansible, compat-openssl098, exempi, glib2, gstreamer-0_10-plugins-base, gstreamer-plugins-base, libmediainfo, libssh2_org, SDL2, sqlite3, and wireshark), Oracle (firefox), Red Hat (thunderbird and vim), Scientific Linux (firefox), SUSE (java-1_8_0-ibm), and Ubuntu (bzip2 and expat).

The LWN.net Weekly Edition for June 27, 2019 is available.

Over the past couple of months, things have been moving fairly swiftly toward the establishment of a separate entity to govern the openSUSE project. The idea is mainly meant to set up an organization that can receive and disburse funds on behalf of the project, rather than as some kind of move away from its parent company, SUSE. Also, while SUSE seems to be in a healthy position with a strong interest in supporting and working on openSUSE, that could change down the road, so a foundation or similar organization seems like the right way to go. At this point, the first draft of the foundation proposal has been posted; it generally has the support of SUSE management, so it is time to see what thoughts the community has.