Welcome to the LWN.net Weekly Edition for May 7, 2020

This edition contains the following feature content:

• Making Emacs popular again: what should change to make Emacs one of the most-used editors?
• Popcorn Linux pops up on linux-kernel: an academic project to extend Linux systems across multiple computers.
• Authenticated Btrfs: a relatively simple change to Btrfs to make it resistant to offline attacks.
• Atomic extent swapping for XFS: safely moving chunks of data between files.
• PHP showing its maturity in release 7.4: a lot has changed in PHP over the years as PHP tries to leave its reputation behind.

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)

Making Emacs popular again

The Emacs editor predates Linux, and was once far more popular, but it has fallen into relative obscurity over the years. In a mega-thread on the emacs-devel mailing list, participants discussed various ideas for making Emacs more "attractive", in both aesthetic and in "appealing to more users" senses of that term. Any improvements to Emacs in that regard have numerous hurdles to overcome, however. There are technical questions and, naturally, licensing considerations, but there is also the philosophical question of what it is, exactly, that stops the venerable text editor from being more popular.

So square

The discussion started with post from "ndame" asking why Emacs is "so square"; the appearance of things like buttons could be improved with rounded corners, they said. Richard Stallman, one of the original authors of Emacs, seemed somewhat dismissive in his reply: "Perhaps we should implement a mode that puts cosmetics on Emacs so it will appeal to those who judge by the surface of things." But Stefan Kangas thought there was more to it than that:

He wondered if there was "any reason not to improve the default look". Stallman said that there are some technical barriers in finding someone interested in and capable of doing the work needed, but there is an overarching problem that needs to be addressed first:

Stallman did agree that the graphical design could improve usability, "but I have a feeling that the changes that would help are deeper issues than the shape of corners". The GUI interface only matters if Emacs users are leaving those features (e.g. the menu bar and tool bar) enabled, Eli Zaretskii said, but much of the advice out there on configuring Emacs suggests disabling those things.

Beyond that, though, there are bigger problems with Emacs as a whole, Joseph Garvin said. The Emacs user interface "doesn't look or behave like any other application", the keyboard shortcuts are different than other programs, and the terminology used in the Emacs world does not match with what users expect:

But "modernizing" Emacs (however defined) is likely to be a waste of the project's time, since its look is not what's holding it back, Ahmed Khanzada said. For example: "Terminal-based Vim is not like a modern application, yet is more popular than Emacs." The appeal of an editor that can be extended using the Lisp language is somewhat limited, he said. Spending a bunch of time and energy to give it a modern look would not change that and, by the time the work was done, the definition of "modern" will have changed again.

Popularity

Kangas wondered about the assertion of Vim's popularity; Khanzada pointed to a 2019 survey that showed Vim with a substantial lead over Emacs (20% to 3% is what he reported, though it shows 25% to 4% as of this writing). That survey showed that Visual Studio Code (VSC) is the clear winner, however, with 50+% of respondents using that tool. You could perhaps quibble with the survey's methodology, but the broad-brush numbers do not seem wildly out of line.

That set off some discussion of why users prefer the experience with VSC. "We need to figure out why VSC is so popular, and then fill in the areas that Emacs is missing", Po Lu said. Bob Newell thought that "the goal of making Emacs more accessible and more appealing is laudable and ambitious"; it is something that the project could accomplish, he said. He is worried, though, that today's software is aimed at "instant gratification" rather than long-term usability—and power.

Stallman agreed with that sentiment. But he would also like to see Emacs return to popularity as an editor of text for publication. Several noted that Org mode is already being used successfully for text-publication purposes. That mode is not familiar to Stallman and he was unable to learn much about using it for word processing by reading the documentation. Zaretskii pointed out that there is a high barrier to learning Org mode from its documentation, at least for the word-processing use case.

Once again, though, it seems quite unlikely that some putative, well-documented word-processing Emacs mode is likely to have users flocking to the editor. But Stallman said that the user profile for Emacs was much broader 30 years ago; he would like to see it be that way again. He personally does not see rounded corners as part of that, though he is not opposed to efforts in that direction; "[...] if you want to attract more users to Emacs, I think there are more important areas for improvement." Lu had some ideas along those lines, for example using starter kits (or packs) to help make the editor "more friendly to newcomers".

There was a difference of opinion about making changes to the defaults, though, in order to help newcomers. If changes need to be made for the sake of newcomers, ndame said, established users can just turn them off. For example, Cua Mode, which adds the "standard" keybindings for things like cut and paste (i.e. ctrl-c, ctrl-x, ctrl-v) to Emacs, should be on by default; "it could make the life of new users easier if they didn't have to turn it on explicitly and they could use their copy/paste keys from the start like they are used it to in other tools".

But Lu suggested adding a button for newcomers to turn on those features from the splash screen instead. Better still might be for Emacs to recognize a possible newcomer, ndame suggested:

There was some discussion of gathering feedback before deciding to change defaults and such, but Dmitry Gutov wondered if existing users are even relevant. If expanding the reach of Emacs is the goal, it may make sense to look at the problem differently:

Lu disagreed; "We should prioritize existing users over hypothetical users that don't even exist yet." But Gutov said that might be shortsighted; "I don't want Emacs to die out, and it will if we don't do the work of attracting new users." No real conclusion was reached; everyone would like to see the number of Emacs users (developers, testers, documentation writers, ...) grow, but how to do so is unclear at best.

Licensing

Back to rounded corners, Zaretskii said that the only thing standing in the way of that was code to implement it; "[...] patches to add such capabilities to Emacs are most welcome". But Emacs is multi-platform, Gutov said, which means that buttons look different on each. Even on the same platform, different graphics toolkits give different looks—and the looks change between toolkit releases.

Alex Bennée suggested that "unifying under a single cross-platform toolkit like GTK+" would avoid some parts of the problem, but he also noted that a longstanding bug in GTK+ had caused him to use Emacs with the Lucid toolkit instead. He also worried about the next generation: "I've been thinking about text editors for my children to use as they graduate from point and click programming to proper text and even I'm not sure I want their first experience to be Emacs."

Zaretskii pointed out that GTK+ is not really cross-platform. In addition, the bug in question is not considered to be one by the GNOME developers, which led Ulrich Mueller to muse about a switch to Qt. But Stallman was quick to put the kibosh on that; Qt is only available for GPL 2 and 3, using it would mean that if there is a GPL 4 someday, Emacs could not switch to it. "So we must avoid using Qt."

Electron was also raised as a possibility, but it turns out to have "freedom issues", Lu said. It is not clear how serious any of these ideas were; switching graphics toolkits is a decidedly non-trivial undertaking. It does seem like an indication that some in the Emacs development community are getting frustrated with the GUI version(s) of the editor. Beyond that, many of the Emacs developers do not even use the GTK+ version because of the bug, which leads to less interest in improving that version of Emacs; it all seems to be something of a mess.

The icons used by Emacs were also questioned in the thread, with licensing rearing its head there as well. The Emacs subreddit is apparently fertile ground for thoughts and suggestions as it came up a few times in the thread. For example, ndame reported "that a user posted a screenshot of an emacs toolbar with really sad looking icons at the end". There are icon sets available under the GPL that could be used instead, they asserted. But Zaretskii cautioned that things may not be that clear-cut:

