Welcome to the LWN.net Weekly Edition for January 27, 2022

This edition contains the following feature content:

• Goodbye FLoC, hello Topics: Google makes another attempt at interest tracking on the web.
• Raw photo development with darktable: a look at this complex photo-editing tool.
• The kernel radar: folios, multi-generational LRU, and Rust: quick updates on what is happening in these areas.
• The rest of the 5.17 merge window: more goodies for the 5.17 kernel release.
• Supporting PGP keys and signatures in the kernel: a discussion over whether it makes sense for the kernel to parse and manage PGP keys.

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)

Goodbye FLoC, hello Topics

Back in May, we looked at a Google proposal to replace third-party cookies with something called the "Federated Learning of Cohorts" (FLoC). Third-party cookies were once used to track users all over the web so that advertisers could, supposedly, target their ads better, but, of the major browsers, only Google's Chrome browser fails to block them today. Google took a fair amount of flak for FLoC, since it was not perceived to be much of a win for users' privacy—and was mostly a sop to the (Google-dominated) web-advertising industry. Now the company is back with a different proposal that could, eventually, replace third-party cookies in Chrome: Topics.

FLoC would effectively pigeonhole users into "opaque" categories (cohorts), so that a given cohort ID would reflect a common set of interests those users have based on their recent browsing history. But exactly what information was being communicated is unclear, and was only opaque to browser users. Advertisers would presumably have been given some information about what a given cohort ID represented (so that they can target their ads) and web-site owners could potentially correlate additional information (e.g. account information) as well as track cohort ID changes over time.

No one, other than Google and web advertisers apparently, was lamenting the loss of third-party cookies, nor really looking for another "more limited" mechanism to track users' browsing habits. But Google sits in the catbird seat with respect to the web; the company is the dominant web-advertising player while also developing and distributing the most popular browser. That has allowed it to dictate, at least to a certain extent, how user tracking will (or will not) be done.

Apparently, the uproar over FLoC succeeded in diverting that particular plan, so Topics was born. Overall, Topics is more privacy-friendly than FLoC, though it still "leaks" more information than many will be comfortable with—that is the point, after all. But it is less opaque than its predecessor, with more controls for the user, though it is still an opt-out feature, so it will be on by default unless users take action.

The GitHub Topics API repository has more technical details than the introductory blog post linked above. The basic idea is that the browser tracks the user's top interests (based on a set of categories) over the past three weeks, then shares them with participating sites. The blog post describes it this way:

With Topics, your browser determines a handful of topics, like "Fitness" or "Travel & Transportation," that represent your top interests for that week based on your browsing history. Topics are kept for only three weeks and old topics are deleted. Topics are selected entirely on your device without involving any external servers, including Google servers. When you visit a participating site, Topics picks just three topics, one topic from each of the past three weeks, to share with the site and its advertising partners. Topics enables browsers to give you meaningful transparency and control over this data, and in Chrome, we're building user controls that let you see the topics, remove any you don't like or disable the feature completely.

The Topics "are thoughtfully curated to exclude sensitive categories, such as gender or race". Meanwhile, the mapping of sites to Topics will be done in the browser as the GitHub site describes:

The topics will be inferred by the browser. The browser will leverage a classifier model to map site hostnames to topics. The classifier weights will be public, perhaps built by an external partner, and will improve over time. It may make sense for sites to provide their own topics (e.g., via meta tags, headers, or JavaScript) but that remains an open question discussed later.

Advertisers (and others) can request information via a JavaScript call to document.browsingTopics(), which will return zero to three Topic IDs, one for each of the previous three weeks, in a random order. The top five Topics for a given week are collected and one random Topic chosen from the full list is added in; one of those six Topics will be chosen for the week. In addition, Topics are tracked in a somewhat complicated scheme to try to "prevent the direct dissemination of user information to more parties than the technology that the API is replacing (third-party cookies)". Said scheme restricts sending Topics to callers that have already called the Topics API for the user on another site that shares a Topic ID with the site in question. So browsers can only send a Topic ID if the advertiser has asked for Topics from a related site (i.e. one that shares the Topic). The GitHub site has a lengthy example to show how it all works.

The blog post shows a mockup of the interface for the browser that will allow users to view the Topics associated with them and to delete any that they do not wish to share. Users would need to do so regularly, though. The strategic use of Incognito Mode would also prevent those Topics from being added into the tracking, since browsing in that mode is not visible to the Chrome Topic-handling code.

Sites can opt-out of the Topic gathering by way of a HTTP header returned with their pages. Sites that do not want to participate can add the following header:

    Permissions-Policy: browsing-topics=()

To its credit, Google will also be honoring the opt-out header value (interest-cohort=()) that was available for FLoC, so sites that have already made that change (e.g. LWN.net) do not need to do anything further. The same complaints raised about this header for FLoC, with regard to web frameworks and content-management systems that do not provide ways to add this header, are still relevant, however.

Both FLoC and Topics are part of Google's Privacy Sandbox project. The FLoC experiment came to an end back in July; Topics is in the public discussion phase and has not been implemented in any browser at this point. While Google clearly hopes that other browser makers follow along, it is not clear that they will. Users do not seem to be clamoring for "relevant ads" (somehow defined); that feature is seen as somewhere between "creepy" and "annoying" (or both at once) by many. The Privacy Sandbox Topics site—another detailed, but less technical, description than the GitHub site—has a somewhat different take, naturally:

Interest-based advertising (IBA) is a form of personalized advertising in which an ad is selected for a user based on their interests, inferred from the sites they've recently visited. This is different from contextual advertising, which aims to match content on the page the user is visiting.

IBA can help advertisers to reach potential customers and help fund websites that cannot otherwise easily monetize visits to their site purely via contextual advertising. IBA can also supplement contextual information for the current page to help find an appropriate advertisement for the visitor.

But one of the more annoying aspects of targeted ads, those based on Google searches, are not really impacted by this change, it would seem. There is no easy way for fleeting searches, or those that resulted in a purchase that is not likely to be repeated anytime soon—or ever—to be removed from the information that Google provides its advertisers. Incognito Mode can help there, too, but the user has to remember to switch. While it is sometimes comical to see Google ads recommending the book you just purchased, or the hotel/flight/rental car you already reserved, it hardly seems like it leads to increased sales for the advertisers.

Overall, Topics is thought-out quite a bit better than its predecessor, but it still suffers from privacy concerns. Part of the problem is that some users do not want to see ads for unrelated interests when they visit a site—or they don't really want to see ads at all. There is a balance to be struck, since running web sites that provide useful content is not free; it is not clear that Topics truly finds that (unattainable?) sweet spot, however. Meanwhile, privacy advocates and users who care about such things are unlikely to be mollified, even if the grounding of FLoC is welcome.

Comments (77 posted)

Raw photo development with darktable

One of your editor's long-time hobbies is photography; it is an activity that can be rewarding even with the lack of any particular talent — a useful attribute. Photography has changed greatly over the years; as a result, those hard-earned darkroom skills are of little use, and photo processing has become yet another software problem. This is a field that supports a lot of proprietary software, but there is also no shortage of free software available. The time has come to combine work and pleasure and catch up with the state of free software for photography, starting with the darktable raw photo editor.

Raw images

Digital cameras normally produce their photographs in a convenient and compressed image format, most often JPEG. But, just as our brains perform a great deal of invisible processing to make our eyes work as well as they do, digital cameras do a lot of work between the sensor and the storage device. The data recorded by the sensor does not make for a particularly satisfying image until it has been through exposure compensation, white-balance adjustment, noise removal, sharpness adjustment, and even, with some devices, advanced manipulation like high-dynamic-range processing. The results from today's cameras can be amazingly good, but they invariably encapsulate a set of processing decisions and loses information from the original image.

