Hírolvasó

Daniel Aleksandersen shows how to sandbox a daemon process using a set of systemd features. "These directives combined would have stopped the specific remote code execution vulnerability that afflicted OpenSMTPD. However, the key takeaway is that you should strive to sandbox long-running and internet-exposed services. There’s no need for your webserver to be able to load a kernel module, your email server to change the hostname, or your DNS server to launch wget and schedule reoccurring tasks with cron."

Linus Torvalds released the 5.6-rc1 prepatch and closed the merge window on February 9; at that point, 10,780 non-merge changesets had been pulled into the mainline repository for 5.6. That is substantially less than recent development cycles (14,350 for 5.5, 14,619 for 5.4), but is similar to what was going on at this time last year (10,843 for 5.0-rc1 in January 2019). About 6,000 of those changes were pulled since the first 5.6 merge-window article was written; read on for what was included in those changes.

Version 9.1 of the GNU debugger is out. There are many improvements; see the announcement and the changelog for details.

Security updates have been issued by Debian (ipmitool, libexif, and ppp), Fedora (glib2, java-1.8.0-openjdk, java-11-openjdk, libasr, libuv, mingw-gdk-pixbuf, mingw-SDL2, nethack, nghttp2, nodejs, nodejs-mixin-deep, nodejs-set-value, nodejs-yarn, opensmtpd, python-feedgen, runc, samba, sox, and texlive-base), Mageia (chromium-browser-stable, mgetty, openslp, qtbase5, spamassassin, sudo, and xmlrpc), openSUSE (ceph and chromium), Oracle (grub2 and kernel), SUSE (docker-runc, LibreOffice, and wicked), and Ubuntu (libxml2 and qtbase-opensource-src).

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.