Welcome to the LWN.net Weekly Edition for June 17, 2021

This edition contains the following feature content:

• Fedora and supply-chain attacks: the Fedora project considers its vulnerability to compromised repositories and what might be done about it.
• Audacity gets a CLA: the acquisition of an open-source project leads to concern among users.
• Implementing eBPF for Windows: an independent implementation of a core Linux technology for the Windows kernel.
• Code humor and inclusiveness: do jokes in our code exclude those who don't understand them?
• quotactl_path() becomes quotactl_fd(): a potential API problem in the 5.13 release is headed off.

This week's edition also includes these inner pages:

• Brief items: Brief news items from throughout the community.
• Announcements: Newsletters, conferences, security updates, patches, and more.

Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.

Comments (none posted)

Fedora and supply-chain attacks

The specter of more events like the SolarWinds supply-chain attacks is something that concerns many in our communities—and beyond. Linux distributions provide a supply chain that obviously needs to be protected against attackers injecting malicious code into the update stream. This problem recently came up on the Fedora devel mailing list, which led to a discussion covering a few different topics. For the most part, Fedora users are protected against such attacks, which is not to say there is nothing more to be done, of course.

The SolarWinds attacks subverted the normal update mechanism of various tools to install malware on systems throughout much of the US government; the malware then exploited other flaws to get access to email and other data. Huzaifa Sidhpurwala posted a message to the mailing list on June 11 wondering whether the rekor tool might be useful in helping to prevent similar attacks against Fedora. Rekor comes from the sigstore project that was announced by the Linux Foundation back in March.

Sigstore is meant as a mechanism to securely record cryptographic signatures of binaries, packages, container images, and similar build artifacts in a tamper-proof ledger. The project was founded by Red Hat, Google, Purdue University, and the Linux Foundation. The press release announcement outlines the problem being solved:

Very few open source projects cryptographically sign software release artifacts. This is largely due to the challenges software maintainers face on key management, key compromise / revocation and the distribution of public keys and artifact digests. In turn, users are left to seek out which keys to trust and learn steps needed to validate signing. Further problems exist in how digests and public keys are distributed, often stored on websites susceptible to hacks or a README file situated on a public git repository. sigstore seeks to solve these issues by utilization of short lived ephemeral keys with a trust root leveraged from an open and auditable public transparency logs.

While it may well be true that the majority of projects on GitHub, GitLab, and other project-hosting sites are not signing their artifacts, that is not the case for most Linux distributions. For Fedora, RPM packages are signed and those signatures are checked by the DNF package manager. Other distributions have similar mechanisms. But there are still situations where some kind of external log of the signatures might be useful.

For example, if the Fedora signing keys were to ever be compromised or subverted, attackers could use the keys to sign malicious packages, which DNF would happily accept. But that means the attackers need to be positioned such that they can either intercept the DNF traffic (difficult with HTTPS) or tamper with the package repository. Even without a key compromise, a malicious (or compromised) package repository could hold back some updates to try to ensure that vulnerabilities in those packages continue to be present on the client systems. For the official Fedora mirrors, the metalink feature (originally added to Yum, the DNF predecessor) protects users by skipping mirrors that are more than three days behind in keeping up-to-date with the distribution's package updates.

In the posting, Sidhpurwala noted that Linux distributions, "which are made of thousands of components built from sources they [don't] even have control over", are potentially more vulnerable to supply-chain attacks because of that lack of control. One way that might start to be addressed is to be able "to ensure that there is no distribution point tampering of binaries shipped in Fedora". He wanted Fedora developers to start thinking about how a tool like rekor might be used to help prevent those kinds of problems. It would seem, though, that there is no huge unfilled hole that an immutable log of package hashes would solve, though there are use cases where it could perhaps be helpful.

Björn Persson wondered what "distribution points" were meant: "Repository mirrors? The master repository? mirrors.fedoraproject.org?" He noted that mirrors cannot modify packages (without the key), but that they could perhaps withhold updates; "Is that a thing that Rekor could prevent?" The sigstore web site might have helped answer the latter question, but it was not usable in his eyes:

On that page I can't see anything but a page header and a pointless animation. Even the text that is right there in the HTML code is hidden. Instead it wants me to execute a bunch of Javascript from at least three different domains. When a website expects me to execute some unknown program before they'll even tell me who they are or what they do, then I'm much more likely to just ignore that website.

That is, of course, a common complaint about JavaScript-only web sites these days, but it is perhaps a bit ironic that information about a security-related project is "hidden" in that way. In any case, Neal Gompa filled him in on sigstore, though Gompa was fairly dismissive of the project, at least so far. Persson had mentioned the ability to sign the repository metadata as another level of protection for Fedora, but Gompa complained that it has not been implemented for the Fedora repositories.

Gompa said that openSUSE signs its RPM repository metadata without any problems; in another message, he noted that CentOS added the feature in 2018. But Fedora infrastructure lead Kevin Fenzi pointed out that there have been numerous problems in trying to add the feature to Fedora along the way. But he is not opposed to doing so eventually:

I'm ok with enabling signed repodata when it is possible to do so and don't cause pain and suffering for our users. This has in fact always been my answer to this. It's not a priority for me personally because metalinks handle almost all the cases. The only things that would be improved by signed repodata are local mirrors that sync without checking for the mirror they sync from being up to date in mirrormanager.

Fenzi also described more of the details of the protection that is provided in the default case (where systems get their updates from the Fedora repository mirrors):

In the default configuration you get a metalink from mirrors.fedoraproject.org. That metalink has checksums for the last 2 repomd.xml files in it. If a mirror you go to then offers you a incorrect repomd.xml or any files (which are in turn checksumed in repomd.xml) dnf will treat the mirror as broken and skip to the next one.