Professional photographers — and hobbyists with an inflated sense of the quality of their snapshots — often choose to do that post-processing themselves. For such people, cameras can be convinced to write the raw data from the sensor (or something close to it) directly to a file in a format that is normally referred to as "raw" (or "RAW" even though it is not an acronym). Photographers can work with raw files to take full advantage of all of the data collected by the sensor and apply their own preferences — if they can get at that data. Naturally, every camera produces raw data in its own special, proprietary format. Fortunately, the free-software community has proved skilled at understanding these formats and writing decoders for them, so there is support for raw images from most available cameras.

Taking photographs in raw format implies a commitment to put some time into "developing" them into a more useful form; that is what a raw image editor is for. There are several of these editors available, including darktable, which is where your editor chose to start. In the name of "research", an afternoon was taken off work to wander in the local parks in search of a suitable raw image to process with darktable; the result is shown on the right. This image is a JPEG thumbnail created by the camera and stored with the raw image, extracted with dcraw. It is not a great work of art by any means, but it is useful to experiment with: there is a lot of contrast, and the rock formation (known as the "Second Flatiron") is somewhat lost in the haze that was present that day. This picture might just benefit from the sort of manipulation a raw editor can perform.

Running darktable

Launching darktable for the first time is a bit of an intimidating experience. It presents two columns of controls, most of which are hidden behind at least one layer of tabs; there are literally hundreds of things that one can tweak. Fortunately, the project has put some time into its documentation, which includes a set of steps to follow to learn how to make basic edits.

The first step is to import images into the application. Darktable can maintain its own directory full of images, but it is also happy to work with image files stored anywhere in the filesystem. There is a module available to import raw images directly from a USB-connected camera for those who prefer to work that way. In all cases, the end result is the "lighttable" screen, where thumbnails of all of the imported images are displayed.

The next step in the suggested workflow is to assign star ratings to each image in an iterative process, eventually eliminating all except for the best ones. Simply hitting "2", for example, marks the image under the cursor as a two-star photo. Images below a certain number of stars can be hidden (or deleted outright), allowing the photographer to focus their effort on the best prospects. Users should remember that this is not a ride-sharing app, and so the full range of star ratings can be used without ill effect.

Then it is time to pick an image and go into the "darkroom" to process it into its final form. Darktable uses a pipeline model (the "pixelpipe") for this processing; there is a long list of modules that can perform specific tasks in this pipeline. These modules are arranged in a series, with each module operating on the output of the one that came before. As an image is passed through this pipeline, it is transformed from the raw format into (hopefully) what the photographer wants it to be. While there is a logical order in which to use many of the modules, darktable allows them to be ordered arbitrarily, and multiple instances of the same module can appear in different places in the pipeline.

As one studies those modules it becomes apparent that darktable is currently going through a major transition in how the pixelpipe is expected to work. Prior to the 3.0.0 release in at the end of 2019, darktable supported a processing mode called "display-referred"; thereafter, the "scene-based" workflow is used instead. The difference comes down to when the color mapping is performed on the raw image.

The dynamic range of the data in a raw file is greater than can be displayed on the screen or represented in a JPEG file; that is part of why photographers use the raw format. At some point, though, the dynamic range must be reduced so that the image can actually be displayed. The display-referred workflow performs that processing near the beginning of the pipeline, with all subsequent modules working in the display color space. In the scene-based mode, the color mapping is deferred until the end, after other processing has been done.

The advantage of the scene-based mode is that it retains the full dynamic range of the raw image for as long as possible, leading to better results at each step in the pipeline. The change makes sense, but even in the current darktable 3.8.0 release it is clearly incomplete. Many of the provided processing modules only work in one mode or the other, but they are all jumbled together in the interface (and the documentation) so the user must sort them out. If scene-based is the way to go, darktable would do well to simply hide all support for display-referred work by default.

Processing the image

The darkroom view is made up of three columns, with the subject image taking up the middle column. On the right, below the color histogram, is the set of processing modules, which can be displayed in a number of ways; clicking on any given module will open a pane with, potentially, several tabs of adjustments to tweak. The left column contains another set of modules, such as the color picker and image exporter, that don't operate directly on the image.

The first step with a new image is to set the overall exposure. The exposure module can be used to compensate for a photograph that was under- or overexposed in general. Indeed, the darktable documentation suggests slightly overexposing photographs ("exposing to the right") and correcting the exposure in postprocessing.

Adjusting the exposure is a simple matter of moving a slider, but one quickly encounters the complexity of the darktable interface — there are five different ways to adjust a slider. Left-clicking on the range will set the slider cursor to the indicated spot. One can use the mouse scroll wheel to make incremental adjustments; the keyboard arrow keys work in the same way. A right click on the slider, instead, pops up a two-dimensional control that can be used for extreme fine-tuning. Finally, double-clicking on a slider resets it to the default value.

The next step goes to the far end of the pipeline and the filmic rgb module, which performs the color mapping for the display. Here one can set the white and black points for the image, picking the portion of the dynamic range that will be used to create the final result. Many other adjustments can be done here, including contrast tweaking, but the intent isn't to get a final image yet.

Moving back to the earlier parts of the processing pipeline, the color calibration module can be used to correct the white balance of the image if the value chosen by the camera (and stored in the raw file) is incorrect. Setting the white balance can be as simple as clicking on a part of the image that should actually be white; as it happens, pictures with snow in them make this task easy. This module can perform much more sophisticated changes, though. For example, like almost all processing modules, it can use a mask to only operate on part of the image; if one has an image needing a different white balance in different regions, the color-calibration module can be employed twice, with masks, to get the job done. Changes far beyond white balance are possible as well.

Your editor played with these modules for a while, and also brought in the haze removal module to clean up the background, with reasonably good effect. At this point, though, something jumped out: the exposure modifications did a good job of bringing out the detail in the image, but at the cost of severely overexposing the sky, turning the Colorado blue sky white. Going back to the exposure module and playing for a while with parametric masks rectified this problem, in a crude manner at least.

A final step was to use the watermark module to add a tasteful LWN logo to the image. After that, one goes into the export module, which can be used to render the final image to disk. All of darktable's editing is non-destructive; the relevant data is kept in a "sidecar" file next to the pristine raw image. The export module will run the pipeline, then convert the result to the desired image format. Naturally, there is a wide range of options controlling just how the image should be exported. There is also a separate print module for getting images to paper.

After all that work, your editor ended up with the image shown to the right. This result, your editor's first with darktable, bears more resemblance to a preschooler's finger painting than actual art, of course. The color of the rock still is not right, and there are numerous artifacts along the skyline, for example. But it is an illustration of the sorts of things that can be done by even a naive darktable user.

There is, of course, a lot more there for the advanced user. Various modules can perform highly specialized processing in ways that, it seems, that only a user with a PhD in color management can understand. There is a whole mechanism for remembering the configuration of collections of modules that will clearly be useful for photographers who end up doing the same sort of processing repeatedly. If that's not enough, the whole thing can be scripted in the Lua language.

Community and conclusion

Darktable is licensed under version 3 of the GNU General Public License. The program is written mostly in C, with a handful of C++ files tossed in for good measure; it uses the GTK library for the user interface. The most recent release is 3.8.0, which came out in late December; it added a new keyboard shortcut system, a new diffuse/sharpen module, reworked perspective correction, a new demosaic algorithm, support for the Canon CR3 raw format, and more. The project produced one other major release (3.6.0) in 2021 as well, and seems to keep two-release-per-year cadence.