Several icon sets were suggested, including GNOME icons, some from Wikimedia, and those from KDE, all of which are available under various free licenses (GPL, Creative Commons, LGPL). But there is more work to do than just identifying candidates, Zaretskii said:

But, ndame asked, shouldn't icons that come from GNOME, a longstanding free-software project, be perfectly acceptable to use in Emacs? Sadly, it is not so easy as that, Zaretskii said: "IANAL, but I think it has to be GPL v2+ at least. And perhaps we would also need the copyright assigned to the FSF." For example, the Wikimedia icons are available under the the LGPLv3 and Creative Commons Attribution-ShareAlike (CC BY-SA) 3.0 licenses, but neither of those would work for pieces that are part of the Emacs program, Stallman said. Without the "or later" on the LGPL grant, the Qt problem would exist; CC BY-SA 3.0 "is incompatible with every version of the GPL". But that may not matter in the end:

Zaretskii and Stallman were able to determine that icons for Emacs fall into that category, so they simply need to be available under any free license, which should simplify things—if someone gets the time and energy to work on the problem. Like most projects, Emacs suffers from a shortage of human power; a project to improve the GUI that may not be widely used by those developers could go wanting. And that, in a lot of ways, sums up the situation with the editor project.

Moving forward

Emacs is quite useful for its adherents; many of them see it is their main interface to their computers. Others use it regularly but less universally. There are even longtime Vim users (who may have started on vi, in truth) that need Emacs for certain tasks—me for example. It serves all of these users well, but does it really still have a role in ten, twenty, or forty years? It is not an easy question to answer, of course; certainly it will still be with us in both ten and twenty years, but how many users will it have in forty?

Part of the problem is that the dedicated following for Emacs is also pretty resistant to change to any major degree. That's not meant as a knock of any sort, simply an observation. There are plenty of examples in that huge thread of ideas that were seemingly shot down because they represent change that might upset existing users. But it would seem that some changes of some sort are needed to bring in new blood. If few or no new users are coming in and nothing is done to attract more, it can only lead to eventual extinction.

Hopefully that is not the path that Emacs is on—or if it is, that it changes direction before (too) long. It is one of the earliest free-software programs in existence; pre-dating the term "free software" by nearly a decade, in fact. Of course, the code itself need never disappear entirely, but a vibrant—growing—Emacs community would be wonderful to see.

In truth, we have barely scratched the surface of that mega-thread. There are plenty of sub-threads that went completely unmentioned here; those interested in Emacs development—warts and all—will find plenty to read and digest there. Whether Emacs ends up with rounded corners or not seems like simply the tip of the iceberg of things that might need to be addressed to make Emacs more newcomer-friendly. How that can happen within that community remains to be seen.

Comments (156 posted)

Popcorn Linux pops up on linux-kernel

The end of April saw the posting of a complex patch set called "Popcorn Linux distributed thread execution". It is the first appearance on the kernel mailing lists of an academic project (naturally called Popcorn Linux) that has been underway since 2013 or so. This project has, among other goals, the objective of turning a tightly networked set of computers into something that looks like a single system — a sort of NUMA machine with even larger than usual inter-node costs. The posted code, which is a portion of the larger project, is focused on process migration and memory sharing across machines. It is an interesting proof of concept, but one should not expect to see it merged in anything close to its current form.

Each node in a Popcorn system is a separate Linux host sitting on the network. Popcorn itself is started by loading a kernel module that is charged with connecting the larger system together. The module reads a list of IP addresses (IPv4 only) directly from a file (/etc/popcorn/nodes by default). Each machine will make a TCP connection to every node listed ahead of itself in this file, then wait for an incoming connection from every node listed afterward. Thereafter, each node is known by an integer ID which is simply its position in the nodes file.

There is a hard-coded maximum of 62 nodes. No sort of authentication is done for incoming node connections, which might seem like a bit of a security issue; indeed, the patch set warns against running Popcorn on machines connected to the Internet. There does not seem to be any provision for nodes going up or down or being absent entirely. Comments in the patch set say that the TCP-based communication system "is intended for Popcorn testing and development purposes only", suggesting that, someday, somebody will get around to implementing something better.

System calls

Unsurprisingly, some new system calls are needed to allow applications to work within the larger Popcorn Linux system. To start with, an application can query the set of available nodes with this new system call:

    struct popcorn_node_info {
	unsigned int status;
	int arch;
	int distance;
    };

    int popcorn_get_node_info(int *my_nid, struct popcorn_node_info *nodes, int len);

On return, my_nid will contain the ID of the node the caller is running on, and nodes, an array of len popcorn_node_info structs indexed by node ID, will be filled in with the details of the first len nodes (up to the number that actually exist, of course). The status field in each entry will be zero if the corresponding node is offline, one otherwise. The arch field will describe the node's architecture (POPCORN_ARCH_X86 in the current patch set, since x86 is the only supported architecture), and distance is always zero.

The system call to move the current thread to another node is:

    int popcorn_migrate(int node_id, void *uregs);

where node_id identifies the node to which the thread should be moved, and uregs is, for some reason, the contents of the processor registers to be restored when the thread resumes on the new node. The passing of the processor registers separately might be an artifact of a Popcorn feature that is not part of this patch set: the ability to move threads to remote nodes with a different processor architecture. In the posted patch set, threads can only move themselves; the underlying code is written to allow other processes to force a thread to move, though.

While popcorn_migrate() looks like a general facility to move threads around, in practice it seems to be a bit more limited than that. A moved ("remote") thread retains a connection to its "origin" node; indeed, the original thread is still present on the origin node, it is just prevented from executing while the remote thread is running. A remote thread can only be moved back to the origin, so migrating a thread between two remote nodes would be a two-step operation, first moving it back to the origin then to out the new node.

The current execution status of a thread can be had with the last of the new system calls in this patch set:

    struct popcorn_thread_status {
	int current_nid;
	int peer_nid;
	pid_t peer_pid;
    };

    int popcorn_get_thread_status(struct popcorn_thread_status *status);

This call will fill in status with the current node ID for the calling thread, the other node it is connected to, and its process ID on that node. If the thread is not currently migrated, both current_nid and peer_nid will be the ID of the origin node.

Supporting remote threads

Once a thread has been moved to another node, more work must be done to keep things synchronized. For example, if the remote thread exits, the origin thread must be made to exit too. A signal sent to the origin thread must be propagated to the remote version where the work is actually being done. All of this is handled by intercepting various actions and sending messages across the inter-node connections to cause the right things to happen. Some especially complicated code appears to be making futexes work across machines.

Migrating a thread sets up the basic information it needs to run, but leaves a lot of stuff behind; in particular, almost the entirety of the thread's memory-layout information still lives on the origin node, where it might well be shared with other threads. It is not surprising that memory management is the focus of some of the most complex code in the Popcorn patch set.

The set of virtual memory areas (VMAs) describing the thread's address-space layout will be shared with any other threads running in the same process — threads that probably have not been migrated to the same target node. So, while the migrated thread needs to mirror that VMA arrangement, it has little ability to change it without coordinating with the origin node. For VMAs, this coordination is handled by actually executing almost all operations at the origin.

