LWN.net is a comprehensive source of news and opinions from and about the Linux community. This is the main LWN.net feed, listing all articles which are posted to the site front page.


created: NaN NaN :: UTC ~ updated: 14 nov 2019 09:50:32 UTC ~ rssv1 ~ TTL 15 min.

[$] Filesystem sandboxing with eBPF. 6 nov 2019 22:40:32.LWN.net.

Running untrusted code in a safe manner is generally the goal of sandboxing efforts. The sandbox technique presented by Georgia Tech PhD student Ashish Bijlani at Open Source Summit Europe 2019 is no exception. He has used something of a novel scheme to allow unprivileged code to implement the sandbox policies using BPF; the policies are then enforced by the kernel.
At Open Source Summit Europe 2019, Michael C. Jaeger and Maximilian Huber updated attendees on the FOSSology project, which is an open-source license-compliance tool. They introduced FOSSology and talked about how it can be used, but they also looked at the new features added in the last few releases. Beyond that, they presented some experiments the project has been doing with creating machine-learning models for license recognition.

Stable kernel updates. 6 nov 2019 16:08:27.LWN.net.

Stable kernels 5.3.9, 4.19.82, 4.14.152, 4.9.199, and 4.4.199 have been released. They all contain important fixes and users should upgrade.

Security updates for Wednesday. 6 nov 2019 15:55:31.LWN.net.

Security updates have been issued by Debian (cpio, openafs, proftpd-dfsg, simplesamlphp, and wordpress), Fedora (thunderbird), openSUSE (binutils, docker-runc, kernel, nfs-utils, php7, python3, and samba), Red Hat (389-ds:1.4, ansible, bind, container-tools:1.0, container-tools:rhel8, curl, dbus, dhcp, dovecot, edk2, elfutils, evolution, freeradius:3.0, gdb, gettext, glib2, glibc, GNOME, gnutls, go-toolset:rhel8, http-parser, httpd:2.4, kernel, kernel-rt, libarchive, libjpeg-turbo, libqb, libreswan, libseccomp, libtiff, libvorbis, lldpad, lua, mariadb:10.3, mod_auth_mellon, numpy, openssh, openssl, openstack-octavia, osinfo-db and libosinfo, php:7.2, php:7.3, python-urllib3, python27:2.7, python3, qemu-kvm-rhev, qt5-qtbase, rh-php70-php, rh-python36-python, samba, squid:4, sssd, sudo, systemd, virt-manager, virt:rhel, and yum), SUSE (ardana-ansible, ardana-horizon, ardana-keystone, ardana-manila, ardana-neutron, crowbar-core, crowbar-openstack, grafana, openstack-cinder, openstack-dashboard, openstack-horizon-plugin-manila-ui, openstack-keystone, openstack-manila, openstack-neutron, openstack-neutron-fwaas, openstack-neutron-lbaas, openstack-nova, openstack-octavia, openstack-octavia-amphora-image, pdns, python-Django1, python-keystonemiddleware, python-octaviaclient, python-os-brick, python-oslo.cache, python-oslo.messaging, gdb, and libssh2_org), and Ubuntu (firefox).

[$] Generalizing address-space isolation. 5 nov 2019 19:16:44.LWN.net.

Linux systems have traditionally run with a single address space that is shared by user and kernel space. That changed with the advent of the Meltdown vulnerability, which forced the merging of kernel page-table isolation (KPTI) at the end of 2017. But, Mike Rapoport said during his 2019 Open Source Summit Europe talk, that may not be the end of the story for address-space isolation. There is a good case to be made for increasing the separation of address spaces, but implementing that may require some fundamental changes in how kernel memory management works.

Red Hat Enterprise Linux 8.1 released. 5 nov 2019 19:16:21.LWN.net.

Red Hat has announced the release of Red Hat Enterprise Linux 8.1. This is the first update in what is planned to be a 6 month cadence for minor releases. The release notes contain more information.