In the time since the 3.4.0 release (just over one year), the project has merged 4,071 changesets from 125 developers, so it does appear to have a reasonably wide contributor base. Of those developers, Pascal Obry was responsible for nearly 22% of those changesets, with Ralf Brown contributing 11%; the top five developers contributed just over half of the changes. The core of the project's community is thus small, as is often the case, but it is definitely not a one-person show.

The project is centered around GitHub, with most of its communication happening there. It does have a development mailing list but makes relatively little use of it; indeed, the project's contact page suggests that "the mailing lists should be your last resort". Discussion on the project's posted issues is active. All told, darktable looks like an active and healthy project, one that a photographer need not worry about depending on.

Darktable itself is a bit of an intimidating program, but it's not clear that it could be any other way. It is a power tool for photographers wanting absolute control over every aspect of their images. Potential users will need to invest a fair amount of time before they can expect to be proficient with it. For many casual photographers, the complexity of darktable will be a firm reminder of how much easier it is to just let the camera do the image-processing work. For those who are willing to put in the time, instead, darktable may well be the tool that puts them firmly in control of their art.

Comments (9 posted)

The kernel radar: folios, multi-generational LRU, and Rust

The kernel community is a busy place, so it is not even remotely possible to write full-length articles about everything that is going on. Other topics may be of interest, but not require a longer treatment. The answer is a collection of short topics covering developments that are on the radar; the selection this time around includes folios, the multi-generational LRU, and Rust in the kernel.

A folio update

Folios have been an active topic since they were first covered here less than one year ago. A folio, recall, is just a container for a struct page that is guaranteed not to be a tail page. It can thus be used to refer to memory, in units of a single page or larger, in a way that is more type-safe and requiring fewer run-time checks than when working directly with page structures. After some extensive discussion, the first set of folio patches was merged for the 5.16 kernel.

A large change of that nature to the memory-management subsystem naturally leads to fears of regressions, but the work in 5.16 appears to have been relatively problem-free. So 5.17 saw another round of folio-related changes, mostly focused on the page cache (which caches file data). In current kernels, the page cache holds, unsurprisingly, pages, but the 4KB page size used on most systems is often far too small to be efficiently managed. When dealing with files of anything but the smallest size, there is value in caching larger chunks at a time. The 5.17 conversion of the page cache to use folios is intended, among other things, to allow the use of "large folios" (a name chosen because the more descriptive "multi-page folios" was a little too long). Large folios might be huge pages, but they don't have to be limited to the huge-page sizes supported by the CPU; the plan is to support any folio size, as long as it is a power of two.

The 5.17 work adds the machinery to support large folios in the page cache, the low-level filesystem-support code, and in the XFS filesystem, but does not actually start using them yet. As Matthew Wilcox said in his pull request: "there may still be places I've overlooked which still have page size assumptions". So the coming development cycle will, presumably, focus on finding any such places so that the transition can happen in 5.18. Meanwhile, the more adventurous among us can enable large folios in 5.17 and help find the remaining sharp edges.

The multi-generational LRU

Another significant memory-management change that has been under development over the last year is the multi-generational LRU, which reworks how the kernel decides which pages to evict when memory is tight. Current kernels use a two-queue system, one each for pages deemed "active" and "inactive". Pages move between the queues based on accesses; when memory is needed, pages are reclaimed off the end of the inactive queue. The multi-generational work generalizes this setup into a larger number of queues, a change that seemingly improves the kernel's ability to identify the pages that are unlikely to be needed in the near future.

When Yu Zhao posted the sixth version of this patch set in early January, he added a request for review and a verdict as to whether it could be merged for 5.17. That sparked a long discussion on the state of this work. As part of that discussion, Michal Hocko (who also did a lot of detailed review of the patches) repeated a theme that has been heard with previous postings: that it would be better to see this work as a series of incremental changes rather than a big addition of new reclaim mechanism:

Changes in the reclaim path are paved with failures and reverts and fine tuning on top of existing fine tuning. The difference from your patchset is that they tend to be much much smaller and go incremental and therefore easier to review.

Jesse Barnes responded that an incremental series might be worse in this case:

I understand the desire for an "incremental approach that gets us from A->B". In the abstract it sounds great. However, with a change like this one, I think it's highly likely that such a path would be littered with regressions both large and small, and would probably be more difficult to reason about than the relatively clean design of MGLRU. On top of that, I don't think we'll get the kind of user feedback we need for something like this *without* merging it.

Linus Torvalds responded to Barnes, saying that this work "is worth going with". Hocko didn't disagree with Barnes, but did note that there are a lot of things needing fixing before the code could be merged in any case.

Zhao, meanwhile, has been actively trying to get supporters of this work to post to the list in favor of its inclusion. Those who responded include Holger Hoffstätte, Shuang Zhai ("the performance improvement is fabulous"), Suleiman Souhlal ("Android on ChromeOS has been using MGLRU for a while now, with great results"), Sofia Trinh, Donald Carr, and Oleksandr Natalenko.

There is clearly some interest in getting this work merged; it is just as clearly not in the cards for 5.17, though. Normally one would expect that a change this fundamental could take a long time yet to get in; given the pressure and the approval from Torvalds, though, it could happen a bit more quickly this time. Merging for 5.18 still seems optimistic, but sometime in 2022 could be a real possibility.

Rust for Linux

The project to make it possible to develop kernel modules in the Rust programming language continues to move forward; the third version of the Rust-support patch set was posted on January 17. A number of changes had been made to keep up with the Rust community and to get this work closer to ready for inclusion.

This version of the patch set supports (and thus requires) the recent 1.58 release of the compiler. The build system is now able to determine automatically whether a suitable Rust toolchain is available for building and, if something is missing, it will tell the developer what is needed. The cover letter notes that a couple of the unstable Rust features required for kernel work are becoming stable in near-future compiler releases. There is, however, still a discouragingly long list of required unstable features.

The series itself starts by increasing the maximum length of symbols that can be managed in the "kallsyms" mechanism. It seems that the name-mangling used by Rust can expand names considerably, to the point that 255 characters is not enough to store some names. Developers will not normally need to see the mangled names, but they will show up in kallsyms and may be surprising. Another preliminary step is to add C helper functions for a long list of things that already look like functions in the kernel — readb() or kmap(), for example — that are actually macros or are inlined. Those cannot be called directly from Rust, so they need to be turned into proper functions first.

Most of the Rust code itself currently appears in two crates. The first, called alloc, deals with memory allocation. The Rust language wasn't built with the idea that code might need to continue when a memory allocation fails; instead, the normal result is an immediate crash. Since crashing in kernel code is considered to be impolite, a modified allocator that can handle failures is required. As a Rust developer would expect, it returns a Result object that contains either a pointer to the allocated memory or an error indication, depending on what happened. Evidently the work to support fallible allocations is meant to go into the upstream Rust library, so the kernel's version of this crate may eventually be able to go away.

The other big crate is called kernel; it contains the rest of the impedance-matching code that makes kernel APIs look like proper Rust interfaces. These provide interfaces for char devices, the clock framework, file structures, file_operations vectors, memory-mapped I/O functions, mutexes, spinlocks, and more. A surprising amount of code is dedicated to the implementation of generic linked lists.

All told, it represents a lot of work toward making it possible to write kernel code in Rust. It is quite a bit of code that, at some point, is going to need to be more widely exercised if it is to progress in useful directions. That, of course, would be helped by getting this support into the mainline kernel where more developers can look at and work with it. Torvalds indicated at the 2021 Maintainers Summit that he expected to merge this work, but there is no indication of when that might happen. The timing is likely to come down to Torvalds and when he thinks that the time has come to open the door to this new language.

Comments (28 posted)