So, assuming the Fedora keys are not compromised, which would allow an attacker to sign anything as if it came from Fedora, of course, then the majority of use cases are covered even without adding signed repository data. Local mirrors, which are typically run by organizations to reduce internet traffic and/or to support systems behind a restrictive firewall, might need some additional features, however. (As Fenzi put it: "We could do more for local mirrors indeed."

But, however unlikely it is, there is always a non-zero probability of a signing key compromise; folks unwinding a catastrophic event of that nature might find a log like that created by rekor to be of some use. Luke Hinds, who is the security engineering lead for Red Hat, described how that could work:

Rekor is a transparency log that stores signing manifests into a merkle tree, it uses the same back end technology as certificate transparency

Rekor has what are termed 'types' that allow it to ingest custom schemas and hash those into the transparency log. For those that don't know, a transparency log is immutable / append only datastore that is publicly auditable. One of the types we have is an rpm type to ingest and store signing materials from an RPM package.

Why is this useful? You get a timestamped / tamper resistance record of all signing events. This is very useful for understanding the exact blast radius of a key compromise and monitoring for suspicious events. Most of the time you will not interact with the tlog, it would sit off to side hashing in entries, so it would make no changes to a maintainers working flow or not being in any build path where it could cause an outage. It's the sort of system most would not be aware of, unless something awful happens, and then it has a lot of value, as you have an immutable record of events.

The "not being in any build path" part was confusing and Hinds walked that part back, but the idea is interesting, though it may be of limited utility. If the Fedora build infrastructure were set up to record all of its legitimate signing activities in the log, any package with a valid signature that did not appear there would be a red flag indicating a key compromise. That, of course, assumes that the attacker cannot also add entries to the log, which may or may not be the case.

As Miloslav Trmac pointed out, though, the rekor log may not actually provide anything new: "[...] any other logging solution from that build/signing system (just send it to a write-only log host) would have very similar security properties, it seems to me." In order for it to be truly useful, Trmac said in a follow-up, clients would need to query the log before installing an RPM to ensure that it is on the list. But, of course, an attacker who can create malicious packages with valid signatures may well be able to use the same machinery to add a log entry. Beyond that: "Given the above discussion about signing metadata, presumably a much smaller change, what makes such a Rekor integration more likely to get done?", Trmac asked.

If rekor (or something like it) is truly going to be useful for Fedora, it would seem that a clearer picture of what kinds of threats it would target—and how it would be superior to the existing protections—is needed. It sometimes seems that blockchain-type mechanisms (broadly defined) can be seen as a solution in search of a problem. While sigstore may well have applications for other types of projects—supply-chain attacks are real and dangerous, after all—Linux distributions may not be a good fit for this kind of tamper-proof log. Distribution security is not perfect, by any means, but the developers on those projects have been grappling with these kinds of problems for a really long time at this point. For Fedora, it probably makes more sense to try to fill in some of the holes that have been identified before climbing up on the Merkle-tree craze.

Comments (24 posted)

Audacity gets a CLA

The Audacity multi-track audio editor and recorder got its start in the previous century; it is a popular application that is available for multiple platforms, and it is licensed under the GPLv2 or later. But Audacity has been acquired by a newly formed organization called Muse Group; that event has caused something of an uproar in its community. The problem, at least in part, is the new Contributor License Agreement (CLA) required to contribute to Audacity.

The acquisition of the project was announced in an early-May YouTube video posted by Martin Keary ("Tantacrul"); that news was subsequently confirmed on the Audacity web site. In the video, Keary talks about what is planned for Audacity:

Audacity has just joined Muse Group, a collection of brands that includes another popular open source music app called MuseScore, which I’m currently in charge of. And since things are going rather well at MuseScore, I was asked to step up and also manage Audacity in partnership with its open source community. And just like we’re doing at MuseScore, we’re now planning on significantly improving the feature set and ease of use of Audacity – providing dedicated designers and developers to give it the attention it deserves – while keeping it free and open source.

In general, the reaction to the announcement (e.g. at Hacker News and again the next day) was fairly positive; there is a belief that Audacity could use some work on its user interface and that Keary has done good work on the MuseScore interface and elsewhere. But it did not take all that long for a clash between the community and the project to arise. A pull request by Dmitry Vedenko to add a telemetry feature was met with a large amount of dissent.

The feature, which was meant to be opt-in at install time, would report anonymous information to Google and Yandex; telemetry could be also be configured out at build time, though it would be present in the builds made by the project. Hundreds of comments on the pull request were made—nearly all unhappy with it due to privacy concerns—which led to the feature, as originally proposed, being dropped. In that message, Keary said that there is a need for opt-in crash and error reporting in Audacity, but that any data sent will be hosted by the project (or Muse Group), not Google and Yandex. Meanwhile, though, there is still interest in more-intrusive application-usage data if an acceptable mechanism is found for it:

Telemetry is a practical tool that tells us a lot about how an app is performing or underperforming (is this new feature being used a lot? Is this button being discovered? etc.) We assumed that making it opt-in would allay privacy concerns but since this isn't the case, we are dropping it. In the future, we may want to determine if there are any acceptable alternative solutions that could achieve the same goal. Feedback would be appreciated on this point. In the meantime, I will continue user testing, interviewing, reading feedback and conducting surveys to learn more about what our users want.

What was acquired?

Something that became clear from various discussions on GitHub and other forums is that people in the community were confused by what was actually acquired when Audacity "joined Muse Group". While the rest of the software industry is notoriously acquisition-happy, the free-software world has generally avoided those kinds of changes, in part because the code is often "owned" by the contributors—and the community. A request for clarification that was linked in various places raised a number of questions about the acquisition, such as:

• Is it even possible for a company to acquire a free and open source project licensed under the GPL?
• How exactly did Muse Group acquire Audacity?
• What rights and power does Muse Group legally have over the Audacity project?
• Can Muse Group even legally claim ownership over the project or do they simply own the trademarks to the name and logo?

It took a bit, but Daniel Ray ("workedintheory"), Muse Group's head of strategy, answered on May 25. In a nutshell: "Muse Group acquired the Audacity trademark and project infrastructure in addition to a license to the source code from contributors to the Audacity project in the form [of a] CLA." In a follow-up message, he confirmed that Muse Group had gotten signed CLAs from all of the relevant Audacity developers; that means that the company has control of the licensing of the code moving forward as well. Ray also pointed to a press release about the acquisition from April 30 that seemingly flew under the radar; for one thing, it filled in the strongly positive reaction from the project's founders, which was something that had been asked about.

But, in an unsurprising development, that same day Ray posted information about the CLA that would be required for contributions going forward. In it, he said that Muse Group intended to update the Audacity license to GPLv3 in order to make Audacity compatible with Virtual Studio Technology 3 (VST3) plugins, and with MuseScore, which recently switched to GPLv3. It is not entirely clear why the GPLv2+ license that Audacity has would be a problem for sharing code with either VST3 or MuseScore, however. He did try to reassure the community, though: "Naturally, Audacity will remain free and open source with no artificial limitations or paid tiers."

But there are platforms like iOS where the GPL can be an impediment, he said, so Muse Group wants the flexibility to be able to further relicense if need be. In addition, it may offer additional services:

We will likely offer separate cloud services that Audacity users can take advantage of if they choose. These services will fund the future development of Audacity, in much the same way that MuseScore.com funds the development of MuseScore composition software.

As might be guessed, that set off another lengthy thread. Numerous commenters pointed out that, in their opinion, the reasons specified by Ray were not sufficient to overcome the problems that stem from a CLA of that nature. The crux of the matter is that the CLA puts Muse Group in a position to use contributions from the community in other products, even if Audacity itself remains free. As Ray put it: "The CLA also allows us to use the code in other products that may not be open source, which we intend to do at some point to support the continued development of Audacity." It is worth noting that while Ray and Keary have both committed to keeping Audacity available as free and open-source software, nothing in the CLA binds the company to doing so.

Audacity's future

There has been talk about forking the project or starting over from scratch, but it is not at all clear how serious any of that is. The Audacity team was obviously involved in the transaction, at least to the point of agreeing to sign the CLA for their contributions, though financial terms have not been disclosed. The team has been largely silent throughout the uproar, perhaps because much of the unhappiness is being expressed by Audacity users or unconnected FOSS community members, not project contributors. In his follow-up linked above, Ray suggested that may explain the lack of engagement:

Mostly, I don't think they really have too much to say much because nearly all of these people who are commenting are not people they know or that have had anything to do with the project in the past. This sudden influx is not from the Audacity contributor community, not really sure if even from the user community, but seem to place demands on a project they were never a part of.

I can see why they would prefer not to say too much.

A lengthy message from Shane Mueller gives his reasons for signing the CLA for his 15-year-old contributions to Audacity. He is impressed with what the team of "3-4 volunteer programmers and handful of regular non-programmer contributors" has done with the application over the years, but worries about the future:

The volunteer team is small and not growing, not young and getting older, mostly not really pro-audio or usability experts, and probably won't be contributing at all in another 10-15 years. Audacity will literally end if a couple key contributors took a step back from the project or retire. It will have no chance of even doing a new release, let alone putting substantial effort into things that will make more than incremental improvements. When people call for a fork, I wonder where they have been for the last 20 years or so--if they were really passionate enough to contribute to a mature project (ugh) for amateur users (ugh) using c++ (ugh), wx (ugh), having an ugly UI (ugh) and relying on large mishmash of audio libraries to figure out (ugh), all to enable cross-platform capability (ugh), I think they would be doing it already.

Mueller said that he would have been happy to sign a CLA for a hypothetical Audacity non-profit foundation—and still would be. But it takes a lot of time and effort to set up that kind of organization, which still does not solve the lack-of-contributors problem. Effectively, he does not see a good future for Audacity without a new approach; he is not interested in working on that himself, but is "willing to support those who are involved and let them try this new model for how the project will be sustained into the future".

It would seem that Muse Group has the current Audacity team on-board with its plans, and has added some additional developer-power to the project. That would seem to bode well for improvements, probably at a much more rapid pace. But the CLA may deter community contributions to the project going forward. Muse Group would seem to have taken that into account in its planning—in the near term, it may be no real change from the status quo.

If there truly is a groundswell of interest in an independent Audacity, obviously a fork is possible at any point while the code is available under the GPL. Or an interested group could start over; Mueller's message and other comments seem to indicate that Audacity might not have the most pleasant code base to work with. But it seems fair to say that if all of the developers with any substantial copyright in Audacity are happy with the Muse Group and its plans, that is clearly the right path for the project, even if it does not mesh entirely cleanly with what the FOSS world has come to expect. It may well be the only plausible way forward for the project.

Comments (22 posted)

Implementing eBPF for Windows

Extended BPF (eBPF), the general-purpose execution engine inside of the Linux kernel, has proved helpful for tracing and monitoring the system, for processing network packets, or generally for extending the behavior of the kernel. So helpful, in fact, that developers working on other operating systems have been watching it. Dave Thaler and Poorna Gaddehosur, on behalf of Microsoft, recently published an implementation of eBPF for Windows. A Linux feature making its way to Windows, in itself, deserves attention. Even more so when that feature has brought new degrees of programmability to the Linux kernel over the last few years. This makes it especially interesting to look at what the new project can do, and to ponder how the current ecosystem might evolve as eBPF begins its journey toward Windows.

Gearing up with open-source components

Simply named "eBPF for Windows", the project targets Windows 10 and Windows Server 2016 (and later). It is not a fork of the Linux code, presumably to avoid any GPL-related issues. Instead, Windows gets a different implementation, but not from scratch. Microsoft's project relies on pre-existing open-source components; it adds the missing pieces along with the necessary shims to interconnect them and to integrate them with Windows internals. It is available from GitHub as ebpf-for-windows, under the MIT license.

One of those components is uBPF, an independent user-space eBPF interpreter and an x86_64 just-in-time (JIT) compiler for eBPF. In 2015, which was the early days for eBPF, uBPF was introduced as a non-GPL implementation of the technology. It has seen little activity since then, but several projects, including DPDK, reuse its code. The Windows project pulls uBPF as a Git submodule, and literally does a #include of its code to embed the interpreter and the JIT compiler. uBPF only supports basic programs; the code in ebpf-for-windows extends it, for example to implement eBPF maps and their related helper functions.

The tooling side for handling eBPF programs on Windows should look familiar to Linux users. The Clang/LLVM back-end remains the main tool to compile programs written in C into eBPF bytecode instructions. The netsh command-line tool, which offers program management and introspection similar to some extent to bpftool, relies on a shared library that should provide an API compatible with libbpf, thus ensuring the portability of loader applications.

The last component used by the project is the PREVAIL verifier, which is another Git submodule that gets pulled into ebpf-for-windows. PREVAIL was developed as part of a research project involving VMware Research, and is best described in the accompanying publication (note that some of the content is now out-of-date). Unlike the Linux verifier, it relies on formal methods to determine the safety of programs. It uses an abstract interpretation layer that aggregates the states after several execution streams rejoin, meaning that, for example, the states of the registers for the different branches of an if/else block are merged together at the end of that block to avoid producing too many combinations of paths.

By contrast, the Linux verifier checks all paths independently: two consecutive if/else blocks produce four paths to explore, rapidly leading to a "path explosion". But the Linux verifier mitigates this by "pruning" some parts of the paths that are known to be safe, once they have been reached and validated from another branch.

PREVAIL is claimed to be better at recognizing valid programs than the Linux verifier, including programs with loops. It also scales better with complexity, and can validate some programs for which Linux would go over its limit of one-million validated states, thus would fail verification. However, the Linux verifier completes validation more quickly when it accepts a program, and consumes less memory. It is also finely tailored to support all of the features that the programs can use and their corner cases, while PREVAIL misses checks for several elements like eBPF-to-eBPF function calls, packet reallocation (when its size changes), or 32-bit subregister tracking. PREVAIL is under active development, and Thaler is contributing to it along with the creator and maintainer, Elazar Gershuni. Together they intend to address some of these limitations: they recently added support for checking termination of eBPF programs.

Taking marks

Equipped with these components, eBPF for Windows provides a working eBPF runtime. But the project is in its infancy. It brings support for two eBPF hooks: XDP (for fast packet processing) and socket binding (equivalent to BPF_CGROUP_INET4_BIND and other related attach points on Linux). It implements the most basic map types: arrays and hash maps.

The repository contains a few examples. The Getting Started guide explains how to set up an XDP program to drop UDP packets with an empty payload in order to protect a DNS server from UDP flood attacks. Another sample program attaches to the hook for socket binding, and can be configured to enforce a limit on the number of sockets to which processes can bind. The program increments or decrements per-process counters (stored in a map) on bind and unbind operations.

Picking a direction

These samples are simple, but the project is just getting started: Where is it heading? The authors made it clear in their blog post that they aim at providing good compatibility with Linux eBPF: "The intent is to provide source code compatibility for code that uses common hooks and helpers that apply across Operating System ecosystems."

Some existing hooks and helper functions, of course, are tightly linked to Linux internals. Some features, like direct calls to kernel functions, will be downright dependent on the operating system. But for the rest, the objective is to reach some level of parity with Linux, including for tracing kernel and user-space functions by reusing, for example, Event Tracing for Windows or DTrace. Tracing user applications can probably work as they do for Linux.

Regarding kernel tracing, the two systems do not have the same internal functions but, at least, through eBPF they should be able to share a common way and workflow to attach probes. Interestingly, the authors of the project already have a new hook in mind to implement file-system "mini-filters" with eBPF on Windows. It seems likely that they will add more in the future. In defining a common way to probe a kernel, perhaps the program hooks themselves will end up as an implementation detail if the eBPF workflow, tooling, and runtime has the same capabilities on all systems and constitute the core of that "interface".

Currently, the disparity in features translates into a number of issues being opened on the GitHub repository. Contributions to the different components will also be necessary. The authors have pushed some of their changes to uBPF and have been contributing to PREVAIL for several months already. It is worth noting how they intend to deal with maps: they would like to reuse the implementation from generic-ebpf, which is yet another uBPF-based runtime that targets FreeBSD in particular.

Alan Jowett, from Microsoft, summarized the project's motivation as: "Any code that could be generic should be moved to a more generic project and pulled in via a sub-module." This reads as an intent to upstream everything possible to uBPF, PREVAIL, and possibly other projects in the future, so as to retain only the minimal amount of shims in ebpf-for-windows and to make the generic components reusable by other projects.

The road ahead

Ideally, most eBPF programs would behave the same way on Linux and Windows. Some engineering effort will be necessary to reach that point. By reimplementing an existing technology, Microsoft saves on the design process, but it will have to catch up with the specific functionalities. There is more than a simple instruction set to eBPF: it comes with many hooks, maps, helpers, user space operations, and features like tail calls, function calls, BPF type format (BTF) information, and many others. uBPF lacks most of these. These items may gain support in time, a fair portion of them should hopefully be generic enough to make eBPF programs portable. Adding JIT compilers for new architectures should not be a major issue, DPDK has one for arm64 already. Any feature that relies on kernel BTF information will likely be tied to an operating system, though.

Compatibility for the verifiers is another concern. Of all the design choices for the Windows implementation, the use of PREVAIL is one of the most interesting because it already has some advantages over Linux. It accepts a larger range of valid programs and is less affected by the path explosion, to the detriment of performance and exhaustiveness of the checks. As a consequence, some programs may be considered valid only by Linux, others only on Windows. This should provide an incentive to improve the Linux verifier, to make it faster on complex sequences, and perhaps help it validate more programs. Full parity will definitely be a challenge.

One may wonder how important it is to ensure cross-operating-system compatibility for eBPF. For a start, Microsoft's interest in the technology would likely be limited if it could not support existing programs. The company could just as well develop its own solution, without bothering to integrate external components. Portability will be necessary to limit ecosystem fragmentation and, more generally, to warrant adoption on Windows. It will be particularly important at a time when the generic-ebpf project might benefit from the exposure and regain some activity. That would provide support on yet more systems and, since static linking is being introduced in libbpf, paving the way to the creation of eBPF libraries.

However, the effort cannot come from Microsoft alone. Synchronization with the existing eBPF community will be essential to make the technology progress in a way that all systems can support. On Linux, eBPF has been used in production for some time, at scale, by big players like Facebook, Google, and Netflix. It has been spreading over the Kubernetes ecosystem for networking, observability, and security with projects like Cilium. There is no way that Linux developers will put eBPF "on hold" to wait for Windows. Thaler and Gaddehosur are aware that a lot of communication will be required:

We are announcing this now while the project is still relatively early in development because our goal is to work in collaboration with the robust eBPF community to make sure that eBPF works great on Windows, and everywhere else.

The project has a dedicated Slack channel named #ebpf-for-windows on https://ebpf.io/slack. Regular meetings are set up until July, at least, to triage and address the GitHub issues. A dedicated mailing list should follow.

The degree of involvement that will come from Linux developers will be decisive, but is hard to predict yet. The announcement of eBPF for Windows is still fresh: there were comments on social networks (enthusiastic overall, with a few expected mentions of the "embrace, extend, and extinguish" strategy — Microsoft has a history), but little reaction has emerged from the Linux world for now.

The journey is just starting

The "eBPF for Windows" project is ambitious but, in its early days, it misses many features supported on Linux: some parity on program types, map types, helpers, and other items will be required to make it viable. This could explain the absence of a clear reaction from the Linux developers, who may be waiting to see if the new implementation lives up to its promise. To show that it does, the authors will need to catch up with development to support more complex use cases on Windows. They must also draw the interest and participation of more contributors, external to Microsoft, if they want to ensure the success of the project.

If they succeed, developers may eventually benefit from eBPF code blocks shared as libraries common to the two systems. User-space libraries, tooling, applications, and compatibility test suites could be extended and run across several environments. The eBPF ecosystem would then profit from fresh ideas coming from the Windows world, and friendly competition will hopefully lead to performance improvements on both sides. As an optimistic vision for the long term, assuming a common basis can be found to express equivalent probes for both systems, eBPF programs might end up as some form of control-plane API to manage networking and observability on different types of nodes. Such interfaces are starting to emerge in cloud-native computing, and a cross-environment eBPF would likely play a role in this.

Of course, there is much to accomplish before that; the project is just starting. Yet, as it stands, this is already a formidable acknowledgment of the benefits eBPF brought to Linux and of its potential for the future. The realization of this potential will depend a lot on the dialogue and synchronization between the different communities. eBPF has just stepped outside of its Linux home to venture into the world.

Comments (16 posted)

Code humor and inclusiveness

Free-software development is meant to be fun, at least some of the time. Even developers of database-management systems seem to think that it is fun; there is no accounting for taste, it seems. Part of having fun is certainly allowing the occasional exercise of one's sense of humor while working on the code. But, as some recent "fix" attempts show, humor does not always carry through to developers all over the planet. Balancing humor and inclusiveness is always going to be a challenge for our community.

There is a function in the kernel scheduler that will, if things go badly wrong, inform users that a bug is present, describing it as "arch topology borken". The message is, of course, breathtaking in its clarity; users will immediately know what to do when they see it. Recently, though, a well-intentioned developer sent a patch changing the message to read "broken" instead. This patch was not accepted, but it did result in a brief discussion explaining the nature of the intended joke to the submitter.

The following day, somebody else attempted to fix another scheduler function containing a comment that cites "histerical raisins". This time, the poster was instructed to search for "humour", which is rather less illuminating. Other examples abound; one of the more amusing such attempts came last year, when a developer concluded that the title of this document required a spelling correction; the response this time politely declined the patch, but encouraged the poster by saying "rest assured that you did get [the] point!".

Anybody who has spent any amount of time trying to function in a non-native language understands that humor can be difficult. It is deeply tied to both the language it is expressed in and the specific context where it is found. Words that fluent speakers find funny can simply fly over the head of those who are less proficient, and attempts to be funny in a non-native language do not always go well. Your editor has a hard time getting a laugh from native English speakers; he has learned that it's better not to even try in other settings.

Source code is meant to be precise and understandable. Comments are there to help when the code itself is not enough to explain why a particular action is taken. When those comments contain plays on words, creative misspellings, or jargon-laden inside jokes, they will become less clear to people who may be struggling to understand even plainly written English. Such readers will trip over the language in question, and some of them may then be moved to try to "fix" it. The result is a certain amount of confusion and lost time.

One possible solution could be to eliminate this kind of play on words as an impediment to global free-software development. As Zhen Lei said in the first discussion linked above: "Linux is an open-source code for the world, so it's better to use a more common word." If we stuck with common words, we would see less confusion, fewer "fixes" for intentional humor, and possibly better participation overall.

But, remember, free-software development is supposed to be fun as well as useful; that is part of why many of us got into it in the first place. Turning a free-software project into a humor-free zone would make it distinctly less fun, which could be seen as an inclusiveness problem in its own right. The cure could be far worse than the disease.

Fortunately, nobody is proposing any such thing. Most of us are agreed that life can only be improved by something that brings a little smile in the middle of an extensive code-reading session. With any luck at all, our code will continue to acquire the occasional comment that makes it clear that we do not take ourselves too seriously.

But that means we will also continue to receive the occasional "fix" from readers who were unable to appreciate a humorous turn of phrase and wish to straighten it out in some way. Those will be the best occasions of all to demonstrate that, indeed, we do not take ourselves too seriously. A curt response from a developer who clearly feels that their time is being wasted may turn away an aspiring contributor who we would much rather keep. A kind response, explaining the phrasing in question, will help that contributor appreciate the humor, improve their language skills, and get them to the point where, someday, they will embed some humor in useful code of their own. Others, silently watching the conversation, may also benefit.

For better or worse, English is the language of the free-software development community. English is not the native language of a majority of our contributors, though, and some of those contributors will struggle with it at times. But, with some patience, we can have our code and laugh at it too.

Comments (87 posted)

quotactl_path() becomes quotactl_fd()

The quotactl() system call is used to manipulate disk quotas on a filesystem; it can be used to turn quota enforcement on or off, change quotas, retrieve current usage information, and more. The 5.13 merge window brought in a new variant of that system call that was subsequently disabled due to API concerns; its replacement is now taking form.

quotactl() has the following prototype:

    int quotactl(int cmd, const char *special, int id, caddr_t addr);

Quota manipulation is a filesystem-oriented operation, but quotactl() requires that the caller provide the name of the block device containing the target filesystem (as special). That can require users (who typically think in terms of mount points) or user-space tools to do a lookup to find out which block device underlies the filesystem of interest. For filesystems that do not have an underlying block device, quotactl() is not usable at all; among others, the UBIFS filesystem, which uses persistent memory for storage, is affected by this problem.

The new system call was introduced to address these issues:

    int quotactl_path(unsigned int cmd, const char *mountpoint, qid_t id,
    		      void *addr);

Rather than accepting a device name, quotactl_path() uses the path name of the mount point where the filesystem is to be found.

Shortly after this new system call was pulled into the mainline (during the 5.13 merge window), an LWN reader pointed out that quotactl_path() failed to follow contemporary best practices for system calls. In particular, it lacked a "flags" argument for future extensions, and there was no directory file-descriptor argument as found in system calls like openat2(). In response to those criticisms, the new system call was disabled in the 5.13-rc3 release so that the problems could be fixed.

On June 2, Jan Kara posted a proposed replacement for quotactl_path(). Rather than simply add the new parameters, though, the new call does away with the path name entirely:

    int quotactl_fd(unsigned int fd, unsigned int cmd, qid_t id, void *addr);

With quotactl_fd(), the caller is expected to provide an open file descriptor identifying the filesystem to operate on. The advantage of doing things this way is that the full complexity of handling the directory file descriptor, resolve flags, etc. can be deferred to openat2() rather than being reimplemented here. For usage involving multiple quotactl_fd() calls, reusing a file descriptor that only need be opened once should be more efficient anyway.

Note that there still is no "flags" argument. In this case, that should not be problematic; the system call can always be extended by adding new commands. In short, as Kara pointed out in the cover letter, the new system call looks a lot like ioctl(), with all the flexibility associated with that call.

Looked at from one angle, this incident could appear to be a failure of the process; how did a system call with these problems get into the mainline? Sometimes code is rushed into the kernel without adequate review, but this patch set was posted three times (in January, February, and March) before being merged. Developers clearly looked at the patches and a number of changes were made, but nobody caught the API problems.

But this episode could also be seen as an example of the process working exactly as it is supposed to. The period between the merge window and the 5.13 release is there to catch remaining issues, and this one was duly pointed out. The system call was immediately disabled to ensure that it would not be released in that form, after which it would likely have been necessary to maintain it indefinitely. And now a better replacement has been created.

That replacement has been reviewed (and approved) by a few relevant developers, including Sascha Hauer, the author of the original quotactl_path() implementation. It has not, as of 5.13-rc6, been pushed into the mainline kernel. Kara hasn't said whether he plans to get this work into 5.13 before its release; if so, the time to do so is quickly running out. The alternative is to push it during the 5.14 merge window; that would allow for another cycle of review to be sure that there are truly no more lingering issues. Given that this API has needed one rework and that 5.13 is due in less than two weeks, waiting may well prove to be the more prudent approach.

Comments (6 posted)

Privacy analysis of FLoC (Mozilla blog)

Over on the Mozilla blog, Eric Rescorla looks into some of the privacy implications of the Federated Learning of Cohorts (FLoC), which is a Google effort to replace third-party cookies with a different type of identifier that is less trackable. But less tracking does not equal no tracking. "People's interests aren't constant and neither are their FLoC IDs. Currently, FLoC IDs seem to be recomputed every week or so. This means that if a tracker is able to use other information to link up user visits over time, they can use the combination of FLoC IDs in week 1, week 2, etc. to distinguish individual users. This is a particular concern because it works even with modern anti-tracking mechanisms such as Firefox's Total Cookie Protection (TCP). TCP is intended to prevent trackers from correlating visits across sites but not multiple visits to one site. FLoC restores cross-site tracking even if users have TCP enabled."

Comments (43 posted)

Google's fully homomorphic encryption package

The Google Developers Blog has this announcement describing the release of a fully homomorphic encryption project under the Apache license. "With FHE, encrypted data can travel across the Internet to a server, where it can be processed without being decrypted. Google’s transpiler will enable developers to write code for any type of basic computation such as simple string processing or math, and run it on encrypted data. The transpiler will transform that code into a version that can run on encrypted data. This then allows developers to create new programming applications that don’t need unencrypted data." See this white paper for more details on how it all works.

Comments (51 posted)

Privilege escalation with polkit: How to get root on Linux with a seven-year-old bug (GitHub blog)

On the GitHub blog, Kevin Backhouse writes about a privilege escalation vulnerability in polkit, which "enables an unprivileged local user to get a root shell on the system" CVE-2021-3560 "is triggered by starting a dbus-send command but killing it while polkit is still in the middle of processing the request. [...] Why does killing the dbus-send command cause an authentication bypass? The vulnerability is in step four of the sequence of events listed above. What happens if polkit asks dbus-daemon for the UID of connection :1.96, but connection :1.96 no longer exists? dbus-daemon handles that situation correctly and returns an error. But it turns out that polkit does not handle that error correctly. In fact, polkit mishandles the error in a particularly unfortunate way: rather than rejecting the request, it treats the request as though it came from a process with UID 0. In other words, it immediately authorizes the request because it thinks the request has come from a root process."

Comments (57 posted)

Kernel release status

The current development kernel is 5.13-rc6, released on June 13. Linus said: "Nothing particularly special to say about this - rc6 is certainly smaller than rc5 was, so we're moving in the right direction".

Stable updates: 5.12.10, 5.10.43, 5.4.125, 4.19.194, 4.14.236, 4.9.272, and 4.4.272 were released on June 10, followed by 5.12.11, 5.10.44, 5.4.126, 4.19.195, 4.14.237, 4.9.273, and 4.4.273 on June 16. Not content with those, Greg Kroah-Hartman has started the review process for 5.12.12, 5.10.45, and 5.4.127; they are due on June 18.

Comments (none posted)

Aya: writing BPF in Rust

The first release of the Aya BPF library has been announced; this project allows the writing of BPF programs in the Rust language. "Over the last year I've talked with many folks interested in using eBPF in the Rust community. My goal is to get as many of you involved in the project as possible! Now that the rustc target has been merged, it's time to build a solid foundation so that we can enable developers to write great eBPF enabled apps".

Comments (8 posted)

linux.dev mailboxes for kernel developers

Konstantin Ryabitsev has announced a new service providing @linux.dev mailboxes for people to use with kernel development. The documentation page has more information. "This is a BETA offering. Currently, it is only available to people listed in the MAINTAINERS file. We hope to be able to offer it to everyone else who can demonstrate an ongoing history of contributions to the Linux kernel (patches, git commits, mailing list discussions, etc)."

Comments (21 posted)

Distribution quote of the week

I've been saying for years that as more and more consumers who just want a device which gives them those tools without a hassle move to just working on their phones and tablets, the share of Linux among people who actually want a computer will go up, and I think we're definitely seeing that among programmers, engineers, students, and gamers. Will that translate eventually to the general public? Maybe not, but that's okay. World domination isn't the only definition of success.

— Matthew Miller

Comments (none posted)

A possible copyright-policy change for glibc

The GNU C Library developers are asking for comments on a proposal to stop requiring developers to assign their copyrights to the Free Software Foundation. This mirrors the recent change by GCC, except that the community is being consulted first. "The changes to accept patches with or without FSF copyright assignment would be effective on August 2nd, and would apply to all open branches. The glibc stewards, like the GCC SC, continue to affirm the principles of Free Software, and that will never change."

Comments (none posted)

FSFE: REUSE Booster helps Free Software projects with licensing and copyright

The Free Software Foundation Europe introduces REUSE Booster. REUSE is a set of best practices to make Free Software licensing easier. "With REUSE Booster, we go one step further. We invite Free Software projects to register for getting help by the FSFE's legal experts. As the name suggests, this will boost the process of adopting the best practices as well as general understanding of licensing and copyright." The registration deadline is July 8.

Comments (3 posted)

Poettering: The Wondrous World of Discoverable GPT Disk Images

In a lengthy blog post, Lennart Poettering describes the advantages of using the unique IDs (UUIDs) and flags from the discoverable partitions specification to label the entries in a GUID Partition Table (GPT). That information can be used to tag disk images in a self-descriptive way, so that external configuration files (such as /etc/fstab) are not needed to assemble the filesystems for the running system. Systemd can use this information in a variety of ways, including for running the image in a container: "If a disk image follows the Discoverable Partition Specification then systemd-nspawn has all it needs to just boot it up. Specifically, if you have a GPT disk image in a file foobar.raw and you want to boot it up in a container, just run systemd-nspawn -i foobar.raw -b, and that's it (you can specify a block device like /dev/sdb too if you like). It becomes easy and natural to prepare disk images that can be booted either on a physical machine, inside a virtual machine manager or inside such a container manager: the necessary meta-information is included in the image, easily accessible before actually looking into its file systems."

Comments (60 posted)

Development quote of the week

The Google researchers examining these silent corrupt execution errors (CEEs) concluded "mercurial cores" were to blame – CPUs that miscalculated occasionally, under different circumstances, in a way that defied prediction. (That's mercurial as in unpredictable, not Mercurial as in the version control system of the same name.)

The errors were not the result of chip architecture design missteps, and they're not detected during manufacturing tests. Rather, Google engineers theorize, the errors have arisen because we've pushed semiconductor manufacturing to a point where failures have become more frequent and we lack the tools to identify them in advance.

— The Register (Thanks to Jörg Sommer)

Comments (5 posted)

CFP Deadlines: June 17, 2021 to August 16, 2021

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
June 20	August 22 August 29	DebConf	Online
June 20	October 11 October 12	Open Networking & Edge Summit + Kubernetes on Edge Day	Virtual
July 4	September 15 September 17	X.Org Developers Conference 2021	Virtual
July 10	August 6 August 8	openSUSE.Asia Virtual Summit 2021	Faridabad, India
July 11	November 9 November 10	Open Source Strategy Forum New York	New York, NY, USA
July 11	October 4 October 5	Open Source Strategy Forum London	London, UK
July 11	September 29 October 1	Linux Security Summit	Seattle, WA, and online
July 13	September 8 September 10	Linaro Virtual Connect	Online
July 15	August 7	Raku Conference	Online
July 15	September 16	Practical Open Source Information	Online
July 18	October 6	OSPOCon Europe	London, UK
July 23	August 18 August 19	eBPF Summit	Virtual
July 24	August 14 August 15	OpenFest 2021	Sofia, Bulgaria
July 27	August 5 August 8	Nest with Fedora	Online
August 13	September 20 September 24	Linux Plumbers Conference	Online

If the CFP deadline for your event does not appear here, please tell us about it.

Events: June 17, 2021 to August 16, 2021

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
June 1 June 30	Ceph Month June	Virtual
June 18 June 25	Akademy 2021	Online
June 18 June 20	openSUSE conference	online
June 22 June 23	Postgres Vision 2020	online
June 23	Linaro and Arm CCA Tech Event	Online
June 24 June 25	Build Meetup 2021	Virtual
July 9 July 11	State of the Map	Online
July 13 July 14	Netdev 0x15 Workshops & Tutorials	Online
July 19 July 23	Netdev 0x15 Main Conference	Online
July 21 July 25	GUADEC	Online
July 28 July 30	EuroPython 2021	Online
August 5 August 8	Nest with Fedora	Online
August 6 August 8	openSUSE.Asia Virtual Summit 2021	Faridabad, India
August 7	Raku Conference	Online
August 14 August 15	OpenFest 2021	Sofia, Bulgaria

If your event does not appear here, please tell us about it.

Alert summary June 10, 2021 to June 16, 2021

Dist.	ID	Release	Package	Date
Arch Linux	ASA-202106-23		apache	2021-06-11
Arch Linux	ASA-202106-21		gitlab	2021-06-11
Arch Linux	ASA-202106-20		inetutils	2021-06-11
Arch Linux	ASA-202106-27		isync	2021-06-11
Arch Linux	ASA-202106-29		kube-apiserver	2021-06-11
Arch Linux	ASA-202106-28		nettle	2021-06-11
Arch Linux	ASA-202106-24		polkit	2021-06-11
Arch Linux	ASA-202106-25		python-urllib3	2021-06-11
Arch Linux	ASA-202106-26		python-websockets	2021-06-11
Arch Linux	ASA-202106-22		thunderbird	2021-06-11
Arch Linux	ASA-202106-30		wireshark-cli	2021-06-11
CentOS	CESA-2021:2323	C7	389-ds-base	2021-06-14
CentOS	CESA-2021:2357	C7	dhcp	2021-06-14
CentOS	CESA-2021:2206	C7	firefox	2021-06-14
CentOS	CESA-2021:2147	C7	glib2	2021-06-14
CentOS	CESA-2021:2318	C7	hivex	2021-06-14
CentOS	CESA-2021:2314	C7	kernel	2021-06-14
CentOS	CESA-2021:1512	C7	postgresql	2021-06-14
CentOS	CESA-2021:2322	C7	qemu-kvm	2021-06-14
CentOS	CESA-2021:2328	C7	qt5-qtimageformats	2021-06-14
CentOS	CESA-2021:2313	C7	samba	2021-06-14
CentOS	CESA-2021:2033	C7	xorg-x11-server	2021-06-14
Debian	DSA-4928-1	stable	htmldoc	2021-06-09
Debian	DLA-2684-1	LTS	lasso	2021-06-10
Debian	DSA-4930-1	stable	libwebp	2021-06-10
Debian	DLA-2687-1	LTS	prosody	2021-06-16
Debian	DLA-2686-1	LTS	python-urllib3	2021-06-16
Debian	DSA-4929-1	stable	rails	2021-06-09
Debian	DLA-2685-1	LTS	squid3	2021-06-14
Debian	DSA-4931-1	stable	xen	2021-06-15
Fedora	FEDORA-2021-3cf08ffe38	F33	dino	2021-06-16
Fedora	FEDORA-2021-e9c84e6d26	F33	dotnet3.1	2021-06-16
Fedora	FEDORA-2021-cb4f3ab817	F34	dotnet3.1	2021-06-16
Fedora	FEDORA-2021-4b3fc547fe	F33	dotnet5.0	2021-06-16
Fedora	FEDORA-2021-1e0e04958d	F34	dotnet5.0	2021-06-16
Fedora	FEDORA-2021-8917c5d9d2	F33	exiv2	2021-06-10
Fedora	FEDORA-2021-7b03865dbc	F33	firefox	2021-06-11
Fedora	FEDORA-2021-af55f610eb	F34	firefox	2021-06-10
Fedora	FEDORA-2021-7ddb8b0537	F34	glibc	2021-06-14
Fedora	FEDORA-2021-db2bb87f35	F33	kernel	2021-06-15
Fedora	FEDORA-2021-bc2a819bc5	F34	kernel	2021-06-15
Fedora	FEDORA-2021-db2bb87f35	F33	kernel-tools	2021-06-15
Fedora	FEDORA-2021-bc2a819bc5	F34	kernel-tools	2021-06-15
Fedora	FEDORA-2021-508acb1153	F33	lasso	2021-06-11
Fedora	FEDORA-2021-bb3ea1e191	F34	lasso	2021-06-11
Fedora	FEDORA-2021-b950000d2b	F33	libxml2	2021-06-14
Fedora	FEDORA-2021-8a10199ab5	F34	microcode_ctl	2021-06-10
Fedora	FEDORA-2021-e145f477df	F33	mingw-openjpeg2	2021-06-12
Fedora	FEDORA-2021-c1ac2ee5ee	F34	mingw-openjpeg2	2021-06-12
Fedora	FEDORA-2021-cc85f79f63	F33	mod_auth_openidc	2021-06-11
Fedora	FEDORA-2021-46b017b771	F34	mod_auth_openidc	2021-06-11
Fedora	FEDORA-2021-b37cffac0d	F33	nginx	2021-06-11
Fedora	FEDORA-2021-393d698493	F34	nginx	2021-06-11
Fedora	FEDORA-2021-e145f477df	F33	openjpeg2	2021-06-12
Fedora	FEDORA-2021-c1ac2ee5ee	F34	openjpeg2	2021-06-12
Fedora	FEDORA-2021-0ad4bec5b1	F33	redis	2021-06-11
Fedora	FEDORA-2021-916f861096	F34	redis	2021-06-11
Fedora	FEDORA-2021-c0bec55ec7	F34	squid	2021-06-11
Fedora	FEDORA-2021-1c3f7963a5	F34	vmaf	2021-06-16
Mageia	MGASA-2021-0247	7, 8	djvulibre	2021-06-13
Mageia	MGASA-2021-0248	7, 8	docker-containerd	2021-06-13
Mageia	MGASA-2021-0252	7, 8	exif	2021-06-13
Mageia	MGASA-2021-0250	7, 8	gnuchess	2021-06-13
Mageia	MGASA-2021-0255	7, 8	irssi	2021-06-13
Mageia	MGASA-2021-0249	7, 8	jasper	2021-06-13
Mageia	MGASA-2021-0257	7, 8	kernel	2021-06-13
Mageia	MGASA-2021-0258	7, 8	kernel-linus	2021-06-13
Mageia	MGASA-2021-0256	7, 8	microcode	2021-06-13
Mageia	MGASA-2021-0246	7, 8	python-lxml	2021-06-13
Mageia	MGASA-2021-0245	7	python-pygments	2021-06-13
Mageia	MGASA-2021-0251	8	rust	2021-06-13
Mageia	MGASA-2021-0253	8	slurm	2021-06-13
Mageia	MGASA-2021-0254	7, 8	wpa_supplicant, hostapd	2021-06-13
openSUSE	openSUSE-SU-2021:0868-1	15.2	389-ds	2021-06-11
openSUSE	openSUSE-SU-2021:0870-1	15.2	pam_radius	2021-06-12
openSUSE	openSUSE-SU-2021:0861-1	15.2	python-HyperKitty	2021-06-09
Oracle	ELSA-2021-2353	OL8	.NET 5.0	2021-06-10
Oracle	ELSA-2021-2352	OL8	.NET Core 3.1	2021-06-12
Oracle	ELSA-2021-2323	OL7	389-ds-base	2021-06-09
Oracle	ELSA-2021-2323	OL7	389-ds-base	2021-06-09
Oracle	ELSA-2021-2291	OL8	container-tools:2.0	2021-06-10
Oracle	ELSA-2021-2370	OL8	container-tools:3.0	2021-06-14
Oracle	ELSA-2021-2371	OL8	container-tools:ol8	2021-06-14
Oracle	ELSA-2021-2357	OL7	dhcp	2021-06-10
Oracle	ELSA-2021-2357	OL7	dhcp	2021-06-10
Oracle	ELSA-2021-2359	OL8	dhcp	2021-06-10
Oracle	ELSA-2021-2417	OL7	gupnp	2021-06-15
Oracle	ELSA-2021-2417	OL7	gupnp	2021-06-15
Oracle	ELSA-2021-2363	OL8	gupnp	2021-06-10
Oracle	ELSA-2021-2318	OL7	hivex	2021-06-10
Oracle	ELSA-2021-2318	OL7	hivex	2021-06-10
Oracle	ELSA-2021-2314	OL7	kernel	2021-06-10
Oracle	ELSA-2021-9305	OL7	kernel	2021-06-14
Oracle	ELSA-2021-9305	OL7	kernel	2021-06-14
Oracle	ELSA-2021-9306	OL7	kernel	2021-06-15
Oracle	ELSA-2021-9306	OL8	kernel	2021-06-15
Oracle	ELSA-2021-9306	OL8	kernel	2021-06-15
Oracle	ELSA-2021-9307	OL7	kernel-container	2021-06-15
Oracle	ELSA-2021-9307	OL8	kernel-container	2021-06-15
Oracle	ELSA-2021-9294	OL7	krb5	2021-06-10
Oracle	ELSA-2021-9294	OL7	krb5	2021-06-11
Oracle	ELSA-2021-2354	OL8	libwebp	2021-06-10
Oracle	ELSA-2021-2305	OL7	microcode_ctl	2021-06-11
Oracle	ELSA-2021-2290	OL8	nginx:1.16	2021-06-10
Oracle	ELSA-2021-2397	OL7	postgresql	2021-06-14
Oracle	ELSA-2021-2397	OL7	postgresql	2021-06-14
Oracle	ELSA-2021-2361	OL8	postgresql:10	2021-06-10
Oracle	ELSA-2021-2372	OL8	postgresql:12	2021-06-12
Oracle	ELSA-2021-2375	OL8	postgresql:13	2021-06-12
Oracle	ELSA-2021-2360	OL8	postgresql:9.6	2021-06-10
Oracle	ELSA-2021-2322	OL7	qemu-kvm	2021-06-09
Oracle	ELSA-2021-2328	OL7	qt5-qtimageformats	2021-06-09
Oracle	ELSA-2021-2328	OL7	qt5-qtimageformats	2021-06-09
Oracle	ELSA-2021-9298	OL7	runc	2021-06-11
Oracle	ELSA-2021-2313	OL7	samba	2021-06-09
Oracle	ELSA-2021-2313	OL7	samba	2021-06-09
Red Hat	RHSA-2021:2370-01	EL8	container-tools:3.0	2021-06-10
Red Hat	RHSA-2021:2371-01	EL8	container-tools:rhel8	2021-06-10
Red Hat	RHSA-2021:2419-01	EL6	dhcp	2021-06-14
Red Hat	RHSA-2021:2418-01	EL7.2	dhcp	2021-06-14
Red Hat	RHSA-2021:2415-01	EL7.3	dhcp	2021-06-14
Red Hat	RHSA-2021:2414-01	EL7.4	dhcp	2021-06-14
Red Hat	RHSA-2021:2405-01	EL7.7	dhcp	2021-06-14
Red Hat	RHSA-2021:2416-01	EL8.1	dhcp	2021-06-14
Red Hat	RHSA-2021:2420-01	EL8.2	dhcp	2021-06-14
Red Hat	RHSA-2021:2417-01	EL7	gupnp	2021-06-14
Red Hat	RHSA-2021:2459-01	EL8.1	gupnp	2021-06-16
Red Hat	RHSA-2021:2422-01	EL8.2	gupnp	2021-06-14
Red Hat	RHSA-2021:2397-01	EL7	postgresql	2021-06-14
Red Hat	RHSA-2021:2392-01	EL8.1	postgresql:10	2021-06-14
Red Hat	RHSA-2021:2390-01	EL8.2	postgresql:10	2021-06-14
Red Hat	RHSA-2021:2372-01	EL8	postgresql:12	2021-06-10
Red Hat	RHSA-2021:2389-01	EL8.2	postgresql:12	2021-06-14
Red Hat	RHSA-2021:2375-01	EL8	postgresql:13	2021-06-10
Red Hat	RHSA-2021:2393-01	EL8.1	postgresql:9.6	2021-06-14
Red Hat	RHSA-2021:2391-01	EL8.2	postgresql:9.6	2021-06-14
Red Hat	RHSA-2021:2395-01	SCL	rh-postgresql10-postgresql	2021-06-14
Red Hat	RHSA-2021:2394-01	SCL	rh-postgresql12-postgresql	2021-06-14
Red Hat	RHSA-2021:2396-01	SCL	rh-postgresql13-postgresql	2021-06-14
Scientific Linux	SLSA-2021:2323-1	SL7	389-ds-base	2021-06-09
Scientific Linux	SLSA-2021:2357-1	SL7	dhcp	2021-06-14
Scientific Linux	SLSA-2021:2417-1	SL7	gupnp	2021-06-15
Scientific Linux	SLSA-2021:2318-1	SL7	hivex	2021-06-09
Scientific Linux	SLSA-2021:2314-1	SL7	kernel	2021-06-15
Scientific Linux	SLSA-2021:2260-1	SL7	libwebp	2021-06-09
Scientific Linux	SLSA-2021:2305-1	SL7	microcode_ctl	2021-06-14
Scientific Linux	SLSA-2021:2397-1	SL7	postgresql	2021-06-14
Scientific Linux	SLSA-2021:2322-1	SL7	qemu-kvm	2021-06-09
Scientific Linux	SLSA-2021:2328-1	SL7	qt5-qtimageformats	2021-06-09
Scientific Linux	SLSA-2021:2313-1	SL7	samba	2021-06-09
Scientific Linux	SLSA-2021:2263-1	SL7	thunderbird	2021-06-09
SUSE	SUSE-SU-2021:1962-1	OS9	ardana-neutron, ardana-swift, cassandra, crowbar-openstack, grafana, kibana, openstack-dashboard, openstack-ironic, openstack-neutron, openstack-neutron-gbp, openstack-nova, python-Django1, python-py, python-pysaml2, python-xmlschema, rubygem-activerecord-session_store, venv-openstack-keystone	2021-06-11
SUSE	SUSE-SU-2021:1943-1	OS8 OS9 SLE12	caribou	2021-06-10
SUSE	SUSE-SU-2021:1954-1	MP4.0 SLE15 SES6 SES7	containerd, docker, runc	2021-06-11
SUSE	SUSE-SU-2021:1963-1	OS7	crowbar-openstack, grafana, kibana, monasca-installer, python-Django, python-py, rubygem-activerecord-session_store	2021-06-11
SUSE	SUSE-SU-2021:1952-1	SLE12	csync2	2021-06-10
SUSE	SUSE-SU-2021:1948-1	SLE15	djvulibre	2021-06-10
SUSE	SUSE-SU-2021:1919-1	MP4.0 SLE15 SES6	firefox	2021-06-09
SUSE	SUSE-SU-2021:1960-1	OS8 OS9 SLE12	freeradius-server	2021-06-11
SUSE	SUSE-SU-2021:1959-1	SLE12	freeradius-server	2021-06-11
SUSE	SUSE-SU-2021:1944-1	SLE15	gstreamer-plugins-bad	2021-06-10
SUSE	SUSE-SU-2021:1980-1	OS8 OS9 SLE12	java-1_8_0-openjdk	2021-06-15
SUSE	SUSE-SU-2021:1912-1	MP4.0 SLE15 SES6	kernel	2021-06-09
SUSE	SUSE-SU-2021:1913-1	SLE12	kernel	2021-06-09
SUSE	SUSE-SU-2021:1915-1	SLE15	kernel	2021-06-09
SUSE	SUSE-SU-2021:1977-1	SLE15	kernel	2021-06-15
SUSE	SUSE-SU-2021:1975-1	SLE15	kernel	2021-06-15
SUSE	SUSE-SU-2021:1957-1	SLE12	libjpeg-turbo	2021-06-11
SUSE	SUSE-SU-2021:1958-1	SLE15	libjpeg-turbo	2021-06-11
SUSE	SUSE-SU-2021:1914-1	SLE15	libopenmpt	2021-06-09
SUSE	SUSE-SU-2021:1917-1	SLE15	libxml2	2021-06-09
SUSE	SUSE-SU-2021:1970-1	SLE15	postgresql10	2021-06-14
SUSE	SUSE-SU-2021:1940-1	OS7	python-Pillow	2021-06-10
SUSE	SUSE-SU-2021:1939-1	OS8	python-Pillow	2021-06-10
SUSE	SUSE-SU-2021:1938-1	OS9	python-Pillow	2021-06-10
SUSE	SUSE-SU-2021:1918-1	MP4.0 SLE15 SES6	qemu	2021-06-09
SUSE	SUSE-SU-2021:1947-1	OS9 SLE12	qemu	2021-06-10
SUSE	SUSE-SU-2021:1942-1	SLE15	qemu	2021-06-10
SUSE	SUSE-SU-2021:1951-1	SLE15	salt	2021-06-10
SUSE	SUSE-SU-2021:1978-1	SMS4	snakeyaml	2021-06-15
SUSE	SUSE-SU-2021:1979-1	SMS4.1	snakeyaml	2021-06-15
SUSE	SUSE-SU-2021:1956-1	MP4.0 SLE15 SES6	spice	2021-06-11
SUSE	SUSE-SU-2021:1927-1	SLE15	spice	2021-06-10
SUSE	SUSE-SU-2021:1928-1	MP4.0 SLE15 SES6	spice-gtk	2021-06-10
SUSE	SUSE-SU-2021:1961-1	MP4.0 SLE15 SES6	squid	2021-06-11
SUSE	SUSE-SU-2021:1932-1	MP4.0 SLE15 SES6	ucode-intel	2021-06-10
SUSE	SUSE-SU-2021:1930-1	OS8 OS9 SLE12	ucode-intel	2021-06-10
SUSE	SUSE-SU-2021:1929-1	SLE12	ucode-intel	2021-06-10
SUSE	SUSE-SU-2021:1931-1	SLE15	ucode-intel	2021-06-10
SUSE	SUSE-SU-2021:1933-1	SLE15	ucode-intel	2021-06-10
SUSE	SUSE-SU-2021:14748-1	SLE11	xorg-x11-libX11	2021-06-15
SUSE	SUSE-SU-2021:14747-1	SLE11	xterm	2021-06-14
Ubuntu	USN-4989-2	16.04	bluez	2021-06-16
Ubuntu	USN-4989-1	18.04 20.04 20.10 21.04	bluez	2021-06-16
Ubuntu	USN-4988-1	18.04 20.04 20.10	imagemagick	2021-06-15
Ubuntu	USN-4987-1	18.04 20.04 20.10 21.04	libimage-exiftool-perl	2021-06-10
Ubuntu	USN-4971-2	14.04 16.04	libwebp	2021-06-10
Ubuntu	USN-4986-2	14.04 16.04	rpcbind	2021-06-09
Ubuntu	USN-4986-4	14.04 16.04	rpcbind	2021-06-10
Ubuntu	USN-4986-3	18.04	rpcbind	2021-06-10

Full Story (comments: none)