Git v2.24.0. 5 nov 2019 17:46:00.LWN.net.

Git 2.24 has been released. This blog post covers the highlights of this release, beginning with feature macros. "Usually, configuring some behavior requires only a single configuration change, like enabling or disabling any of the aforementioned values. But what about when it doesn’t? What do you do when you don’t know which configuration values to change? For example, let’s say you want to live on the bleeding-edge of the latest from upstream Git, but don’t have a chance to discover all the new configurable options. In Git 2.24, you can now opt into feature macros—one Git configuration that implies many others. These are hand-selected by the developers of Git, and they let you opt into a certain feature or adopt a handful of settings based on the characteristics of your repository."

Security updates for Tuesday. 5 nov 2019 15:38:53.LWN.net.

Security updates have been issued by Arch Linux (electron, ghostscript, glibc, python2, and samba), Debian (webkit2gtk), Slackware (libtiff), SUSE (ImageMagick, python-ecdsa, and samba), and Ubuntu (apport, haproxy, ruby-nokogiri, and whoopsie).
The stable kernel releases are meant to contain as many important fixes as possible; to that end, the stable maintainers have been making use of a machine-learning system to identify patches that should be considered for a stable update. This exercise has had some success but, at the 2019 Open Source Summit Europe, Sasha Levin asked whether this process could be improved further. Might it be possible for a machine-learning system to identify patches that create bugs and intercept them, so that the fixes never become necessary?

Security updates for Monday. 4 nov 2019 15:50:41.LWN.net.

Security updates have been issued by Arch Linux (chromium and qt5-webengine), CentOS (firefox and php), Fedora (file, java-latest-openjdk, nspr, nss, php, t1utils, and webkit2gtk3), Mageia (ansible, aspell, golang, libsoup, and libxslt), openSUSE (chromium and chromium, re2), Oracle (php), and Ubuntu (apport and file).

Kernel prepatch 5.4-rc6. 4 nov 2019 00:46:05.LWN.net.

The 5.4-rc6 kernel prepatch is out for testing. "There's no particular area or outstanding issue that is worrisome, but if things don't calm down this week, I suspect we'll be looking at one of those releases when we have an rc8. We'll see how things evolve here over the next couple of weeks."
The kernel project's email-based development process is well established and has some strong defenders, but it is also showing its age. At the 2019 Kernel Maintainers Summit, it became clear that the kernel's processes are much in need of updating, and that the maintainers are beginning to understand that. It is one thing, though, to establish goals for an improved process; it is another to actually implement that process and convince developers to use it. At the 2019 Open Source Summit Europe, a group of 20 or so maintainers and developers met in the corner of a a noisy exhibition hall to try to work out what some of the first steps in that direction might be.

The meeting was organized and led by Konstantin Ryabitsev, who is in charge of kernel.org (among other responsibilities) at the Linux Foundation (LF). Developing the kernel by emailing patches is suboptimal, he said, especially when it comes to dovetailing with continuous-integration (CI) processes, but it still works well for many kernel developers. Any new processes will have to coexist with the old, or they will not be adopted. There are, it seems, some resources at the LF that can be directed toward improving the kernel's development processes, especially if it is clear that this work is something that the community wants.


Ryabitsev's first goal didn't feature strongly at the Maintainers Summit, but is an issue that he has been concerned about for some time: improving attestation for patches so that recipients can be sure of their provenance. Currently, there is no attestation at all, so recipients have to trust that patches come from the developer whose name appears on them. We all assume that maintainers are watching carefully and can catch spoofed emails, but the truth of the matter is that it is relatively easy to sneak malicious code past a maintainer. So an attacker could conceivably find a way to add a vulnerability to the kernel.

The first problem to solve is thus, according to Ryabitsev, to fix attestation. Linus Torvalds does verify the signed tags that are associated with pull requests, he said, so that part of the process is taken care of. But there are no signatures on actual patches, and no consensus on how they might be added.