The rest of the 5.17 merge window

Linus Torvalds released 5.17-rc1 and closed the 5.17 merge window on January 23 after having pulled just over 11,000 non-merge changesets into the mainline repository. A little over 4,000 of those changesets arrived after our first-half merge-window summary was written. Activity thus slowed down, as expected, in the second half of the merge window, but there still a number of significant changes that made it in for the next kernel release.

The more interesting changes merged for 5.17 include:

Core kernel

• It is now possible to assign names to "private" anonymous-memory areas; this feature is useful when trying to optimize application memory use. See this article and this commit for more information.
• The kernel is now able to decompress kernel modules within the kernel itself, rather than relying on user space to do that work. This feature was added to allow the LoadPin security module to maintain the connection between the module code on the storage device and what gets loaded into memory.

Filesystems and block I/O

• The fanotify subsystem supports a new event type called FAN_RENAME. It is meant as a replacement for the old FAN_MOVED_FROM and FAN_MOVED_TO events that captures an entire rename operation in a single event; the old event types are, of course, still supported.
• The FUSE filesystem was running out of initialization flags, so the FUSE_INIT operation has been extended with a new set of flags. While known FUSE implementations have been shown to work with the extended flags, the possibility of a user-space surprise exists. Should one turn up, this change will probably need to be reverted and replaced with something more complicated.
• The "fscache" subsystem, which handles caching for network filesystems, has been torn out and rewritten from scratch. For the most part, there should be few, if any, user-visible changes resulting from this work. This merge commit provides an overview of this work and why it was done.
• The old /sys/class/dax compatibility option has been removed; this change, too, is not known to break any actually deployed systems but may be reverted if somebody complains.
• There is a new syntax for Ceph filesystem mounts that addresses a number of problems; see this documentation commit for an overview of what it looks like.

Hardware support

• Clock: R-Car Gen4 and S4-8 clock controllers, TI TPS68470 PMIC clock controllers, Allwinner D1 clock-control units, Qualcomm MSM8956/76, SDX65 and SM8450 global clock controllers, Toshiba Visconti5 clock controllers, MediaTek MT7986 clock controllers, Nintendo realtime clocks, and Sunplus SP7021 realtime clocks.
• Industrial I/O: Analog Devices AD7293 power amplifier current controllers, Analog Devices AD74412R/AD74413R I/O controllers, Analog Devices ADMV8818 high-pass/low-pass filters, Analog Devices AD3552R digital-to-analog converters, and Analog Devices ADMV1013 microwave upconverters.
• Miscellaneous: Mediatek MT6360 PMIC LED controllers, Mediatek SPMI controllers, MStar MSC313E timers, Xilinx AMS system monitors, Renesas R-Car Gen3 realtime processors, and Qualcomm MSM8996, QCM2290, and SM8450 interconnect providers.

  Also, Intel's "platform firmware runtime update" driver has been merged; it allows parts of the system firmware to be updated without the need to restart the system. Some more information can be found in this document.

• PHY: Qualcomm eDP PHYs, Microchip lan966x Ethernet PHYs, Intel Thunder Bay eMMC PHYs, and Freescale i.MX8M PCIE PHYs.
• Sound: Mediatek MT8195 audio DSPs, AMD Renoir audio DSPs, Texas Instruments TLV320ADC3001/3101 audio codecs, and Asahi-Kasei AK4375 codecs.
• Watchdog: Realtek Otto MIPS watchdog timers, Renesas RZ/G2L WDT watchdog timers, and Apple SoC watchdog timer.

Miscellaneous

• The perf ftrace command has a new latency subcommand to generate latency histograms, optionally using a BPF script for the data collection. This feature was brought over from the BCC tools.
• The "RTLA" set of tools for realtime system analysis has been added. These tools include osnoise (measures operating-system interference with task execution) and timerlat (measures timer latency).

Security-related

• Mitigation for straight-line speculation vulnerabilities has been merged; building a kernel with this protection will require GCC 12, once it is released.
• The new "page-table check" feature adds extra checks when new entries are added to process page tables. It is able to detect certain types of corruption and bring down the system before something worse happens; some information can be found in this commit.

Internal kernel changes

• The next batch of folio patches has been merged. This work converts most of the page-cache code to use folios, but does not yet quite complete the job. Various APIs related to the page cache have changed as a result. The XFS filesystem has also received a set of folio-conversion patches.
• The new kthread_run_on_cpu() helper creates a new kernel thread on the specified CPU and starts it running.
• vmalloc() now supports the __GFP_NOFAIL flag for those cases where an allocation absolutely cannot be allowed to fail. Developers considering using this flag should keep in mind Andrew Morton's admonition that "every use is a sin", though. The GFP_NOFS and GFP_NOIO flags are also now supported with vmalloc().
• The new make mod2noconfig build target creates a new kernel configuration where all subsystems formerly built as modules are, instead, disabled.
• The oldest LLVM release that can be used to build the kernel has been increased to 11.0.0. This commit explains the motivation for that change.
• The "cleancache" mechanism, which was merged in 2010, has been removed. It seems that there are no users of cleancache at this point, and thus no reason to keep it around. Most of the associated "frontswap" mechanism is also gone, and it is no longer possible to select frontswap as a separate configuration option.

The time has now come to stabilize all of that work that has just entered the mainline. That process can be expected to unfold over the next seven or eight weeks, with the final 5.17 release happening on March 13 or 20.

Comments (2 posted)

Supporting PGP keys and signatures in the kernel

A few weeks back, we looked at a proposal to add an integrity-management feature to Fedora. One of the selling points was that the integrity checking could be done using the PGP signatures that are already embedded into the RPM package files that Fedora uses. But the kernel needs to be able to verify PGP signatures in order for the Fedora feature to work. That addition to the kernel has been proposed, but some in the kernel-development community seem less than completely enthusiastic about bringing PGP support into the kernel itself.

Roberto Sassu proposed the addition of support for PGP keys and signatures based on earlier work by David Howells. Sassu is also proposing the Digest Lists Integrity Module (DIGLIM) for the kernel and is the owner of the Fedora change proposal to support DIGLIM in the distribution. That proposal was originally targeting Fedora 36, but it is not likely to be adopted for any Fedora release until both DIGLIM and PGP support are upstream.

Parser

In order to handle the keys and signatures, though, there is a need for the kernel to understand the PGP format, so Sassu proposed putting a parser into the kernel. As might be guessed, that drew complaints; Maciej S. Szmigiero wondered if there was a better way:

Aren't PGP keys simply RSA / ECC / EdDSA keys with additional metadata? Can't they be unwrapped from their (complex) PGP format in userspace and loaded raw into the kernel, in a similar way as they are sometimes used for SSH authentication?

This will save us from having to add complex parsers (a well-known source of bugs) into the kernel [...]

Sassu said that Howells had already implemented a parser that follows the RFC for PGP data; unwrapping it into another format still requires a parser of some kind. In addition, that code has been tested in several different ways:

I extensively tested the implementation with an ad-hoc fault injector, to see if the code can correctly handle errors. I also developed a fuzzer to corrupt the data before it is read by the kernel. Finally, I checked that there are not memory leaks. But I agree, there could still be bugs.

Meanwhile, an "in-kernel PGP Web of Trust", as Szmigiero asked about, would be available to a limited extent, Sassu said. Certain kernel keyrings, such as the Integrity Measurement Architecture (IMA) keyring, require that keys being added to them are vouched for by another key on the kernel keyrings; support for checking the PGP signature on a key and rejecting the key if the check fails is part of what Sassu has implemented in the patch set.

But Szmigiero was still concerned about an in-kernel parser:

