Linux Weekly News

Linus has released 5.6-rc1 and closed the merge window for this development cycle. "This was actually a slightly smaller merge window than usual, but I think that what happened is simply that the holiday season impacted new development. It impacted the 5.5 rc series less than I had expected, but seems to instead have caused 5.6 to have slightly less development than normal."

One of the more eyebrow-raising features to go into the 5.6 kernel is the ability to load TCP congestion-control algorithms as BPF programs; networking developer Toke Høiland-Jørgensen described it as a continuation of the kernel's "march towards becoming BPF runtime-powered microkernel". On its face, congestion control is a significant new functionality to hand over to BPF, taking it far beyond its existing capabilities. When one looks closer, though, one's eyebrow altitude may well increase further; the implementation of this feature breaks new ground in a couple of areas.

Over on the Ardour forum, Paul Davis wonders whether access to the source code is truly what users these days want or need. There are other closed-source digital audio workstations that are far more customizable than Ardour via a scripting language without needing any access to the source. "But perhaps for applications like Ardour, ones that do not yet exist, there ought to be a different development pathway. I remember once wondering if we should have implemented the entire GUI in PyGTK (i.e. Python). We didn't, and most of my curiosity was about whether it would have helped or hindered our development process. However, had we done so, one of the consequences would have been that many changes to the program would have been made simpler, easier to access and would require no 'rebuild'. I wonder if going forward, large-scale apps like Ardour ought to (as Reaper did relatively early in its life) consider the 'script extension system' to be a vital and critical part of the application infrastructure. This would mean, for example, writing large parts of 'core functionality' using this system, rather than dropping back into C++ to get things done. There are precedents for this: GNU Emacs, for example, is at some level written in C, but almost everything about the program is actually constructed in Emacs Lisp, its own 'scripting extension'. The C core of Emacs is so small and so irrelevant that it almost doesn't matter that it is there: if you want to modify or extend Emacs, you (almost always) write Lisp, not C."

Security updates have been issued by Arch Linux (chromium, python-django, and sudo), Debian (libexif and libxmlrpc3-java), Fedora (upx and xar), openSUSE (ucl and upx), Oracle (ipa), Scientific Linux (kernel), SUSE (e2fsprogs, libqt5-qtbase, nginx, pcp, php7, rubygem-rack, systemd, wicked, and xen), and Ubuntu (mariadb-10.1, mariadb-10.3, mesa, pillow, and python-reportlab).

On his blog, Peter Hutterer writes about some changes that will allow users to start deploying their own rules to modify keyboard layouts without driving themselves crazy. Many many moons ago before the Y2K bug was even in its larvae stage, the idea was that you could configure all of those because every UNIX tool had to be more flexible than your yoga teacher. I'm unsure to what extent this was actually ever the case but around 2007-ish the old keyboard driver got deprecated and the evdev driver made it's grand entrance. And one side-effect of that was that things broke. evdev uses different keycodes, so all those users that copy-pasted unnecessary XKB configuration into their xorg.conf now had broken keys because they were applying the wrong rules. After whacking enough moles that we got in trouble with the RSPCA [Royal Society for the Prevention of Cruelty to Animals] we started hardcoding the "evdev" ruleset everywhere. The xorg.conf option "XKBRules" became a noop and thus stopped breaking users' setups.

Except that it also stopped users from deploying their own rules files - something that probably didn't really matter anyway. This had some unintended side-effects though. First, to have a working custom XKB layout you basically had to get it merged upstream. Yes, you could edit the files locally but they'd just be overwritten next time you update the packages. Second, getting rid of hardcoded things is hard so we're stuck with the evdev ruleset for the forseeable future. This was the situation until, well, now.

By many accounts, the kernel project uses outdated tooling, far behind the state of the art that Kids Today tend to favor. The kernel's workflow has worked well (enough) for years, but there are signs that it may not be sustainable indefinitely. As a result, there has been an ongoing conversation about improving the kernel's workflow, but little has changed so far. The posting of a simple tool called get-lore-mbox is a sign that the rate of change may be about to increase.

Security updates have been issued by CentOS (kernel-rt, qemu-kvm, spamassassin, and Xorg), Debian (ruby-rack-cors), Fedora (glibc), openSUSE (ImageMagick), Oracle (ipa, kernel, and qemu-kvm), SUSE (systemd), and Ubuntu (exiv2, mbedtls, and systemd).

The LWN.net Weekly Edition for February 6, 2020 is available.