Thus, for example, if the migrated thread calls mmap(), that call will be intercepted and shipped back to the origin for execution. The origin node will send back a response describing the result of the operation; the migrated thread's memory layout will then be adjusted to match. Other calls, including brk() and madvise() are handled in the same way.

Pages of actual memory need to be handled a bit differently, though, or performance will suffer horribly. Popcorn implements a protocol to allow the ownership of pages to move between nodes, much like ownership of cache lines can move between processors. Read-only copies of pages can be spread across a set of nodes, but only one node can be modifying a specific page at any given time. Much of the coordination is handled, once again, by the origin node, which handles tasks like sending and receiving copies of pages, invalidating pages on remote nodes, revoking page ownership, and more.

The patch set also adds a new madvise() operation, MADV_RELEASE, which explicitly releases a remote node's ownership of a range of pages.

Will it pop soon?

There is a lot more to Popcorn Linux than what has been posted to the list so far. There is a mechanism to run multiple kernels on the same machine, for example, using a modified version of the kexec mechanism. There is a whole fault-tolerance project underway. There is a mechanism to offload low-demand virtual machines to slow (but power-efficient) embedded boards, possibly running a different processor architecture. And more; the web site is well-populated with academic papers describing various parts of the system.

Popcorn Linux seems like an interesting project, so readers unfamiliar with how kernel development works may be surprised to see that this patch set, posted on April 29 and which has received a fair amount of attention on various Internet sites since, has not seen a single response on the mailing list. The reason for that is relatively straightforward, though: what has been posted is a pile of code, rather than a patch series that is intended for serious review and consideration. Patch 1 introduces the system calls, for example, but the structure definitions they rely on don't show up until Patch 5, and the messaging infrastructure, without which nothing works, shows up last. Your editor can attest that reading a patch series organized in this way is not a simple task; many busy kernel developers are unlikely to try.

One often hears complaints that the work done in academic settings almost never makes it into Linux; this seems paradoxical, given that the open development process behind Linux should be a natural fit for academic developers. This patch set shows where the roadblocks are, though. It represents many years worth of work, but none of that work was directed toward creating a patch set that is ready to be considered for merging.

To get this work even considered for upstream, the Popcorn Linux developers will have do a number of things. The patches will have to be reworked into a bisectable series, where each patch stands alone and can be considered on its own merits. The temporary messaging system will have to be replaced with something that is robust, secure, and fast. Performance benchmarks will have to be prepared, including the impact of Popcorn Linux on systems that are not using any of its features. Documentation is distressingly optional in kernel development, but a few pages of introductory material might help developers review the patches. And so on.

Doing all of that would be a lot of work, even before one gets into the code changes that are likely to become necessary during the review process. This work is expensive and is unlikely to lead to the publication of even a single thesis or academic paper. It is unsurprising that getting code of this complexity upstream tends to look unappealing to academic researchers. So that work is rarely done.

Sadly, that seems likely to be the fate of Popcorn Linux as well, unless somebody can come up with the funding and the motivation to make it suitable for the decidedly non-academic Linux kernel. Even if it is not merged, though, Popcorn Linux may eventually inspire some energetic developer to adopt some of its best ideas and get them upstream in some form. There is a lot of interesting work to be found in this project; hopefully some of it will eventually graduate from the academic setting and onto our systems.

Comments (17 posted)

Authenticated Btrfs

Developers who are concerned about system integrity often put a fair amount of effort into ensuring that data stored on disk cannot be tampered with without being detected. Technologies like dm-verity and fs-verity are attempts to solve this problem, as is the recently covered integrity policy enforcement security module. More Recently, Johannes Thumshirn has posted a patch series adding filesystem-level authentication to Btrfs; it promises to provide integrity with a surprisingly small amount of code.

Integrity-verification code at the filesystem or storage level generally works by calculating (and storing) checksums of each block of data. When it comes time to read that data, the checksum is calculated anew and compared to the stored value; if the two match, one can be confident that the data has not been modified (or corrupted by the hardware) since the checksum was calculated. If there is reason to believe that the stored checksum is what the creator of the data intended, then the data, too, should be as intended.

Solutions like dm-verity and fs-verity work by storing checksums apart from the data; fs-verity, for example, places the checksum data in a hidden area past the end of the file. The developers of more modern filesystems, though, have generally taken the idea that storage devices are untrustworthy (if not downright malicious) to heart; as a result, they design the ability to calculate, store, and compare checksums into the filesystem from the beginning. Btrfs is one such filesystem; as can be seen from the on-disk format documentation, most structures on disk have a checksum built into them. Checksums for file data is stored in a separate tree. So much of the needed infrastructure is already there.

Checksums in Btrfs, though, were primarily intended to catch corruption caused by storage hardware. The thing about hardware is that, while it can be creative indeed in finding new ways to mangle data, it's generally not clever enough to adjust checksums to match. Attackers tend to be a bit more thorough. So the fact that a block of data stored in a Btrfs filesystem matches the stored checksum does not, by itself, give much assurance that the data has not been messed with in a deliberate way.

To gain that assurance, Btrfs needs to use a checksum that cannot readily be altered by an attacker. Btrfs already supports a number of checksum algorithms, but none of them have that property. So the key to adding the needed sort of authentication to Btrfs is to add another checksum algorithm with the needed assurance. Thumshirn chose to add an HMAC checksum based on SHA-256.

Calculating an HMAC checksum for a block of data requires a secret key; without the key, the code can neither calculate checksums nor verify those that exist. This key must be provided when the filesystem is created; an example from the patch set reads like this:

    mkfs.btrfs --csum hmac-sha256 --auth-key 0123456 /dev/disk

Here, 0123456 is the authentication key to be used with this filesystem.

This key must also be provided when the filesystem is mounted; that does not happen directly on the command line, though. Instead, the key must be stored in the kernel's trusted keyring; the name of that key is then provided as a mount option. This (hopefully) keeps the key itself from appearing in scripts or configuration files; instead, the key must come from a trusted source at system boot time.

That is really about all there is to it. An attacker who lacks the trusted key can still read the filesystem, but they cannot make changes without breaking the checksums — and that will cause any such changes to be detected the next time the affected data is read. It is worth noting, though, that an attacker who can compromise the kernel can access the key or just have the kernel write the desired changes directly to the filesystem. Solutions like fs-verity, instead, usually don't allow the key anywhere near production systems; that makes the protected files read-only, but that is usually the intent anyway. So authenticated Btrfs is suitable for deterring offline attacks, but it may not be able to protect against as wide a range of attacks as some other technologies.

On the other hand, authenticated Btrfs requires minimal changes to the Btrfs code, and doesn't require the interposition of any other layers between the file system and the storage device. It may well prove useful for a range of use cases. The patch set is relatively young, though, and has not yet received much in the way of review comments. The real test will happen once developers find the time to give these changes a close look.

Comments (27 posted)

Atomic extent swapping for XFS

Normally, files exist in a filesystem to keep data contained within them separated; seeing data exchanged directly between files is often a sign of filesystem corruption. There are, however, use cases where it is desirable to be able to perform a controlled swap of data between a pair of files. Darrick Wong has recently posted a patch set implementing this feature for the XFS filesystem, but also making it available in a general way.