A parser in userspace is preferred to one in kernel since if there is a bug somewhere its consequences are much less severe. And experience shows that parsers are especially prone to bugs. A userspace implementation can also be tightly sandboxed for extra security.

He also pointed out that there are existing user-space parsers for OpenPGP that could be used, but Sassu does not see that path as less worrisome:

However, it does not seem to me less risky to define a new format to upload the RSA key and the signature to avoid the complexity of PGP. Also, it does not seem more complex than PKCS#7, which is already in the kernel.

[...] Another concern that I have is that, the approach of using an OpenPGP library still requires the Linux distribution vendors to do a transformation from the source data they have to another format. They have anyway to certify this transformation, even if it is done in user space. Maybe it is easier to keep the original data and verify the minimum necessary to handle PGP keys and signature in the kernel, rather than verifying a library running in user space with many other functions.

PGP deprecated?

Jason A. Donenfeld had a more fundamental concern about adding PGP support to the kernel at all. "The general consensus in the crypto engineering world is that PGP ought to be on its way out." He pointed to a 2019 blog post as an example of the breadth of problems with PGP (and the applications that implement it, such as GnuPG). He suggested using an Ed25519-based signature mechanism with something like Minisign or signify in user space, and having only minimal code in the kernel; that would have "very few moving parts to break", he said.

But James Bottomley disagreed; while there are legions of PGP detractors, "no-one's actually been able to come up with a more usable replacement". Beyond that, Ed25519 is not supported by the Trusted Platform Module (TPM) and might never be; by the time the TPM standards organization adds new algorithms, it might skip over Ed25519 for something stronger. He said that the crypto community often wants minimal solutions, but those have "only a relatively small set of possible use cases and no future proofing", while more extensible solutions that are more complex get criticized "as being a 'swiss army knife'"

Antony Vennard thought that was the wrong way to look at things, though. There is already support for PKCS #7 in the kernel, adding PGP support further complicates things:

We already have one extensible system that is complicated in the kernel. This patch proposes to add a second one achieving the same purpose instead of a userspace solution to take advantage of the existing code, which I think would be preferable and safer.

Sassu replied that there are still barriers to the use of alternative mechanisms; whatever key format is adopted will still need some kind of parser and a way to verify signatures on the keys that will need to be present in the kernel. He has considered the problems and believes his approach achieves the right balance:

After several iterations, trying to remove anything that was not essential from the patch set, I came to the conclusion that having the logic for both the keys and the signatures was the best compromise. True, it means more maintenance effort for the kernel, but this ensures the best interoperability with the current ecosystem.

I think the code is not particularly complicated that would be impractical to review.

While the PGP format has lots of different packet types, the in-kernel parser "just needs to parse the key, user ID and the signature packet and subpackets", he said. The distribution ecosystem is one of his areas of concern with switching to alternative solutions; "I think that forcing all Linux distributions to do it seems unrealistic". But if a minimal PGP parser could be vetted, the distribution's use cases would be supported:

Parsing data in the PGP format seems to be the only barrier. Once we are confident that we parse this small number of packets correctly, the rest is just reusing the mechanisms already in place. And we make it easier for people to adopt security features.

He elaborated further on the distribution side of the puzzle in a reply to Donenfeld. Switching to another package-signing mechanism (based on Ed25519 as Donenfeld suggested, say) would require an enormous shift for the distributions, which would likely take years to accomplish:

More specifically, the first task would be to modify how RPMs are signed (and thus how they are verified). The second task would be to have a different way to certify the public key. Lastly, Linux distribution vendors would have to change their building infrastructure to use the new certified key, a new version of the rpm package manager which takes as input the new key, produces a different type of signature and embeds it in the RPM header.

[...] The aim of this patch set is to make some security features available in a short time, by significantly reducing the burden of Linux distribution vendors for managing those security features.

Donenfeld sympathized with the situation for distributions, but noted that it comes down to short-term versus long-term thinking; instead of putting a lot of work into a transition to a better scheme (which requires "evaluating *what* the better thing would be"), continuing to support a flawed (but functioning) system is an easier path forward. He wondered if that kind of thinking needed to come to a halt, at least for PGP:

I don't have a whole lot _technical_ to say about long term vs short term thinking, but it does strike me that PGP is one of these cases where people have known about the flaws for decades, but the ecosystem keeps being extended because people continue to go with the short term solutions, one by one, and now they've wound up here, at the doorstep of the kernel. Maybe if at some point somebody puts down the foot and says, "the road of short term intentions stops here," there might gradually be impetus toward looking into long term solutions, e.g. viable PGP replacements? Just a thought.

While Ed25519 might be attractive, Konstantin Ryabitsev said, its key management leaves something to be desired:

I am concerned that ed25519 private key management is very rudimentary -- more often than not it is just kept somewhere on disk, often without any passphrase encryption.

With all its legacy warts, GnuPG at least has decent support for hardware off-load via OpenPGP smartcards or TPM integration in GnuPG 2.3, but the best we have with ed25519 is passhprase protection as implemented in minisign (and even that is rudimentary -- if you need to sign 10 things, you will need to type in your passphrase 10 times, as there is no passphrase agent of any kind).

He said that the integration of support for FIDO2 into OpenSSH is the "most promising non-PGP development of PKI [public-key infrastructure] signatures that I've seen lately". Key management has been a known weakness for many of the public-key signature schemes over the years. which makes him "worried that it's going to result in a net loss in overall security".

It is less than clear where this proposal will lead at this point. The kernel is the obvious "trusted" place to store keys and verifying signatures made with those keys is a logical extension of that. But the resistance, both to PGP and to another in-kernel parser for a complicated format, may be too much to overcome.

Comments (20 posted)

A new Polkit vulnerability

Qualys has announced the disclosure of a local-root vulnerability in Polkit. They are calling it "PwnKit" and have even provided a proof-of-concept video.

Successful exploitation of this vulnerability allows any unprivileged user to gain root privileges on the vulnerable host. Qualys security researchers have been able to independently verify the vulnerability, develop an exploit, and obtain full root privileges on default installations of Ubuntu, Debian, Fedora, and CentOS. Other Linux distributions are likely vulnerable and probably exploitable. This vulnerability has been hiding in plain sight for 12+ years and affects all versions of pkexec since its first version in May 2009.

Updates from distributors are already rolling out.

Comments (42 posted)

Kernel release status

The current development kernel is 5.17-rc1, released on January 23. Linus said:

5.17 doesn't seem to be slated to be a huge release, and everything looks fairly normal. We've got a bit more activity than usual in a couple of corners of the kernel (random number generator and the fscache rewrite stand out), but even with those things, the big picture view looks very much normal: the bulk is various driver updates, with architectures updates, documentation, and tooling being the bulk of the rest.

Note that "basic" support for case-insensitive filesystem was added to the NFS client after the 5.17-rc1 release.

Stable updates: 5.16.2, 5.15.16, 5.10.93, and 5.4.173 were released on January 20. The massive 5.16.3, 5.15.17, 5.10.94, 5.4.174, 4.19.226, 4.14.263, 4.9.298, and 4.4.300 stable updates are in the review process; they are due at any time. What does "massive" mean? It turns out that 5.16.3 broke Greg Kroah-Hartman's scripts, which were not prepared for the possibility of more than 1,000 patches in a single update.

Note that, while it has not been announced formally, the end of 4.4.x is coming and there may not be many (if any) releases after 4.4.300.

Comments (none posted)

Netfilter project: Settlement with Patrick McHardy