Stable kernels 5.4.18, 4.19.102, and 4.14.170 have been released. They contain important fixes and users should upgrade.

Browser tracking across different sites is certainly a major privacy concern and one that is more acute when the boundaries between sites and browsers blur—or disappear altogether. That seems to be the underlying tension in a "discussion" of an only tangentially related proposal being made by Google to the W3C Technical Architecture Group (TAG). The proposal would change the handling of the User-Agent headers sent by browsers, but the discussion turned to the unrelated X-Client-Data header that Chrome sends to Google-owned sites. The connection is that in both cases some feel that the web-search giant is misusing its position to the detriment of its users and its competitors in the web ecosystem.

Support for the CoreOS Container Linux distribution is coming to an end on May 26; there will be no further updates after that date. Users are recommended to move to Fedora CoreOS or some other distribution.

Stable kernels 5.5.2, 4.9.213, and 4.4.213 have been released with important fixes. Users should upgrade.

Security updates have been issued by Debian (storebackup), openSUSE (e2fsprogs and wicked), Red Hat (containernetworking-plugins, ipa, kernel, kernel-rt, ksh, and qemu-kvm), Scientific Linux (ipa and qemu-kvm), SUSE (libqt5-qtbase, python-reportlab, and terraform), and Ubuntu (graphicsmagick, OpenSMTPD, spamassassin, and sudo).

Python 2 was officially "retired" on the last day of 2019, so no bugs will be fixed or changes made in that version of the language, at least by the core developers—distributions and others will continue for some time to come. But there are lots of Python projects that still support Python 2.7 and may not be ready for an immediate clean break. Some changes that were made for the upcoming Python 3.9 release (which is currently scheduled for October) are causing headaches because support for long-deprecated 2.7-compatibility features is being dropped. That led to a discussion on the python-dev mailing list about postponing those changes to give a bit more time to projects that want to drop Python 2.7 support soon, but not immediately.

Security updates have been issued by Arch Linux (salt), CentOS (git), Debian (qtbase-opensource-src), Fedora (java-11-openjdk), Mageia (kernel and openjpeg2), openSUSE (mailman, python-reportlab, ucl, and upx), Oracle (git), Red Hat (container-tools:rhel8, go-toolset:rhel8, grub2, kernel, kernel-rt, php:7.2, and sudo), SUSE (crowbar-core, crowbar-openstack, openstack-neutron-fwaas, rubygem-crowbar-client and python36), and Ubuntu (python-django).

The Git source-code management system is famously built on the SHA‑1 hashing algorithm, which has become an increasingly weak foundation over the years. SHA‑1 is now considered to be broken and, despite the fact that it does not yet seem to be so broken that it could be used to compromise Git repositories, users are increasingly worried about its security. The good news is that work on moving Git past SHA‑1 has been underway for some time, and is slowly coming to fruition; there is a version of the code that can be looked at now.

Security updates have been issued by Arch Linux (opensmtpd), Debian (firefox-esr, libidn2, libjackson-json-java, prosody-modules, qemu, qtbase-opensource-src, spamassassin, and sudo), Fedora (e2fsprogs, java-1.8.0-openjdk, mingw-openjpeg2, openjpeg2, samba, sox, upx, webkit2gtk3, and xar), Red Hat (git), Scientific Linux (git), Slackware (sudo), SUSE (ceph and rmt-server), and Ubuntu (sudo).

The GNU libc 2.31 release is out. Significant changes include some initial C2X standard support, some DNS stub resolver changes, a new pthread_clockjoin_np() POSIX threads extension, a number of changes to time-related functions, and more.

The 5.5.1, 5.4.17, and 4.19.101 stable kernel updates have been released; each contains another set of important fixes.

The longtime tech writer for the Yocto Project, Scott Rifenbark, has died after a battle with cancer. Project architect Richard Purdie announced the sad news on the yocto mailing list; he also reflected on Rifenbark and his impact: "I remember interviewing Scott over 10 years ago when forming a team at Intel to work on what became the Yocto Project, he was with it from the start. He warned me he wasn't an entirely traditional tech writer but I warned we weren't aiming to be a traditional project either. It was a great match. He stayed with the project ever since in one way or another, he enjoyed working on the project and we enjoyed working with him. The concept of having a tech writer as part of the team was a decision I'm proud of and it shows in the material supporting the project today but that success belongs to Scott and his approach to it. Someone else put that best, 'He would first try the procedure or instructions before documenting it, I was really impressed'. He was hands on and wanted things to be understandable and correct, a huge challenge with some of the complexities we deal with."