As it happens, XFS has had a data-swapping capability for some time: the rigorously undocumented XFS_IOC_SWAPEXT ioctl() command will exchange extents of data in two files. This feature exists for one purpose in particular: defragmentation of filesystems. The xfs_fsr utility does its job by scanning a filesystem for the most highly fragmented files — those that are split up into the largest number of extents. It then creates a new file with a single extent large enough to hold one of the fragmented files and copies the data over. The final step is an XFS_IOC_SWAPEXT operation to atomically replace the old file's data blocks with the new, defragmented version.

It seems, however, that there are other interested users out there. Application developers would like a way to replace some or all of the contents of a file in an atomic and safe way — one which preferably does not leave the file corrupted if the system goes down partway through. Currently such tasks must be handled by creating a temporary file, populating it, and renaming it over the original; this works, but it is a multi-step affair that is hard to get right.

With a well-implemented "swap range" operation, atomically replacing a portion of a file's contents can be done with a series of operations like:

• Create a new file in the same filesystem as the one to be modified, using the O_TMPFILE option.
• Populate the temporary file with the new data. If only a portion of the file's contents are to be changed, the application can start with an FICLONE ioctl() operation to "copy" the old data in by reference; then only the data to be changed needs to be written.
• Perform the swap operation to move the new data into the old file.
• Close the temporary file, which will then be deleted by the kernel.

Other processes working with the file will see either the old or the new data, but they will never see a combination of the two.

Wong's patch set adds a new FISWAPRANGE ioctl() command to the virtual filesystem layer, meaning that any filesystem can implement it (though only XFS is implemented so far). An application fills in a structure describing the operation that is to be performed:

    struct file_swap_range {
	__s64		file1_fd;
	__s64		file1_offset;
	__s64		file2_offset;
	__s64		length;	
	__u64		flags;
	__s64		file2_ino;
	__s64		file2_mtime;
	__s64		file2_ctime;
	__s32		file2_mtime_nsec;
	__s32		file2_ctime_nsec;
    };

One of the two files is identified by file1_fd, which holds a file descriptor; the other file is passed directly as the ioctl() call's file-descriptor argument. The normal operation of this call will be to exchange length bytes from the first file starting at file1_offset with the same number of bytes in the second file starting at file2_offset. The range of data to move need not be tied to existing extents in the file, but the offsets must be aligned to the filesystem block size, and in most cases length must be a multiple of the block size. Interestingly, the two files can, in fact, be the same file, in which case the two ranges of data (which must not overlap) exchange positions.

The operation is done in an atomic manner, meaning that the file will not be corrupted in case of a crash.

The flags argument can modify the behavior of this operation in a number of ways. The flags defined in the patch set are:

• FILE_SWAP_RANGE_NONATOMIC: the application doesn't care about atomic behavior, so the operation can potentially be done in a less expensive way.
• FILE_SWAP_RANGE_FILE2_FRESH: before performing the swap, the kernel will verify that the second file's inode number matches file2_ino, and that its modification times match file2_mtime, file2_mtime_nsec, file2_ctime, and file_ctime_nsec. In the absence of an exact match, the call will fail with an EBUSY error. This is a way of ensuring that nobody else has modified the file while the exchange was being prepared.
• FILE_SWAP_RANGE_FULL_FILES: ensure that the exchange operation includes all of the data in both files. In other words, this requires both offsets to be zero and both files to have the same length (which must match the length field).
• FILE_SWAP_RANGE_TO_EOF: data is exchanged from the indicated offsets to the ends of both files. In this case, the length field is ignored, and the size of the two ranges to swap may differ.

The XFS implementation records the operation in the transaction log before actually carrying it out. That provides the necessary robustness in the face of a crash, but it also makes filesystems using this feature incompatible with earlier versions of the XFS code.

Internally, the patch set adds another member to the ever-growing file_operations structure:

    int (*swap_file_range)(struct file *file_in, struct file *file_out,
		           struct file_swap_range *fsr);

Any other filesystem can support the FISWAPRANGE ioctl() by implementing this function.

This patch set is quite young, to the point that reporting on it is probably violating its privacy rights in some jurisdictions. The review process has not yet begun. It is thus fair to expect that things could change significantly before it finds its way into the mainline, at some point in the not-too-close future. It does appear to be a useful feature, though, so it seems likely to be merged at some point.

Comments (34 posted)

PHP showing its maturity in release 7.4

This year PHP turned 25 and, as with all things, the hope is that with age comes wisdom and maturity. Often derided as a great way to write bad (and insecure) code, PHP is hard to ignore completely when it is used in nearly eight out of ten websites. With PHP 7.4.5 released in April, it's worthwhile to take a look at modern PHP, how it has evolved to address the criticisms of the past, and what lies ahead in its future.

The evolution of OOP in PHP

PHP's object model has had some pretty rough patches in the past. When objects were first introduced in PHP 4, the implementation was essentially an array with function references and was horribly problematic. The fundamental problems of that implementation were thankfully addressed with the release of PHP 5, featuring an entirely rethought object implementation. In the versions that have come since, up through version the current 7.4 releases, numerous interesting language features for object-oriented programming (OOP) have emerged.

While still a dynamically typed language, PHP does now support a robust typing mechanism including the typing of function parameters and return values along with the use of scalar types. New in PHP 7.4 is typing for object properties. Combining those features with namespaces, interfaces, traits, and iterables results in a well-rounded and modern object-oriented language. If you still think PHP lacks an appropriate object model, you might be pleasantly surprised taking a look again.

For example, consider this brief example encapsulating many of the now-available PHP OOP constructs:

    <?php
    namespace App\LWN;

    use App\LWN\Database;
    use App\LWN\Contracts\Collection
    use App\LWN\Filter as MyFilter;
    use App\LWN\PrettyArray;

    class Example extends Database implements Collection
    {
            use PrettyArray;

	    protected array $data;

	    public function filter(?MyFilter $filter) : iterable
	    {
		    /* ... filter $this->data based on the $filter object's logic ... */
		    return $filtered;
	    }
    }

This snippet defines a class called Example, which extends from the base class Database, and that implements the Collection interface. The fully qualified class name — including namespace — would be App\LWN\Example. Four pieces are imported: the Database class, Collection interface, Filter type (aliased as MyFilter), and PrettyArray trait. In the body of the class, we use PrettyArray in order for the class to take advantage of the properties and methods defined in the trait.

The class also defines a single array property $data (scoped as protected) and adds a single class method filter() scoped for public access. The filter() method accepts a single optional parameter $filter that must either be an instance of App\LWN\Filter (aliased to MyFilter) or NULL. The method returns an iterable pseudo-type, which indicates that the method must either return a PHP array or any other object that implements the built-in PHP Traversable interface. This allows callers to know that the results can be traversed using other language constructs such as foreach.

Proper dependency management and third-party extensions

In the early days of PHP, two repositories, PEAR and PECL, were created to catalog both reusable PHP code and non-bundled, C-based extensions, respectively. PECL continues to be a valuable collection with over 400 extensions, from authentication to data structures, however it has failed to become a widespread tool allowing PHP developers to use those extensions because they introduce system-level dependencies that are generally unavailable on cheaper hosting providers. PEAR, being pure PHP code, was more successful in adoption yet struggled to become the tool it was intended to be. Unfortunately code age and quality proved to be too big of a hurdle to overcome and, because of this, PEAR was officially disabled by default as of PHP 7.4.