His proposal is to introduce signatures on emailed patches as well. The mechanism used would be minisign, not GnuPG; one of the big advantages of minisign is that the attached signatures are much shorter than those created by GnuPG. Steve Rostedt interrupted at this point to question the value of this approach; he said that an attack, to be successful, would have to involve a relatively complex patch written in a style that mimics that of the purported author. It would be a big effort, he said; anybody with the resources to do that could also crack the encryption scheme used for attestation.

Ryabitsev responded, though, that minisign is "real cryptography" and not easy to crack; there are far easier ways to get bad code into the kernel than breaking the encryption. The hard part with this scheme, instead, is with identity tracking. GnuPG, like PGP before it, is based on the "web of trust" idea, but the web of trust has proved to be mostly unworkable over the years and people are giving up on it. Newer schemes tend to be based, like SSH, on a "trust on first use" (or TOFU) model, where a new key is trusted (and remembered) when it is first encountered, but changes in keys require close scrutiny. He suggested using a TOFU approach in an attestation mechanism for Git as well.

Rafael Wysocki was also skeptical, asserting that this scheme does not solve the problem; it only moves it elsewhere. An attacker could create an identity and build trust over time before submitting something malicious; the proposed scheme adds complexity but doesn't really fix anything, he said. Ryabitsev disagreed, though; building trust requires time and resources, but an attacker could spoof a trusted developer now.

Frank Rowand asked whether maintainers would be expected to strip signatures before committing patches. The signature, Ryabitsev answered, would go below the "‑‑‑" line in the changelog, so it would be automatically stripped at commit time. But the key used would also be noted in a local database and verified the next time a patch shows up from the same developer. Rostedt pointed out that one-time submitters would not have a key in this database; Ryabitsev replied that, since those developers are not coming back, it doesn't really matter. This scheme is about trusting ongoing developers.

He would like minisign-based attestation to become part of Git; tools like git format-patch would just add it automatically. Rowand pointed out that a lot of developers use relatively old versions of Git, so it would take years to roll this capability out to everybody. He said that GnuPG should be used instead; developers have it and the kernel's web of trust already exists. But Ryabitsev said that GnuPG is a poor tool for signing patches; the attached signature is often larger than the patch itself, and list archival mechanisms tend to strip it out. To be truly useful, signatures on patches need to be unobtrusive.

Like much of what was discussed in this meeting, signature use would be opt-in, at least initially. Ryabitsev is thinking about writing a bot that would watch the mailing lists and gently suggest to developers who are not using signatures that they might want to start. He asked the group whether this scheme as a whole was a good idea and got almost universal agreement (Rowand being the exception). So he intends to try to get the needed support added to Git.

Base-tree information

A common question asked of patch submitters is: "which tree was this made against?". That information is often needed to successfully apply a patch, and CI systems need it to be able to do automatic testing. But that "base-tree information" is not included with patches currently; fixing that is high on many developers' wish lists. Dmitry Vyukov asked whether it would be better to add this feature to Git and wait for it to be adopted, or to create a wrapper script that developers could use now. It turns out, though, that the ‑‑base option works in Git now, it's just a matter of getting submitters to use it. Vyukov agreed that this is the hardest part; he suggested creating a wrapper that would supply this option automatically.

There was a bit of a side discussion on whether Torvalds would complain about the base-tree information, as he does when tags like Change-id show up in patches. The problem, though, is not really the extra tag, it's the perceived uselessness of the information. If the base-tree information is useful, there should not be complaints.

It was pointed out that the base-tree information might not always be helpful to others; that base could be in a private tree, for example. At other times, though, it could be useful indeed. Rostedt pointed out that the "tip" tree used for x86 (and beyond) maintenance has a dozen or so branches in it; knowing which branch a patch applies to would be helpful. Everybody seemed to agree that this information should be there, and that the checkpatch.pl script should be made to check for it. There may eventually be a bot to nag developers who omit this information from their patches, but care would have to be taken to prevent it from generating too much noise.