The netfilter project, which works on packet-filtering for the Linux kernel, has announced that it has reached a settlement (English translation) with Patrick McHardy that is "legally binding and it governs any legal enforcement activities" on netfilter programs and libraries as well as the kernel itself. McHardy has been employing questionable practices in doing GPL enforcement in Germany over the last six years or more. The practice has been called "copyright trolling" by some and is part of what led to the creation of The Principles of Community-Oriented GPL Enforcement.

This settlement establishes that any decision-making around netfilter-related enforcement activities should be based on a majority vote. Thus, each active coreteam member at the time of the enforcement request holds one right to vote. This settlement covers past and new enforcement, as well as the enforcement of contractual penalties related to past declarations to cease-and-desist.

Full Story (comments: 29)

Git 2.35.0 released

Version 2.35.0 of the Git source-code management system has been released. There are a lot of changes, as usual; see the announcement and this GitHub blog entry for details.

Comments (10 posted)

Rust 1.58.1 released

Anybody who upgraded to the recent Rust 1.58.0 release will probably want to move on to Rust 1.58.1; among other things it contains a fix for a security vulnerability in the standard library. "We recommend all users to update their toolchain immediately and rebuild their programs with the updated compiler".

Comments (90 posted)

Conill: the FSF’s relationship with firmware is harmful to free software users

Ariadne Conill writes about the FSF's policy toward proprietary firmware and, specifically, the rules for "Respects Your Freedom" certification.

Purism was able to accomplish this by making the Librem 5 have not one, but two processors: when the phone first boots, it uses a secondary CPU as a service processor, which loads all of the relevant blobs (such as those required to initialize the DDR4 memory) before starting the main CPU and shutting itself off. In this way, they could have all the blobs they needed to use, without having to worry about them being user visible from PureOS. Under the policy, that left them free and clear for certification.

This is not a new story; see Papering over a binary blob from 2011, for example.

Comments (117 posted)

CFP Deadlines: January 27, 2022 to March 28, 2022

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

Deadline	Event Dates	Event	Location
February 4	March 29	Open Source 101	Online
February 8	February 19 February 20	Online Guix Days 2022	online
February 9	June 7 June 9	Open Infrastructure Summit	Berlin, Germany
February 13	April 20 April 22	foss-north Online 2022	Online
February 15	July 11 July 17	SciPy 2022	Austin, TX, USA
February 16	March 4 March 6	Binary T00ls Summit	Online
February 22	May 13	PostgreSQL Conference Germany	Leipzig, Germany
March 1	May 2 May 4	Linux Storage, Filesystem, and Memory-Management Summit	Palm Springs CA, USA
March 1	June 21 June 25	The Perl and Raku Conference 2022	Houston, Texas, USA
March 14	June 21 June 24	Open Source Summit North America	Austin, TX, USA
March 18	April 29 May 1	Linux Application Summit 2022	Rovereto, Italy

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

Events: January 27, 2022 to March 28, 2022

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

Date(s)	Event	Location
January 28 January 29	DevConf.CZ	online
February 3 February 4	CentOS Dojo, FOSDEM 2022	online, online
February 4	Offensive Security Conference 2022	Berlin, Germany
February 5 February 6	FOSDEM 2022	Online (Brussels), Belgium
February 8	Kernel Debug Stories for Arm (Linaro Connect Tech Webinar)	online
February 19 February 20	Online Guix Days 2022	online
March 4 March 6	Binary T00ls Summit	Online
March 7 March 11	Mozilla Festival 2022	Online
March 19 March 20	LibrePlanet 2022	Online
March 22	Nordic PGDay 2022	Helsinki, Finland
March 24	pgDay Paris	Paris, France

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

Alert summary January 20, 2022 to January 26, 2022