In lieu of PEAR, the PHP community has adopted Composer. Similar to Node's npm or Python's pip, Composer has been adopted by nearly every major PHP-based software package to create a community of well-built, well-maintained, and dependency-conscious PHP modules that can be added simply into an application. For example, installing the Stripe payment API is now similar to what you might find in other languages:

    $ composer require stripe/stripe-php

This command finds the package in the Packagist repository (by default), installing it in the vendor directory (in the current directory) along with any necessary dependencies. Using it requires the existence of a composer.json file in the project to define the project's specific version dependencies for both PHP and needed packages. From this, Composer generates a composer.lock file for the project to track exactly what is installed and should be kept in the project. To use the components managed by Composer, the ./vendor/autoload.php file can be loaded using require_once in your application; it will do the necessary bootstrapping and class resolution on instantiation using PHP's autoloading mechanisms.

Most modern PHP frameworks and PHP-based applications today rely on Composer, yet one notable holdout is the ever-popular WordPress blogging package. Efforts in the WordPress community continue to move toward adoption, but it appears to be a massive undertaking that will not be completed soon.

PHP gets proper FFI

One interesting new feature that has come with the release of PHP 7.4 is a foreign function interface (FFI). This has been an obvious omission when comparing PHP to other languages and has the potential to make a big impact in the PHP arena. To understand the potential impact we need to revisit PECL alongside a bit of PHP release and architecture background.

PHP has always favored a "batteries included" approach. Various extensions that are not really considered part of the language by internals developers (such as various database drivers) have been bundled as part of the official release since PHP 3. Other languages have struggled with this topic from time to time, but for PHP the problem is particularly acute due to external factors. Since it is a language that is typically deployed as part of a web server, the vast majority of PHP deployments are simply provided to end-users as part of hosting packages without the ability to add extensions. For example, most cost-effective WordPress hosting services do not provide any third-party extension functionality.

While the bundling strategy succeeds in ensuring that a wide range of consistent functionality exists across hosting providers, it comes at the cost of application support nightmares for anything beyond that — even for self-managed servers. For example, if a non-standard PECL extension existed that did exactly what was needed, the process of loading it and maintaining it on server farms and across PHP versions can easily become unnecessarily painful to system administrators everywhere. Moreover the bundling approach also creates a bottleneck for PHP releases themselves, as there is much more code (features, bug fixes, etc.) that has to go into every release.

FFI in PHP 7.4 has a lot of potential benefits. Where currently C-based extensions provide the glue to map the functionality of shared libraries into PHP APIs, a baked-in FFI allows those PHP API implementations to be done in PHP itself moving forward.  As PHP code, this new form of extension is manageable by the widely-adopted Composer, reducing a major barrier to the use of shared library APIs currently only available as extensions in PECL (or possibly not available at all). This all leads to what may ultimately be the first step away from the "batteries included" approach taken to date while broadening the capacities of the overall PHP community. Of course, the hosting providers will need to cooperate by installing the underlying development packages for the shared libraries on their servers.

If successful, this would be a wonderful win for the internals community and certainly is enabling to the community at large. The internals community would gain a path forward to solving the "batteries included" problem by replacing C-based extensions with PHP-based FFI-enabled ones, without sacrificing consistency across hosting providers. For the general PHP community, FFI enables the use of shared system libraries with only the need to understand and implement the aspects needed for their specific problem and, importantly, without any specific PHP internals knowledge. Composer packages (and PHP applications) are ultimately a large composite of various API bindings, so simply being able to use what is needed via FFI is a major improvement over needing someone to implement a full binding for general-purpose use in C. An example of how the FFI works can be seen in the TensorFlow bindings for PHP, written by PHP core developer and author of the FFI implementation Dmitry Stogov.

Although FFI is a relatively straightforward feature taken by itself, it will be worth watching how it melds into the hosting provider and bundling situation. As part of the core, it may enable hosting providers a mechanism to expand their abilities securely and enable the community in a lot of positive ways.

Making security less obscure

As PHP has matured, so has its focus on security. PHP gets a bad reputation on security, due in no small part to various ill-conceived language features of the past, such as the notorious register_globals and safe_mode settings. Thankfully it has been ten years since register_globals and safe_mode were removed in PHP 5.4. Most PHP-related security issues don't come from the implementation of the language these days but rather from insecurely written code. To address this, a lot of effort has been put in to make handling complicated security issues as straightforward for PHP developers as possible.

This has taken the form of a couple of key technologies that have appeared in more recent versions of PHP. Starting with PHP 7.2, the popular libsodium cryptographic library has been included as part of the PHP tool set, providing high-quality cryptographic services to developers. For hashing critical data such as passwords, PHP also bundles the Argon2 password-hashing algorithm (the winner of a multi-year password-hashing competition).

Of course, there have been continuous improvements and additions to the built-in filtering and sanitization tools that were first included in PHP 5.2. These provide the facilities to consistently and reliably ensure external input is what developers expect it to be.

Through the widespread adoption of proper dependency management, key security-related technologies, and modern frameworks that implement all of this intelligently, PHP has made welcome and significant security-minded improvements over the years.

Performance increases

PHP has continuously worked to improve the per-request performance of its code and has made serious improvements as time has gone on. PHP 7.4 can handle three times as many requests per second as PHP 5.6 and is roughly 18% faster than even PHP 7.0.

Adding to these overall performance improvements is the new PHP 7.4 preloading feature. According to Stogov, who is the original feature proposer:

Enabling preloading is easily done using the opcache.preload configuration directive and specifying the path to a PHP script. All classes and functions referenced within that script will be permanently loaded into memory and referenced in each server request as needed. In exchange for this additional memory usage on the server, resources used every request are universally available resulting in considerably faster execution times. Unfortunately, it also means that changes to the preloaded files will require a server restart to take effect.

Last but not least is just-in-time (JIT) compilation to machine code for PHP, which is provided as an experimental feature in PHP 7.4, and is slated for release in PHP 8. Described as "extremely simple" in its present form compared to implementations such as V8 and PyPy, PHP's forthcoming JIT implementation will be powered by DynASM (developed for the LuaJIT project). It will likely serve as the bedrock for future execution-speed improvements.

The future of PHP

Based on past history, PHP is likely to continue with releases in the 7.x branch, adding incremental improvements, features and bug fixes while PHP 8 is still on the horizon. It is difficult to predict which new features may be rolled into 7.x, and which will be reserved for 8.0. Historically, PHP 5.x was the beneficiary of many improvements originally slated for the never-released PHP 6 when development stalled on that effort.

It is worth noting that it is unlikely PHP 8 will suffer the same fate as PHP 6, however, as developer Derick Rethans has provided a rough schedule leading to a December 2020 launch for PHP 8 (with early alphas being available in June). Since significant features for that release are already committed, it seems likely that timeline will more or less hold. According to the available RFCs being considered we can expect JIT and improvements to the object model, various consistency tweaks, improvements to syntax, and more.

Comments (7 posted)

Security quotes of the week

— Bruce Schneier on contact-tracing apps