Beyond email

For a number of reasons, requiring all kernel patches to be sent by email looks like a policy with a limited future. Switching to a "forge" service, along the lines of GitHub or GitLab, is an idea without universal appeal, though, especially in the short term. But there is desire for a solution that could let some developers move beyond email while maintaining the current workflow overall. The first step in that direction is likely to be some sort of Git-to-email bridge. Ryabitsev pointed out, though, that there is no consensus on what such a bridge might look like.

One option could be a special Git repository that developers could push to; any patch series pushed there would be turned into a series of emails and sent to the appropriate addresses. Ryabitsev does not like that idea, though; any such system would be a central point of failure that could go down at inopportune times. Another option would be some sort of web service that could be pointed at a public repository; once again, it would generate an email series and submit it. This solution falls down in another way, though: it is unable to support attestation. A third alternative is to create a command-line tool that can turn a pull request into an emailed series.

There are a number of hard problems to be solved here, he said, with many tradeoffs to be considered. But the easiest solution appears to be the command-line tool, perhaps integrated with an tool like GitGitGadget. There is also a tool under development at sourcehut that is worth a look. He might support such a tool by exposing an SMTP service specifically for mailing patches to kernel.org addresses.

That led to the concept of "feeds" — services that provide access to patches and more. The lore.kernel.org service has been running for a while now; it has quickly become an indispensable part of the kernel development process. Ryabitsev would, though, like to create something with similar functionality that does not need a mailing list behind it. Developers could use it to create their own patch feeds; CI systems could also export feeds describing the tests they have run and the results. Then it would be possible to, for example, automatically annotate patches with data on how they have been tested and by who. Bots could use this information to figure out which tests they should run, avoiding those that have already been run elsewhere. Feeds would be archived and mirrored so they could be checked years in the future. Feeds would be able to support attestation, record Acked-by tags, and more.

But that still leaves the problem of actually creating all of this tooling and making it easy to use. Nobody is going to want all of these feeds in their inbox, so it will have to be possible to establish filters. Size also matters: lore.kernel.org currently requires about 200GB of disk space, which is a bit unwieldy to download to one's laptop. But lore contains a lot of ancient history that developers will not normally need, so the database could be much smaller.

Ryabitsev is currently working with the maintainer of public-inbox on the development of some of these tools. There is, he said, some development time that is available at the LF over the next six months; what should he aim to achieve in that time? Building something with Docker would be convenient for many, but the "old-school developers" don't want to deal with Docker. Should it be a command-line or web-based tool? Fans of command-line tools tend to be more vocal, but that does not mean that they are a majority.

Perhaps, he said, the way to start would be to make it easy to set up a local Patchwork instance. There was a wandering discussion on how subsystems with group maintainership could be supported, but that is not a problem that can be solved in the next six months, he said. Further discussion on how the tools should be developed was deferred to the kernel workflows mailing list.

As time ran out there was some quick discussion of CI systems, including GitLab, Gerrit, and more. The kernel clearly needs more CI testing, so Ryabitsev wants to be sure that it is all integrated into any new tooling. He would like to be able to provide a feed describing what each of these systems is doing. These forge systems mostly provide an API for event data now; what is needed is a set of translator bots that could pull those events together into a pubic-inbox feed for anybody who is interested. CI systems would be able to consume this data, and others could follow it without having to have an account on each CI system.

The emails sent by CI systems now are just noise to many recipients, he said; as more of these systems come online that problem will get worse. Creating a feed solves the problem by putting CI reports where only the people who want them have to see them. It is a hard thing to do well, he said, and he is not sure how his solution will work, but he wants to try. Email is a terrible way to integrate with systems that need structured data, so he's looking to replace the email message bus with a more structured, feed-based system.

The session broke up with a promise that, if the community asks for this kind of tooling, there is a real possibility that the LF will find a way to fund its development.

See also: Han-Wen Nienhuys's notes from the meeting.

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting your editor's travel to the event.]