Dist.	ID	Release	Package	Date
CentOS	CESA-2022:0143	C7	httpd	2022-01-25
CentOS	CESA-2022:0204	C7	java-11-openjdk	2022-01-25
Debian	DLA-2894-1	LTS	aide	2022-01-25
Debian	DSA-5051-1	stable	aide	2022-01-20
Debian	DLA-2897-1	LTS	apr	2022-01-24
Debian	DSA-5054-1	stable	chromium	2022-01-23
Debian	DLA-2889-1	LTS	drupal7	2022-01-19
Debian	DSA-5049-1	stable	flatpak	2022-01-20
Debian	DLA-2892-1	LTS	golang-1.7	2022-01-21
Debian	DLA-2891-1	LTS	golang-1.8	2022-01-21
Debian	DLA-2896-1	LTS	ipython	2022-01-24
Debian	DSA-5050-1	stable	kernel	2022-01-20
Debian	DLA-2890-1	LTS	libspf2	2022-01-20
Debian	DLA-2901-1	LTS	libxfont	2022-01-25
Debian	DLA-2900-1	LTS	lrzsz	2022-01-25
Debian	DLA-2898-1	LTS	nss	2022-01-25
Debian	DSA-5062-1	stable	nss	2022-01-25
Debian	DSA-5057-1	stable	openjdk-11	2022-01-24
Debian	DSA-5058-1	stable	openjdk-17	2022-01-25
Debian	DLA-2893-1	LTS	pillow	2022-01-23
Debian	DSA-5053-1	stable	pillow	2022-01-21
Debian	DLA-2899-1	LTS	policykit-1	2022-01-25
Debian	DSA-5059-1	stable	policykit-1	2022-01-25
Debian	DLA-2895-1	LTS	qt4-x11	2022-01-24
Debian	DLA-2885-1	LTS	qtsvg-opensource-src	2022-01-24
Debian	DSA-5056-1	stable	strongswan	2022-01-24
Debian	DSA-5052-1	stable	usbview	2022-01-21
Debian	DSA-5055-1	stable	util-linux	2022-01-24
Debian	DSA-5060-1	stable	webkit2gtk	2022-01-25
Debian	DLA-2884-1	LTS	wordpress	2022-01-24
Debian	DSA-5061-1	stable	wpewebkit	2022-01-25
Fedora	FEDORA-2022-9d18d4159e	F34	binaryen	2022-01-25
Fedora	FEDORA-2022-a662b2def6	F35	binaryen	2022-01-25
Fedora	FEDORA-2022-e605d8760d	F35	expat	2022-01-21
Fedora	FEDORA-2022-b3b5ac4053	F35	harfbuzz	2022-01-22
Fedora	FEDORA-2022-b7ef5c55da	F34	kernel	2022-01-20
Fedora	FEDORA-2022-6d4082d590	F34	kernel	2022-01-22
Fedora	FEDORA-2022-a23dd56848	F35	kernel	2022-01-20
Fedora	FEDORA-2022-6352c313b7	F35	kernel	2022-01-22
Fedora	FEDORA-2022-a4bca77f88	F34	libreswan	2022-01-20
Fedora	FEDORA-2022-42e0892147	F35	libreswan	2022-01-20
Fedora	FEDORA-2022-78090d2099	F34	nodejs	2022-01-20
Fedora	FEDORA-2022-0eda327cb4	F35	nodejs	2022-01-20
Fedora	FEDORA-2022-8e3fbc74e9	F35	qt5-qtsvg	2022-01-21
Fedora	FEDORA-2022-2c73789458	F34	rust	2022-01-25
Fedora	FEDORA-2022-1bafa3fc91	F35	rust	2022-01-25
Fedora	FEDORA-2022-639b9d2b85	F35	texlive-base	2022-01-20
Fedora	FEDORA-2022-48b86d586f	F34	vim	2022-01-24
Fedora	FEDORA-2022-25a98f5d55	F35	webkit2gtk3	2022-01-23
Fedora	FEDORA-2022-1daf93c51d	F34	wireshark	2022-01-20
Fedora	FEDORA-2022-30411cb3c4	F35	wireshark	2022-01-20
Fedora	FEDORA-2022-dfe346f53f	F34	zabbix	2022-01-23
Fedora	FEDORA-2022-1a667b0f90	F35	zabbix	2022-01-23
Mageia	MGASA-2022-0031	8	expat	2022-01-25
Mageia	MGASA-2022-0028	8	glibc	2022-01-23
Mageia	MGASA-2022-0033	8	htmldoc	2022-01-25
Mageia	MGASA-2022-0026	8	kernel	2022-01-21
Mageia	MGASA-2022-0027	8	kernel-linus	2022-01-21
Mageia	MGASA-2022-0030	8	libreswan	2022-01-25
Mageia	MGASA-2022-0035	8	mysql-connector-c++	2022-01-25
Mageia	MGASA-2022-0036	8	phpmyadmin	2022-01-25
Mageia	MGASA-2022-0037	8	polkit	2022-01-26
Mageia	MGASA-2022-0029	8	python-celery	2022-01-25
Mageia	MGASA-2022-0032	8	python-numpy	2022-01-25
Mageia	MGASA-2022-0034	8	webkit2	2022-01-25
openSUSE	openSUSE-SU-2022:0150-1	15.3	aide	2022-01-21
openSUSE	openSUSE-SU-2022:0151-1	15.3	bind	2022-01-21
openSUSE	openSUSE-SU-2022:0135-1	15.3	busybox	2022-01-20
openSUSE	openSUSE-SU-2022:0019-1	15.3 SLE15	chromium	2022-01-24
openSUSE	openSUSE-SU-2022:0144-1	15.3	cryptsetup	2022-01-20
openSUSE	openSUSE-SU-2022:0178-1	15.3	expat	2022-01-25
openSUSE	openSUSE-SU-2022:0136-1	15.3	firefox	2022-01-20
openSUSE	openSUSE-SU-2022:0140-1	15.3	grafana	2022-01-20
openSUSE	openSUSE-SU-2022:0184-1	15.3	json-c	2022-01-25
openSUSE	openSUSE-SU-2022:0131-1	15.3	kernel	2022-01-19
openSUSE	openSUSE-SU-2022:0169-1	15.3	kernel	2022-01-25
openSUSE	openSUSE-SU-2022:0198-1	15.3 15.4	kernel	2022-01-26
openSUSE	openSUSE-SU-2022:0141-1	15.3	permissions	2022-01-20
openSUSE	openSUSE-SU-2022:0190-1	15.3	polkit	2022-01-26
openSUSE	openSUSE-SU-2022:0134-1	15.3	python-numpy	2022-01-20
openSUSE	openSUSE-SU-2022:0177-1	15.3	qemu	2022-01-25
openSUSE	openSUSE-SU-2022:0171-1	15.3	rust1.55	2022-01-25
openSUSE	openSUSE-SU-2022:0149-1	15.3	rust1.56	2022-01-21
openSUSE	openSUSE-SU-2022:0175-1	15.3	rust1.57	2022-01-25
openSUSE	openSUSE-SU-2022:0018-1	15.3 SLE15	stb	2022-01-21
openSUSE	openSUSE-SU-2022:0199-1	15.3	thunderbird	2022-01-26
openSUSE	openSUSE-SU-2022:0176-1	15.3 15.4	unbound	2022-01-25
openSUSE	openSUSE-SU-2022:0020-1	15.3	virtualbox	2022-01-24
openSUSE	openSUSE-SU-2022:0182-1	15.3	webkit2gtk3	2022-01-25
openSUSE	openSUSE-SU-2022:0157-1	15.3 15.4	zxing-cpp	2022-01-24
Oracle	ELSA-2022-0162	OL7	gegl	2022-01-19
Oracle	ELSA-2022-0162	OL7	gegl	2022-01-19
Oracle	ELSA-2022-0177	OL8	gegl04	2022-01-19
Oracle	ELSA-2022-0143	OL7	httpd	2022-01-19
Oracle	ELSA-2022-0143	OL7	httpd	2022-01-19
Oracle	ELSA-2022-0258	OL8	httpd:2.4	2022-01-25
Oracle	ELSA-2022-0204	OL7	java-11-openjdk	2022-01-25
Oracle	ELSA-2022-0204	OL7	java-11-openjdk	2022-01-25
Oracle	ELSA-2022-0185	OL8	java-11-openjdk	2022-01-25
Oracle	ELSA-2022-0161	OL8	java-17-openjdk	2022-01-19
Oracle	ELSA-2022-9028	OL7	kernel	2022-01-19
Oracle	ELSA-2022-9028	OL8	kernel	2022-01-19
Oracle	ELSA-2022-9028	OL8	kernel	2022-01-19
Oracle	ELSA-2022-0188	OL8	kernel	2022-01-21
Oracle	ELSA-2022-9029	OL7	kernel-container	2022-01-19
Oracle	ELSA-2022-9029	OL8	kernel-container	2022-01-19
Oracle	ELSA-2022-0199	OL8	libreswan	2022-01-19
Oracle	ELSA-2022-0274	OL7	polkit	2022-01-25
Oracle	ELSA-2022-0274	OL7	polkit	2022-01-25
Oracle	ELSA-2022-0267	OL8	polkit	2022-01-25
Red Hat	RHSA-2022:0228-01		OpenJDK 11.0.14	2022-01-24
Red Hat	RHSA-2022:0229-01		OpenJDK 11.0.14	2022-01-24
Red Hat	RHSA-2022:0165-01		OpenJDK 17.0.2	2022-01-24
Red Hat	RHSA-2022:0166-01		OpenJDK 17.0.2	2022-01-24
Red Hat	RHSA-2022:0236-01	OCP3.11	OpenShift Container Platform 3.11.570	2022-01-25
Red Hat	RHSA-2022:0260-01	OSP16.1	Red Hat OpenStack Platform 16.1 (etcd)	2022-01-25
Red Hat	RHSA-2022:0237-01	OSP16.2	etcd	2022-01-24
Red Hat	RHSA-2022:0258-01	EL8 EL8.2 EL8.4	httpd:2.4	2022-01-25
Red Hat	RHSA-2022:0204-01	EL7	java-11-openjdk	2022-01-24
Red Hat	RHSA-2022:0185-01	EL8	java-11-openjdk	2022-01-24
Red Hat	RHSA-2022:0233-01	EL8.1	java-11-openjdk	2022-01-24
Red Hat	RHSA-2022:0209-01	EL8.2	java-11-openjdk	2022-01-24
Red Hat	RHSA-2022:0211-01	EL8.4	java-11-openjdk	2022-01-24
Red Hat	RHSA-2022:0188-01	EL8	kernel	2022-01-19
Red Hat	RHSA-2022:0186-01	EL8.4	kernel	2022-01-19
Red Hat	RHSA-2022:0187-01	EL8.4	kernel-rt	2022-01-19
Red Hat	RHSA-2022:0232-01	EL8	kpatch-patch	2022-01-24
Red Hat	RHSA-2022:0231-01	EL8.4	kpatch-patch	2022-01-24
Red Hat	RHSA-2022:0199-01	EL8	libreswan	2022-01-20
Red Hat	RHSA-2022:0239-01	EL8.4	libreswan	2022-01-24
Red Hat	RHSA-2022:0246-01	EL8.4	nodejs:14	2022-01-25
Red Hat	RHSA-2022:0269-01	EL6	polkit	2022-01-25
Red Hat	RHSA-2022:0274-01	EL7	polkit	2022-01-25
Red Hat	RHSA-2022:0270-01	EL7.3	polkit	2022-01-25
Red Hat	RHSA-2022:0272-01	EL7.4	polkit	2022-01-25
Red Hat	RHSA-2022:0271-01	EL7.6	polkit	2022-01-25
Red Hat	RHSA-2022:0273-01	EL7.7	polkit	2022-01-25
Red Hat	RHSA-2022:0267-02	EL8	polkit	2022-01-25
Red Hat	RHSA-2022:0268-01	EL8.1	polkit	2022-01-25
Red Hat	RHSA-2022:0265-01	EL8.2	polkit	2022-01-25
Red Hat	RHSA-2022:0266-01	EL8.4	polkit	2022-01-25
Red Hat	RHSA-2022:0254-01	EL8.4	rpm	2022-01-25
Scientific Linux	SLSA-2022:0204-1	SL7	java-11-openjdk	2022-01-24
Scientific Linux	SLSA-2022:0274-1	SL7	polkit	2022-01-26
Slackware	SSA:2022-025-01		expat	2022-01-24
Slackware	SSA:2022-025-02		polkit	2022-01-25
Slackware	SSA:2022-019-01		wpa_supplicant	2022-01-19
SUSE	SUSE-SU-2022:0150-1	MP4.1 SLE15 SES6 SES7	aide	2022-01-21
SUSE	SUSE-SU-2022:0145-1	OS8 OS9 SLE12	aide	2022-01-20
SUSE	SUSE-SU-2022:14879-1	SLE11	aide	2022-01-25
SUSE	SUSE-SU-2022:0091-2	SLE15	apache2	2022-01-20
SUSE	SUSE-SU-2022:0151-1	SLE15	bind	2022-01-21
SUSE	SUSE-SU-2022:0135-1	MP4.1 SLE15 SES6 SES7	busybox	2022-01-20
SUSE	SUSE-SU-2022:0160-1	SLE12	clamav	2022-01-24
SUSE	SUSE-SU-2022:0144-1	SLE15	cryptsetup	2022-01-20
SUSE	SUSE-SU-2022:0178-1	MP4.1 SLE15 SES6 SES7	expat	2022-01-25
SUSE	SUSE-SU-2022:0179-1	OS8 OS9 SLE12	expat	2022-01-25
SUSE	SUSE-SU-2022:14878-1	SLE11	expat	2022-01-25
SUSE	SUSE-SU-2022:0136-1	MP4.1 SLE15 SES7	firefox	2022-01-20
SUSE	SUSE-SU-2022:14880-1	SLE11	firefox	2022-01-25
SUSE	SUSE-SU-2022:0137-1	SLE15 SES6	firefox	2022-01-20
SUSE	SUSE-SU-2022:0138-1	SMT12	grafana	2022-01-20
SUSE	SUSE-SU-2022:0139-1	SMT15	grafana	2022-01-20
SUSE	SUSE-SU-2022:14877-1	SLE11	htmldoc	2022-01-19
SUSE	SUSE-SU-2022:0166-1	OS8 OS9 SLE12	java-1_7_1-ibm	2022-01-24
SUSE	SUSE-SU-2022:0184-1	MP4.1 SLE15 SES6 SES7	json-c	2022-01-25
SUSE	SUSE-SU-2022:0197-1	MP4.1 SLE15 SES7	kernel	2022-01-26
SUSE	SUSE-SU-2022:0131-1	SLE15	kernel	2022-01-19
SUSE	SUSE-SU-2022:0169-1	SLE15	kernel	2022-01-25
SUSE	SUSE-SU-2022:0181-1	SLE15	kernel	2022-01-25
SUSE	SUSE-SU-2022:0198-1	SLE15	kernel	2022-01-26
SUSE	SUSE-SU-2022:0130-1	MP4.1 SLE15 SES7	kubevirt, virt-api-container, virt-controller-container, virt-handler-container, virt-launcher-container, virt-operator-container	2022-01-19
SUSE	SUSE-SU-2022:0133-1	OS9	openstack-monasca-agent, spark, spark-kit, zookeeper	2022-01-20
SUSE	SUSE-SU-2022:0141-1	SLE15	permissions	2022-01-20
SUSE	SUSE-SU-2022:0190-1	MP4.1 SLE15 SES7	polkit	2022-01-26
SUSE	SUSE-SU-2022:0189-1	OS8 OS9 SLE12	polkit	2022-01-26
SUSE	SUSE-SU-2022:0191-1	SLE15 SES6	polkit	2022-01-26
SUSE	SUSE-SU-2022:0134-1	SLE15	python-numpy	2022-01-20
SUSE	SUSE-SU-2022:0177-1	SLE15	qemu	2022-01-25
SUSE	SUSE-SU-2022:0200-1	SLE15	rust	2022-01-26
SUSE	SUSE-SU-2022:0171-1	SLE15	rust1.55	2022-01-25
SUSE	SUSE-SU-2022:0149-1	SLE15	rust1.56	2022-01-21
SUSE	SUSE-SU-2022:0175-1	SLE15	rust1.57	2022-01-25
SUSE	SUSE-SU-2022:0199-1	SLE15	thunderbird	2022-01-26
SUSE	SUSE-SU-2022:0176-1	MP4.1 SLE15 SES6 SES7	unbound	2022-01-25
SUSE	SUSE-SU-2022:0182-1	MP4.1 SLE15 SES7	webkit2gtk3	2022-01-25
SUSE	SUSE-SU-2022:0142-1	OS8 OS9 SLE12	webkit2gtk3	2022-01-20
SUSE	SUSE-SU-2022:0183-1	SLE15 SES6	webkit2gtk3	2022-01-25
SUSE	SUSE-SU-2022:0161-1	OS8 OS9 SLE12	zsh	2022-01-24
SUSE	SUSE-SU-2022:0163-1	SLE12	zxing-cpp	2022-01-24
SUSE	SUSE-SU-2022:0157-1	SLE15	zxing-cpp	2022-01-24
Ubuntu	USN-5243-2	14.04 16.04	aide	2022-01-24
Ubuntu	USN-5243-1	18.04 20.04 21.04 21.10	aide	2022-01-20
Ubuntu	USN-5021-2	16.04	curl	2022-01-20
Ubuntu	USN-5244-1	16.04	dbus	2022-01-20
Ubuntu	USN-5240-1	18.04 20.04 21.04 21.10	linux, linux-aws, linux-aws-5.11, linux-aws-5.4, linux-azure, linux-azure-5.11, linux-azure-5.4, linux-bluefield, linux-gcp, linux-gcp-5.11, linux-gcp-5.4, linux-gke, linux-gke-5.4, linux-gkeop, linux-gkeop-5.4, linux-hwe-5.4, linux-ibm, linux-kvm, linux-oem-5.10, linux-oem-5.13, linux-oem-5.14, linux-oracle, linux-oracle-5.11, linux-oracle-5.4, linux-raspi, linux-raspi-5.4	2022-01-19
Ubuntu	USN-5242-1	21.10	openvswitch	2022-01-20
Ubuntu	USN-5252-2	14.04 16.04	policykit-1	2022-01-25
Ubuntu	USN-5252-1	18.04 20.04 21.10	policykit-1	2022-01-25
Ubuntu	USN-5241-1	18.04	qtsvg-opensource-src	2022-01-19
Ubuntu	USN-5250-2	14.04 16.04	strongswan	2022-01-24
Ubuntu	USN-5250-1	18.04 20.04 21.10	strongswan	2022-01-24
Ubuntu	USN-5248-1	18.04 20.04	thunderbird	2022-01-21
Ubuntu	USN-5246-1	21.10	thunderbird	2022-01-21
Ubuntu	USN-5249-1	18.04 20.04 21.10	usbview	2022-01-21
Ubuntu	USN-5193-2	14.04 16.04	xorg-server	2022-01-26

Full Story (comments: none)