— Peter Gutmann

Comments (25 posted)

Kernel release status

The current development kernel is 5.7-rc4, released on May 3. Linus said: "Anyway, it doesn't feel like there's anything worrisome going on, so come on in and test the waters."

Stable updates: this week's stable-kernel flood started with 5.6.9 and 5.4.37 on May 2. Then, 5.6.10, 5.4.38, 4.19.120, 4.14.178, 4.9.221, and 4.4.221 came on May 4, followed by 5.6.11, 5.4.39, 4.19.121, 4.14.179, 4.9.222, and 4.4.222 on May 6.

Comments (none posted)

Firefox 76.0

Firefox 76.0 has been released. This version features a number of improvements to password management, Picture-in-Picture allows a small video window to follow you around as you work, and support for Audio Worklets has been added, allowing more complex audio processing. The release notes have more details.

Comments (6 posted)

Inkscape 1.0 released

Version 1.0 of the Inkscape drawing editor has been released. "One of the first things users will notice is a reorganized tool box, with a more logical order. There are many new and improved Live Path Effect (LPE) features. The new searchable LPE selection dialog now features a very polished interface, descriptions and even the possibility of marking favorite LPEs. Performance improvements are most noticeable when editing node-heavy objects, using the Objects dialog, and when grouping/ungrouping."

Comments (7 posted)

The 2020 Python Language Summit

The 2020 Python Language Summit was held virtually this year, over two days, via videoconference, with discussions via voice and chat. The summit is a yearly gathering for developers of CPython, other Python implementations, and related projects. As with last year, A. Jesse Jiryu Davis covered the summit; his writeups are being posted to the Python Software Foundation (PSF) blog. So far, all of the first day's session writeups are up, as well as two (of six) from the second day. Topics include "All strings become f-strings", "The path forward for typing", "A formal specification for the (C)Python virtual machine", and more.

Comments (17 posted)

The Wayland Protocol

Drew DeVault has just released a (mostly complete) book on the Wayland display-server protocol under the Creative Commons CC-SA license. "This book will help you establish a firm understanding of the concepts, design, and implementation of Wayland, and equip you with the tools to build your own Wayland client and server applications. Over the course of your reading, we'll build a mental model of Wayland and establish the rationale that went into its design. Within these pages you should find many 'aha!' moments as the intuitive design choices of Wayland become clear, which should help to keep the pages turning." For those who would rather peruse (or contribute to) the Markdown source, it's available here.

Comments (20 posted)

• DistroWatch Weekly (May 4)

• Linux Mint Monthly News (April)

• Lunar Linux Weekly News (May 1)

• openSUSE Tumbleweed Review of the Week (May 1)

• SparkyLinux News (April 30)

• Ubuntu Weekly Newsletter (May 2)

• Emacs News (May 4)

• GCC 10.0.1 Status Report (April 30)

• GCC 11.0.0 Status Report (April 30)

• What's cooking in git.git (May 1)

• What's cooking in git.git (May 5)

• Koha Community Newsletter (April)

• LibreOffice monthly recap (April 30)

• LLVM Weekly (May 4)

• OCaml Weekly News (May 5)

• Perl Weekly (May 4)

• PostgreSQL Weekly News (May 3)

• Python Weekly Newsletter (April 30)

• Racket News (May 4)

• Weekly Rakudo News (May 4)

• Ruby Weekly News (April 30)

• This Week in Rust (May 5)

• Tor News (May 4)

• Wikimedia Tech News (May 4)

• Fedora FESCO meeting minutes (May 4)

• Free Software Supporter (May)

CFP Deadlines: May 7, 2020 to July 6, 2020

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

Deadline	Event Dates	Event	Location
May 22	May 28 May 31	MiniDebConf Online
June 5	September 13 September 18	The C++ Conference 2020	Online
June 14	September 4 September 11	Akademy 2020	Virtual, Online
June 15	August 25 August 27	Linux Plumbers Conference	Virtual
June 30	July 4 July 5	State of the Map 2020	Virtual
July 1	September 22 September 24	Linaro Virtual Connect	online
July 2	September 9 September 10	State of the Source Summit	online
July 5	October 28 October 29	[Canceled] DevOpsDays Berlin 2020	Berlin, Germany
July 5	August 23 August 29	DebConf20	online
July 5	September 16 September 18	X.Org Developer's Conference 2020	online
July 5	October 2 October 3	PyGotham TV	Online

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

MiniDebConf Online

MiniDebConf Online will take place May 28-31. "In this MiniDebConf, we aim to put our online resources to the test and find areas for improvement to have even better online events in the future. It will also be great for us to see each other again, even if only on screen, and transform that energy into renewed motivation to work on new or ongoing projects." The call for proposals closes May 22.

Full Story (comments: none)

Events: May 7, 2020 to July 6, 2020

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

Date(s)	Event	Location
May 7 May 9	Linuxwochen Wien	Wien, Austria
May 11 May 13	[ONLINE] Power Management and Scheduling in the Linux Kernel	Pisa, Italy
May 11 May 13	[RESCHEDULED] Linux Audio Conference	Bordeaux, France
May 12	Open Source 101 at Home	The world , The world
May 18 May 20	[POSTPONED] Percona Live Open Source Database Conference 2020	Austin, Tx, USA
May 26 May 28	[VIRTUAL] sambaXP 2020	Berlin, Germany
May 26 May 29	[POSTPONED] Libre Graphics Meeting 2020	Rennes, France
May 27 May 28	[ONLINE] PGCon 2020	Ottawa, Canada
May 28 May 31	MiniDebConf Online
June 6 June 7	[CANCELED] Linuxwochen Linz	Linz, Austria
June 11 June 12	[CANCELED] PGDay.IT 2020	Bergamo, Italy
June 12 June 14	[POSTPONED] GNU Tools Cauldron	Paris, France
June 17 June 18	[ONLINE] Open Source Data Center Conference	Berlin, Germany
June 17 June 18	[ONLINE] stackconf 2020	Berlin, Germany
June 18 June 19	[CANCELED] Swiss PGDay 2020	Zurich, Switzerland
June 19	[CANCELED] Open Source Camp | #5 Bareos	Berlin, Germany
June 20 June 21	International Conference on Networks, Blockchain and Internet of Things	Dubai, UAE
June 23 June 25	[CANCELED] IcingaConf 2020	Amsterdam, Netherlands
June 23 June 25	[ONLINE] Postgres Vision 2020	Boston, MA, USA
June 24 June 26	Perl Conference in the Cloud
June 25	Linux Plumbers virtual town hall	online
June 25 June 26	[CANCELED] Postgres Ibiza 2020	Ibiza, Spain
June 29 July 2	[VIRTUAL] Open Source Summit/Embedded Linux Conference North America	Austin, TX, USA
July 1 July 2	[ONLINE] Linux Security Summit North America	Austin, TX, USA
July 4 July 5	State of the Map 2020	Virtual

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

Alert summary April 30, 2020 to May 6, 2020