Python adopts a 12-month release cycle. 1 nov 2019 15:04:01.LWN.net.

The long discussion on changing the Python project's release cadence has come to a conclusion: the project will now be releasing new versions on an annual basis. See PEP 602 for the details on how it is expected to work.

Security updates for Friday. 1 nov 2019 14:29:20.LWN.net.

Security updates have been issued by CentOS (firefox, sudo, and thunderbird), Debian (libarchive and qtbase-opensource-src), Oracle (php), Red Hat (php, rh-php71-php, and rh-php72-php), Scientific Linux (firefox and php), and SUSE (kernel and samba).

Security updates for Thursday. 31 oct 2019 15:01:23.LWN.net.

Security updates have been issued by Debian (italc and python-ecdsa), Fedora (php and sudo), openSUSE (binutils and docker-runc), Oracle (thunderbird), Red Hat (firefox and sudo), SUSE (ardana-ansible, ardana-glance, ardana-horizon, ardana-input-model, ardana-manila, ardana-neutron, ardana-nova, ardana-octavia, ardana-tempest, crowbar-core, crowbar-ha, crowbar-openstack, crowbar-ui, galera-3, grafana, mariadb, mariadb-connector-c, novnc, openstack-cinder, openstack-glance, openstack-heat, openstack-horizon-plugin-neutron-vpnaas-ui, openstack-keystone, openstack-monasca-installer, openstack-neutron, openstack-neutron-gbp, openstack-neutron-lbaas, openstack-nova, python-amqp, python-ovs, python-pysaml2, python-python-engineio, python-urllib3, release-notes-suse-openstack-cloud, rubygem-easy_diff, rubygem-rest-client-1_6, venv-openstack-keystone, dbus-1, firefox, php7, and samba), and Ubuntu (file, freetds, and whoopsie).
The LWN.net Weekly Edition for October 31, 2019 is available.

[$] Unifying kernel tracing. 30 oct 2019 17:49:49.LWN.net.

Steven Rostedt has been a part of the Linux kernel tracing community for most of its existence, it seems. He was the developer of ftrace, which was one of the early mainline additions for tracing. There are now many tracing facilities in the kernel. At the 2019 Open Source Summit Europe in Lyon, France, Rostedt wanted to present an idea that he has been thinking about for a long time: a unified tracing platform to provide access to all of the kernel tracing facilities from user-space applications.

Security updates for Wednesday. 30 oct 2019 14:24:16.LWN.net.

Security updates have been issued by Debian (imapfilter, libvncserver, and pam-python), Fedora (tcpdump), Mageia (file, graphviz, kernel, and php, pcre2), openSUSE (nfs-utils), Red Hat (heketi and samba), Scientific Linux (thunderbird), SUSE (libtomcrypt, php7, and runc), and Ubuntu (apport, libarchive, libidn2, samba, and whoopsie).

Fedora 31 is here. 29 oct 2019 16:50:33.LWN.net.

Fedora Magazine announces the release of Fedora 31. This release includes the Fedora Toolbox for launching and managing personal workspace containers. The Fedora Editions include Workstation, Server, with CoreOS and IoT in a preview state. Alternate architectures include ARM AArch64, Power, and S390x. However the 32-bit only i686 system has been dropped. The release notes contain additional information.
Back in March, we looked at a discussion and Python Enhancement Proposal (PEP) for a new dictionary "addition" operator for Python. The discussion back then was lively and voluminous, but the PEP needed some updates and enhancements in order to proceed. That work has now been done and a post about the revised PEP to the python-ideas mailing list has set off another mega-thread.


REQUEST_URI: /dyn/feeds/feed?id=6&off=20 - id: 005DCD24610E7250 - , uid: , sheet: feeds/feed-list.xsl

2019-11-14T09:54:41.984 - SERVER_NAME: chafar.net, server_id: cnet, SERVER_SOFTWARE: Apache/2.4.10 (Debian)