Dist.	ID	Release	Package	Date
Arch Linux	ASA-202004-22		chromium	2020-04-30
Arch Linux	ASA-202004-21		git	2020-04-30
Arch Linux	ASA-202004-24		libmicrodns	2020-05-05
Arch Linux	ASA-202005-1		salt	2020-05-05
Arch Linux	ASA-202004-23		webkit2gtk	2020-04-30
CentOS	CESA-2020:1511	C7	git	2020-04-30
CentOS	CESA-2020:1507	C7	java-1.7.0-openjdk	2020-04-30
CentOS	CESA-2020:1512	C7	java-1.8.0-openjdk	2020-04-30
CentOS	CESA-2020:1509	C7	java-11-openjdk	2020-04-30
CentOS	CESA-2020:1962	C6	python-twisted-web	2020-04-30
CentOS	CESA-2020:1561	C7	python-twisted-web	2020-04-30
CentOS	CESA-2020:1489	C7	thunderbird	2020-04-30
Debian	DLA-2202-1	LTS	ansible	2020-05-05
Debian	DLA-2191-1	LTS	dom4j	2020-05-01
Debian	DSA-4675-1	stable	graphicsmagick	2020-05-05
Debian	DLA-2200-1	LTS	mailman	2020-05-03
Debian	DLA-2197-1	LTS	miniupnpc	2020-04-30
Debian	DSA-4669-1	stable	nodejs	2020-04-29
Debian	DLA-2201-1	LTS	ntp	2020-05-05
Debian	DLA-2199-1	LTS	openldap	2020-05-02
Debian	DLA-2198-1	LTS	otrs2	2020-05-01
Debian	DLA-2196-1	LTS	pound	2020-04-30
Debian	DLA-2196-2	LTS	pound	2020-05-03
Debian	DSA-4674-1	stable	roundcube	2020-05-05
Debian	DLA-2192-1	LTS	ruby2.1	2020-05-01
Debian	DSA-4676-1	stable	salt	2020-05-06
Debian	DLA-2203-1	LTS	sqlite3	2020-05-05
Debian	DSA-4670-1	stable	tiff	2020-04-29
Debian	DSA-4673-1	stable	tomcat8	2020-05-03
Debian	DSA-4672-1	stable	trafficserver	2020-05-01
Debian	DSA-4671-1	stable	vlc	2020-04-30
Debian	DLA-2195-1	LTS	w3m	2020-04-30
Debian	DSA-4677-1	stable	wordpress	2020-05-06
Debian	DLA-2194-1	LTS	yodl	2020-04-30
Fedora	FEDORA-2020-0e7f1b663b	F30	chromium	2020-05-03
Fedora	FEDORA-2020-4e093619bb	F30	git	2020-05-01
Fedora	FEDORA-2020-73341c894c	F30	java-11-openjdk	2020-05-02
Fedora	FEDORA-2020-372eeb28f3	F31	java-11-openjdk	2020-05-06
Fedora	FEDORA-2020-92ed6d99e4	F30	java-latest-openjdk	2020-05-01
Fedora	FEDORA-2020-64d46a6e29	F30	kernel	2020-05-02
Fedora	FEDORA-2020-b453269c4e	F31	kernel	2020-05-02
Fedora	FEDORA-2020-16f9239805	F32	kernel	2020-05-02
Fedora	FEDORA-2020-c931060ab7	F32	libldb	2020-05-05
Fedora	FEDORA-2020-0c71c00af4	F30	libxml2	2020-04-30
Fedora	FEDORA-2020-7694e8be73	F32	mingw-libxml2	2020-05-01
Fedora	FEDORA-2020-969414e05b	F30	openvpn	2020-05-03
Fedora	FEDORA-2020-fd8761fd13	F30	php-horde-horde	2020-04-30
Fedora	FEDORA-2020-1a968aeb47	F31	php-horde-horde	2020-04-30
Fedora	FEDORA-2020-6b8868fad9	F32	php-horde-horde	2020-05-01
Fedora	FEDORA-2020-c9eb911737	F30	pxz	2020-05-03
Fedora	FEDORA-2020-07fcbfddbd	F31	pxz	2020-04-30
Fedora	FEDORA-2020-8b89d5b9eb	F32	pxz	2020-05-01
Fedora	FEDORA-2020-d171bf636d	F30	rubygem-json	2020-05-03
Fedora	FEDORA-2020-26df92331a	F31	rubygem-json	2020-05-03
Fedora	FEDORA-2020-c931060ab7	F32	samba	2020-05-05
Fedora	FEDORA-2020-1e85425a52	F30	sqliteodbc	2020-04-30
Fedora	FEDORA-2020-c98c7da2f6	F31	sqliteodbc	2020-04-30
Fedora	FEDORA-2020-df7c647fa3	F32	sqliteodbc	2020-05-01
Fedora	FEDORA-2020-295ed0b1e0	F31	xen	2020-05-01
Gentoo	202004-16		cacti	2020-05-01
Gentoo	202004-17		django	2020-05-01
Gentoo	202004-14		fontforge	2020-05-01
Gentoo	202004-15		libu2f-host	2020-05-01
Mageia	MGASA-2020-0198	7	chromium-browser-stable	2020-05-05
Mageia	MGASA-2020-0190	7	crawl	2020-05-05
Mageia	MGASA-2020-0193	7	dolphin-emu	2020-05-05
Mageia	MGASA-2020-0196	7	exiv2	2020-05-05
Mageia	MGASA-2020-0199	7	fortune-mod	2020-05-05
Mageia	MGASA-2020-0194	7	gnuchess	2020-05-05
Mageia	MGASA-2020-0201	7	kernel	2020-05-05
Mageia	MGASA-2020-0197	7	libsndfile	2020-05-05
Mageia	MGASA-2020-0189	7	openexr	2020-05-05
Mageia	MGASA-2020-0200	7	openldap	2020-05-05
Mageia	MGASA-2020-0195	7	openvpn	2020-05-05
Mageia	MGASA-2020-0192	7	qtbase5	2020-05-05
Mageia	MGASA-2020-0186	7	ruby-json	2020-05-05
Mageia	MGASA-2020-0187	7	squid	2020-05-05
Mageia	MGASA-2020-0191	7	teeworlds	2020-05-05
Mageia	MGASA-2020-0188	7	webkit2	2020-05-05
openSUSE	openSUSE-SU-2020:0597-1	15.1	apache2	2020-05-02
openSUSE	openSUSE-SU-2020:0607-1	15.1	bouncycastle	2020-05-04
openSUSE	openSUSE-SU-2020:0565-1		cacti, cacti-spine	2020-04-30
openSUSE	openSUSE-SU-2020:0566-1		chromium	2020-05-01
openSUSE	openSUSE-SU-2020:0615-1		chromium	2020-05-06
openSUSE	openSUSE-SU-2020:0604-1	15.1	chromium	2020-05-03
openSUSE	openSUSE-SU-2020:0598-1	15.1	git	2020-05-02
openSUSE	openSUSE-SU-2020:0609-1		python-typed-ast	2020-05-04
openSUSE	openSUSE-SU-2020:0567-1	15.1	python-typed-ast	2020-05-01
openSUSE	openSUSE-SU-2020:0585-1	15.1	resource-agents	2020-05-02
openSUSE	openSUSE-SU-2020:0586-1	15.1	ruby2.5	2020-05-02
openSUSE	openSUSE-SU-2020:0564-1	15.1	salt	2020-04-30
openSUSE	openSUSE-SU-2020:0601-1	15.1	samba	2020-05-02
openSUSE	openSUSE-SU-2020:0612-1		sqliteodbc	2020-05-05
openSUSE	openSUSE-SU-2020:0606-1	15.1	squid	2020-05-03
openSUSE	openSUSE-SU-2020:0602-1	15.1	webkit2gtk3	2020-05-02
openSUSE	openSUSE-SU-2020:0599-1	15.1	xen	2020-05-02
Oracle	ELSA-2020-1962	OL6	python-twisted-web	2020-04-29
Red Hat	RHSA-2020:1981-01	EL6	chromium-browser	2020-04-30
Red Hat	RHSA-2020:1970-01	EL6	chromium-browser	2020-04-29
Red Hat	RHSA-2020:2036-01	EL6	firefox	2020-05-06
Red Hat	RHSA-2020:2037-01	EL7	firefox	2020-05-06
Red Hat	RHSA-2020:2031-01	EL8	firefox	2020-05-06
Red Hat	RHSA-2020:2033-01	EL8.0	firefox	2020-05-06
Red Hat	RHSA-2020:2032-01	EL8.1	firefox	2020-05-06
Red Hat	RHSA-2020:1980-01	EL8	git	2020-04-30
Red Hat	RHSA-2020:1978-01	EL8.0	git	2020-04-30
Red Hat	RHSA-2020:1979-01	EL8.1	git	2020-04-30
Red Hat	RHSA-2020:1998-01	EL8	gnutls	2020-04-30
Red Hat	RHSA-2020:1984-01	EL7.7	kernel	2020-04-30
Red Hat	RHSA-2020:1975-01	RHSC	rh-git218-git	2020-04-29
Red Hat	RHSA-2020:2014-01	EL7.6	sqlite	2020-05-05
Red Hat	RHSA-2020:2040-01	EL7	squid	2020-05-06
Red Hat	RHSA-2020:2041-01	EL8	squid:4	2020-05-06
Red Hat	RHSA-2020:2038-01	EL8.0	squid:4	2020-05-06
Red Hat	RHSA-2020:2039-01	EL8.1	squid:4	2020-05-06
Scientific Linux	SLSA-2020:1962-1	SL6	python-twisted-web	2020-04-29
Slackware	SSA:2020-126-01		firefox	2020-05-05
Slackware	SSA:2020-124-01		seamonkey	2020-05-03
Slackware	SSA:2020-126-02		thunderbird	2020-05-05
SUSE	SUSE-SU-2020:1165-1	OS7 OS8 SLE12 SES5	LibVNCServer	2020-05-04
SUSE	SUSE-SU-2020:14355-1	SLE11	LibVNCServer	2020-05-04
SUSE	SUSE-SU-2020:1164-1	SLE15	LibVNCServer	2020-05-04
SUSE	SUSE-SU-2020:1190-1	OS9	ardana-ansible, ardana-barbican, ardana-cluster, ardana-db, ardana-designate, ardana-input-model, ardana-logging, ardana-monasca, ardana-mq, ardana-neutron, ardana-octavia, ardana-osconfig, ardana-tempest, ardana-tls, crowbar-core, crowbar-ha, crowbar-openstack, memcached, openstack-ceilometer, openstack-cinder, openstack-designate, openstack-heat, openstack-ironic, openstack-ironic-image, openstack-manila, openstack-neutron, openstack-nova, openstack-octavia, openstack-octavia-amphora-image, python-cinderclient, python-glanceclient, python-ironic-lib, python-ironicclient, python-keystonemiddleware, python-manila-tempest-plugin, python-novaclient, python-octaviaclient, python-openstackclient, python-os-brick, python-oslo.config, python-oslo.rootwrap, python-oslo.utils, python-swiftclient, python-watcherclient, release-notes-suse-openstack-cloud, rubygem-crowbar-client, rubygem-puma, zookeeper	2020-05-05
SUSE	SUSE-SU-2020:1158-1	OS8 SLE12 SES5	ceph	2020-04-30
SUSE	SUSE-SU-2020:1180-1	OS7 OS8 SLE12 SES5	icu	2020-05-05
SUSE	SUSE-SU-2020:14354-1	SLE11	kernel	2020-04-30
SUSE	SUSE-SU-2020:1142-1	SLE12	kernel	2020-04-29
SUSE	SUSE-SU-2020:1142-1	SLE12	kernel	2020-04-29
SUSE	SUSE-SU-2020:1141-1	SLE12	kernel	2020-04-29
SUSE	SUSE-SU-2020:1141-1	SLE12	kernel	2020-04-29
SUSE	SUSE-SU-2020:1146-1	SLE15	kernel	2020-04-29
SUSE	SUSE-SU-2020:1146-1	SLE15	kernel	2020-04-29
SUSE	SUSE-SU-2020:14356-1	SLE11	mailman	2020-05-05
SUSE	SUSE-SU-2020:1144-1	SLE12	munge	2020-04-29
SUSE	SUSE-SU-2020:1171-1	SLE15	nginx	2020-05-04
SUSE	SUSE-SU-2020:1193-1	OS7 OS8 SLE12 SES5	openldap2	2020-05-05
SUSE	SUSE-SU-2020:14353-1	SLE11	openldap2	2020-04-30
SUSE	SUSE-SU-2020:1163-1	SLE15	permissions	2020-05-04
SUSE	SUSE-SU-2020:1194-1	SES5	python-Pillow	2020-05-06
SUSE	SUSE-SU-2020:1179-1	SLE15	rmt-server	2020-05-05
SUSE	SUSE-SU-2020:1177-1	SLE15	rpmlint	2020-05-05
SUSE	SUSE-SU-2020:1178-1	SLE15	rubygem-actionview-5_1	2020-05-05
SUSE	SUSE-SU-2020:14350-1		salt	2020-04-30
SUSE	SUSE-SU-2020:14351-1		salt	2020-04-30
SUSE	SUSE-SU-2020:1147-1	MP3.2 SLE12	salt	2020-04-30
SUSE	SUSE-SU-2020:1151-1	SLE15	salt	2020-04-30
SUSE	SUSE-SU-2020:1150-1	SLE15	salt	2020-04-30
SUSE	SUSE-SU-2020:1156-1	SLE15	squid	2020-04-30
SUSE	SUSE-SU-2020:1139-1	SLE12	xen	2020-04-29
SUSE	SUSE-SU-2020:1138-1	SLE12	xen	2020-04-29
Ubuntu	USN-4349-1	16.04 18.04 19.10	edk2	2020-04-30
Ubuntu	USN-4348-1	16.04 18.04	mailman	2020-04-29
Ubuntu	USN-4350-1	16.04 18.04 19.10 20.04	mysql-5.7, mysql-8.0	2020-05-04
Ubuntu	USN-4330-2	20.04	php7.4	2020-05-06
Ubuntu	USN-4333-2	20.04	python3.8	2020-04-30
Ubuntu	USN-4341-2	14.04	samba	2020-04-29
Ubuntu	USN-4341-3	16.04	samba	2020-04-29
Ubuntu	USN-4347-1	18.04 19.10 20.04	webkit2gtk	2020-04-29

Full Story (comments: none)