Welcome to the LWN.net Weekly Edition for August 17, 2017

This edition contains the following feature content:

• Debian debates software for proprietary services: should the distribution ship a library whose job is mainly to interface with a proprietary network service?
• A canary for timer-expiration functions: hardening the kernel against timer-overwrite attacks.
• Scaling the kernel's MAINTAINERS file: as the kernel community grows, even the MAINTAINERS file needs maintenance — and perhaps a process change as well.
• Another attempt at speculative page-fault handling: a memory-management scalability technique that has been eight years in the making.
• Reducing Python's startup time: it takes too long to start a Python program; developers are looking at one way of making things better.

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)

Debian debates software for proprietary services

Distributions like Debian have a clear policy on the software they ship; as a general rule, only free software can be considered for inclusion. How that policy should be applied to software that interacts with proprietary systems is not entirely clear, though. A recent discussion on a package that interfaces with a proprietary network service seems unlikely to lead to any changes in policy, but it does highlight a fault line within the Debian community.

Back in February, Jonas Smedegaard filed a bug against the "certspotter" package, complaining that the package's description advertises the proprietary SSLMate service. On August 4, the maintainer of that package, Faidon Liambotis, got around to answering the bug, saying that the description is helpful for users searching for the package and will not be removed. At that point, Smedegaard took the discussion to the debian-project mailing list in an attempt to rally the Debian developer community against the offending package description.

The ensuing discussion, though, quickly got away from the question of the description and into the area of whether Debian should host software that interfaces with proprietary services in its "main" repository, or whether such software should be relegated to "contrib" instead. The answer to this question carries some consequences. If a package moves to contrib, any package that depends on it (or even recommends it) must also move to contrib. The contrib repository is not enabled by default in a new Debian installation, and packages in contrib do not normally get security updates. So a move to contrib signals a clear second-class-citizen status that would almost certainly result in a significant reduction in the number of users who even know that the package exists, much less use it.

We are talking about Debian here, so one can expect to find a written policy addressing the issue. In this case, though, the policy manual is mostly silent, with one exception. Section 2.2, which describes the repository areas, says: "None of the packages in the main archive area require software outside of that area to function". Some Debian developers interpret this sentence as saying that the packages in main cannot link to proprietary software; others say that use of a proprietary web service is enough to disqualify a package from main.

If the latter view holds, there are quite a few ongoing policy violations in need of attention. The classic example, raised by a number of participants in the discussion, is the venerable ICQ messaging service. This service is proprietary, but a number of ICQ clients exist in the Debian main repository. In this case, the fact that the client itself is free software has generally been deemed good enough for inclusion in main.

If that is no longer the case, then a number of other packages need review as well. Vincent Bernat raised s3cmd, a tool for managing Amazon S3 services. But perhaps s3cmd is different because there are now a couple of free tools that emulate the S3 API. Another one, also pointed out by Bernat, is rclone, which specializes in synchronizing files between local systems and cloud-storage services, which are generally commercial. This tool is not just useful for ongoing use of those services; it can also be used as a means for escape from a cloud service — which is generally considered beneficial.

On August 9, Smedegaard carried the discussion to the debian-devel list, in the apparent hope of finding more support there. The result was perhaps less than he had hoped for. There were some developers, such as Bas Wijnen, who argued for expelling all such software from main:

Others disagreed, making the point that, if one looks closely enough, there is little software indeed that doesn't require proprietary software — in the CPU's microcode if not elsewhere — to function. Russ Allbery argued strongly against pushing out such software, saying: "I believe this would be hugely counter-productive for free software. It would hurt us way more than it would hurt proprietary services". He added that "writing a library specifically to interact with a non-free service is *good software engineering*" and that such libraries should be allowed in Debian. After that, the discussion slowed considerably.

Once again, this is Debian, so the possibility of this disagreement snowballing into a huge general-resolution fight is real. But a reading of the discussion does not appear to reveal an appetite for that kind of battle. A more likely outcome is that the issue will slowly fade from view with no significant changes to existing practice. But, this being Debian, one can probably predict with reasonable certainty that the topic will return to the lists in the not-too-distant future.

Comments (29 posted)

A canary for timer-expiration functions

A bug that allows an attacker to overwrite a function pointer in the kernel opens up a relatively easy way to compromise the kernel—doubly so, if an attacker simply needs to wait for the kernel use the compromised pointer. There are various techniques that can be used to protect kernel function pointers that are set at either compile or initialization time, but there are some pointers that are routinely set as the kernel runs; timer completion functions are a good example. An RFC patch posted to the kernel-hardening mailing list would add a way to detect that those function pointers have been changed in an unexpected way and to stop the kernel from executing that code.

The patch from Kees Cook is targeting a class of vulnerabilities that arrange to overwrite the function field in struct timer_list. That field is the function that will be called when the timer expires and it conveniently (from an attacker's perspective) passes the next field in that structure (data) to the function. So an attacker who finds a way to overwrite function can likely overwrite data as well, leading to a fairly straightforward way to call some code of interest and to pass it an argument. As Cook put it: "This provides attackers with a ROP-like primitive for performing limited kernel function calls without needing all the prerequisites to stage a ROP attack."

Exploits

In the patch, he pointed to two recent exploits that used this technique. The first was described by its discoverer, Philip Pettersson, in December 2016. It uses an AF_PACKET socket (for raw socket handling as used by tools like tcpdump) and manipulates the version of the packet-socket API requested using setsockopt(). By changing from TPACKET_V3 to TPACKET_V1 at just the right time (to take advantage of a race condition), his demonstration exploit will cause the memory containing a timer_list to be freed without deleting the timer.

So the timer object will be used by the kernel after it has been freed. By arranging for that memory to be reallocated somewhere that the attacker can write to (Pettersson mentions using the add_key() system call to do so), function and data can be overwritten. In the example, it actually does that twice, first to change the vsyscall table from read-only to read-write, then to register a world-writable sysctl (/proc/sys/hack) that sets the path of the modprobe executable. It arranges that the exploit program gets run as modprobe (as root), which leads to the execution of a root shell.

The second recent exploit was the subject of a lengthy Project Zero blog post in May by Andrey Konovalov, who discovered the flaw using the syzkaller fuzzer. It uses a heap buffer overflow in the AF_PACKET code. By arranging the heap appropriately and sending a packet with the contents of interest (the exploit code, effectively), it will place the code into memory. But that memory is user-space memory, and the Intel supervisor mode access protection (SMAP) and supervisor mode execution protection (SMEP) features will prevent the kernel from directly accessing or executing code there. So Konovalov used the same technique as Pettersson to simply disable those protections by calling native_write_cr4() to change the CR4 register bits as the expiration function of a socket timer.

Once that is done, it sets up a new compromised socket and ring buffer combination that turns a transmit function pointer into a pointer to a commit_creds(prepare_kernel_cred(0)) call in user space. Then simply transmitting a packet using the socket invokes the code, which gives the current process root privileges.

It is interesting to note that both of these vulnerabilities can be exploited by non-privileged users on distributions (e.g. Fedora, Ubuntu) where user namespaces are enabled and unrestricted. Both require the CAP_NET_RAW capability to create packet sockets, which can be acquired by unprivileged users by creating a new user namespace. While the problem is not directly attributable to the user namespace code itself, it does further highlight the dangers of expanding user privileges that namespaces provide. Both Pettersson and Konovalov warn against allowing unprivileged users to create user namespaces.

Both also avoid kernel address-space layout randomization (KASLR), SMAP, and SMEP protections. Pettersson's exploit uses hardcoded offsets for the calls of interest to avoid KASLR, while Konovalov reads dmesg to pluck out the kernel's text address. SMAP/SMEP are either bypassed by using kernel memory directly (Pettersson) or by explicitly disabling the features (Konovalov).

A possible fix

Cook's patch would add a canary field to struct timer_list just prior to the function field. When a timer is initialized, the canary would be set to a value calculated by XORing the addresses of the timer and the function, along with a random number that only the kernel would know. The idea is that the canary value would also be overwritten if the function pointer is. So, before calling the function when the timer expires, the canary would be recalculated and compared with the stored value; if they differ, the function pointer has been changed and will not be called. A warning will be logged as well.

Unfortunately, Cook soon realized that his patch was incomplete. He had addressed timers that were set up using the setup_timer_*() macros and the add_timer() function, but missed many static timer initializations that use DEFINE_TIMER(). He promised a revised version of the patch to handle that case.

But it turns out that will require some extensive refactoring of the timer code, he said in response to an email query. That is a bigger job than he expected, but does provide a nice cleanup, he said. He may also have to weaken the canary for the static timers, he said in the patch followup. As with many cross-subsystem patch sets that change code across the tree, getting something like that into the mainline may be difficult. Cook outlined some of the problems he and others have encountered trying to do so in a ksummit-discuss thread back in June.

As the two exploits showed, though, the problem is real. Some kind of solution that would simply eliminate that class of vulnerabilities would be welcome. Whether Cook's canary can be that solution remains to be seen, however.

Comments (12 posted)

Scaling the kernel's MAINTAINERS file

The kernel's development community is large, to the point that it is often far from obvious who a given patch should be sent to. As the community has grown, it has developed mechanisms for tracking that information centered on a text file called MAINTAINERS. But now it would appear that this scalability mechanism has scalability problems of its own.

The MAINTAINERS file sits at the top of the kernel's source tree; it is a plain-text file with a number of fields describing how various kernel subsystems are managed. For example, the following entry was consulted for a recent article on device-tree issues:

    OPEN FIRMWARE AND FLATTENED DEVICE TREE
    M:	Rob Herring <robh+dt@———>
    M:	Frank Rowand <frowand.list@———>
    L:	devicetree@vger.kernel.org
    W:	http://www.devicetree.org/
    T:	git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
    S:	Maintained
    F:	drivers/of/
    F:	include/linux/of*.h
    F:	scripts/dtc/
    F:	Documentation/ABI/testing/sysfs-firmware-ofw

This entry says that the flattened device-tree subsystem has two maintainers (the "M:" fields), Rob Herring and Frank Rowand. The relevant mailing list (L:) and web site (W:) are given, as is the subsystem's Git tree (T:). The F: lines describe the files and directories that are considered to be a part of this subsystem. The file can be read in a text editor, but it is often consulted by way of the get_maintainer.pl script, which reads a patch and outputs a list of addresses to which the patch should be sent.

This file is over 14,000 lines long in current kernels and contains entries for over 1,700 subsystems in the kernel. Those subsystems are ostensibly listed in alphabetical order but, as Randy Dunlap noted in a patch posted in July, many of the entries are not in the right place. His patch sought to improve the situation, but that is where the real trouble started.

In a community as large as the kernel, changes to subsystems happen on a frequent basis. If the relevant maintainers are paying attention, those changes result in patches to the MAINTAINERS file — on the order of 100 patches in each development cycle. Needless to say, a certain number of those patches will conflict with each other, and Linus Torvalds gets to clean up the mess. When Dunlap's patch inevitably resulted in a merge conflict, Torvalds proclaimed his frustration with the MAINTAINERS file. Perhaps, he asked, there would be some way to split it up?

His original suggestion was to spread the maintainer information through the kernel source tree, like the kernel configuration file was split up starting in 1.3.36. He later suggested that the maintainer information could, in fact, live in the Kconfig files with the configuration options, though that idea did not get far. Regardless of the exact scheme used, he explained, splitting up the maintainer information would make resolving conflicts into a less frustrating task.

The advantages of a less frustrated Linus Torvalds are evident to most kernel developers, so interest in improving the MAINTAINERS file is relatively high. Joe Perches suggested splitting the file into a top-level MAINTAINERS directory; that would keep the information easy to find and easy for scripts to work with. And that would indeed appear to be way things are headed.

That leaves the question of how the file should be split. Yet another suggestion from Torvalds was to split the file by mailing list, so that all entries pointing to the same list would end up in the same file. But Perches came back with a script that splits the file by directory hierarchy instead. The result is 54 files in the MAINTAINERS directory with names like arch_arm64, drivers_gpu_drm, or filesystems. Any subsystem without enough entries to justify its own file ends up in MAINTAINERS/MAINTAINERS.

Torvalds tried it out but chose not to go with the result. He had a few quibbles with how the split is done, but concluded that "*some* of it looks really nice". But perhaps the concern that really stopped things was a familiar one: making this change will create merge conflicts with any subsystem tree containing changes to the MAINTAINERS file. The most likely solution to that problem is to make the change immediately after the 4.14-rc1 release. Torvalds has not committed to doing so, but it does seem likely that the MAINTAINERS split is coming in the relatively near future.

Comments (6 posted)

Another attempt at speculative page-fault handling

While the best way to avoid performance problems associated with page faults is usually to avoid faulting altogether, that is not always an option. Thus, it is important that the kernel handle page faults with a minimum of overhead. One particular pain point in current kernels comes about in multi-threaded workloads that are all incurring faults in the same address space. Speculative page-fault handling is an old idea for improving the scalability of such workloads that may finally be approaching a point where it can be considered for inclusion.

Memory-management performance with multi-threaded workloads is often bounded by the ability to acquire the mmap_sem reader/writer semaphore, which serializes access to the data structures describing a process's address space. The handling of page faults, in particular, requires mmap_sem, so a process with a large number of threads generating faults will see contention. Speculative page faults are an attempt to alleviate this contention by doing lockless reads of a process's virtual memory areas (VMA) without holding mmap_sem.

The speculative page-fault patches first appeared in 2009 and have been discussed and improved upon intermittently by various kernel developers through the years, but this work has not found its way into the kernel. Laurent Dufour has recently revived this effort by resubmitting the patches with fixes and improvements of his own, and an active discussion took place on the linux-kernel mailing list on its inclusion. Notably, Dufour reports a 20% speed improvement loading a 2TB database with the speculative page fault code.

As noted above, the mmap_sem semaphore can be a point of significant contention for multi-threaded workloads. In particular, page-fault handling requires access to a process's VMA structures that describe its memory layout, and that access requires mmap_sem. Even when only read locking is required (as is the case for page faults), frequent access to mmap_sem leads to cache-line bouncing and poor performance. The idea behind speculative page faults is to increase memory-management performance by avoiding the use of the mmap_sem in page-fault handling. Doing so requires a way to perform a lockless walk of the VMAs; that, in turn, means facing a number of problems that mmap_sem is explicitly there to prevent.

The first of these problems, naturally, is that the VMA describing the area where a fault occurs may, if mmap_sem is not held, change during the handling of the fault. The strategy taken to address this problem is to do as much work as possible that doesn't depend on the state of the VMA, then checking to see if anything has changed before changing the process's address space directly. So, for example, a free page can be allocated and its data read in from disk independently of the address space, but actually putting that page into the address space requires a consistent view of the VMA.

The kernel has a longstanding mechanism for this kind of access: the seqlock. So the patch set adds a seqlock to the VMA structure, along with the code to increment its sequence count everywhere that the VMA is changed. The speculative fault-handling code can then record the sequence number before doing any work and verify that the number has not changed at the end. If the sequence number does change, the VMA has been changed and the speculative work was done in vain; in this case the attempt fails and the fault is retried in the old-fashioned way.

The second problem is a bit trickier; without mmap_sem, a VMA may disappear entirely while a fault is being handled. This situation is avoided by using read-copy-update (RCU) to keep VMA structures around while a fault is being handled. SRCU (the sleepable variant of RCU) is used to serialize VMA updates and accommodate lockless reads of the VMA. SRCU is required because a number of fault-handling operations can sleep.

When handling a page fault speculatively, the kernel will do a lockless page-table walk and grab the finer-grained page-table lock. Then it does a srcu_read_lock() to do a VMA lookup, and checks the write-sequence count of the VMA. It will need to use the VMA to find the page that the address faulted on, but to do this it needs to drop the page table lock to honor locking order rules. Once the page is found, the VMA is validated again by repeating the page table walk, obtaining the page-table lock, and validating that the VMA sequence number did not change. If it didn't, the page is installed in the page table, and the page-table lock is released.

Another pitfall with speculative page-fault handling has to do with translation lookaside buffer (TLB) invalidation. Various actions, such as unmapping a memory area, can call for a TLB invalidation; that is handled by sending inter-processor interrupts (IPIs) to tell each CPU to invalidate its own TLB. The unmap path can lock specific page-table entries and perform the invalidation while that lock is held. The speculative fault-handling path, meanwhile, will attempt to take the page-table lock it needs with interrupts disabled. Should that attempt happen on a page-table entry that is held by the unmap path, the processor will spin in a loop with interrupts disabled, meaning it will never receive the TLB-invalidation IPI. The result is a deadlock, a situation that is even worse for performance than mmap_sem contention. Once this problem is understood the solution is straightforward: use a "trylock" operation to acquire the lock in the speculative path, and fall back to traditional fault handling if it fails.

The first speculative page fault patches were posted in 2009 by Hiroyuki Kamezawa. The ensuing discussion led Peter Zijlstra to create his own implementation based on the idea of using RCU to enable lockless reading of the VMA structures. Zijlstra's implementation had some issues of its own; no code was merged, and the discussion stalled and fizzled out. The idea was revived again by Zijlstra in 2014, because many of the issues blocking the progress of previous attempts had been solved. However, the discussion fizzled out again, and there was no push for merging the code. In June, Dufour forward-ported Zijlstra's patches and added some of his own. One of the problems Dufour addresses with his patches is the TLB invalidation issue.

Despite the two previous abandoned speculative page fault implementations, the idea is useful enough for another attempt to be made at trying to get this code merged into the kernel. Dufour's database-loading speed improvements led Michal Hocko to ask if there were any other tests or benchmarks that were run, such as kernbench or other highly threaded workloads. In response, the August 8 posting (linked above) includes a number of results from different benchmarks, showing modest to significant improvements depending on the test.

At this point, it would appear that the significant issues with this patch set have been addressed. Given that speculative page-fault handling shows significant improvements for some workloads, one might not be faulted for speculating that there is a reasonable chance that this work will be merged in the relatively near future — a mere eight years after the initial idea was floated.

[Thanks to Peter Zijlstra for answering my questions about this work.]

Comments (1 posted)

Reducing Python's startup time

The startup time for the Python interpreter has been discussed by the core developers and others numerous times over the years; optimization efforts are made periodically as well. Startup time can dominate the execution time of command-line programs written in Python, especially if they import a lot of other modules. Python startup time is worse than some other scripting languages and more recent versions of the language are taking more than twice as long to start up when compared to earlier versions (e.g. 3.7 versus 2.7). The most recent iteration of the startup time discussion has played out in the python-dev and python-ideas mailing lists since mid-July. This time, the focus has been on the collections.namedtuple() data structure that is used in multiple places throughout the standard library and in other Python modules, but the discussion has been more wide-ranging than simply that.

A "named tuple" is a way to assign field names to elements in a Python tuple object. The canonical example is to create a Point class using the namedtuple() factory:

    Point = namedtuple('Point', ['x', 'y'])
    p = Point(1,2)

The elements of the named tuple can then be accessed using the field names (e.g. p.x) in addition to the usual p[0] mechanism. A bug filed in November 2016 identified namedtuple() as a culprit in increasing the startup time for importing the functools standard library module. The suggested solution was to replace the namedtuple() call with its equivalent Python code that was copied from the _source attribute of a class created with namedtuple(). The _source attribute contains the pure Python implementation of the named tuple class, which eliminates the need to create and execute some of that code at import time (which is what namedtuple() does).

There are a few problems with that approach, including the fact that any updates or fixes to what namedtuple() produces would not be reflected in functools. Beyond that, though, named tuple developer Raymond Hettinger was not convinced there was a real problem:

Nick Coghlan agreed with Hettinger's assessment:

Hettinger closed the bug, though it was reopened in December to consider a different approach using Argument Clinic and subsequently closed again for more or less the same reasons. That's where it stood until mid-July when Jelle Zijlstra added a comment that pointed to a patch to speed up named tuple creation by avoiding some of the exec() calls. It was mostly compatible with the existing implementation, though it did not support the _source attribute. That led to a classic "bug war", of sorts, where people kept reopening the bug, only to see it be immediately closed again. It is clear that some felt that the arguments for closing the bug were not particularly compelling.

After several suggestions that the proper way to override the bug-closing decisions made by Hettinger and Coghlan was to take the issue to python-dev, Antoine Pitrou did just that. According to Pitrou, the two main complaints about the proposed fix were that it eliminated the _source attribute and that "optimizing startup cost is supposedly not worth the effort". Pitrou argued that _source is effectively unused by any Python code that he could find and that startup optimizations are quite useful:

In addition, the _source attribute is something of an odd duck in that it would seem to be part of the private interface because it is prefixed with an underscore, but also that it is meant to be used as a learning tool, which is not typical for Python objects. The underscore was used so that source could be used as a tuple field name but, as Hettinger noted, it probably should have been named differently (e.g. source_). But he is adamant that there are benefits to having that attribute, mostly from a learning and understanding standpoint.

Ever the pragmatist, Guido van Rossum offered something of a compromise. He agreed with Pitrou about the need to optimize named tuple class creation, but hoped that it would still be possible to support Hettinger's use case:

As might be guessed, a pronouncement like that from Van Rossum, Python's benevolent dictator for life (BDFL), led Hettinger to reconsider: "Okay, then Nick and I are overruled. I'll move Jelle's patch forward. We'll also need to lazily generate _source but I don't think that will be hard." He did add "one minor grumble", however, regarding the complexity of the CPython code:

That tradeoff between complexity and performance is one that has played out in many different development communities over the years—the kernel community faces it regularly. Part of the problem is that the negative effects of a performance optimization may not be seen for a long time. As Coghlan put it:

Van Rossum's pronouncement set off a predictable bikeshedding frenzy around named tuple enhancements that eventually moved to python-ideas and may be worthy of a further look at some point. But there was also some pushback regarding Hettinger's repeated contention that shaving a few milliseconds here and there from the Python startup time was not an important goal. As Barry Warsaw said:

Gregory P. Smith pointed to the commonly mentioned command-line utilities as one place where startup time matters, but also described another problematic area:

The discussion (and a somewhat dismissive tweet from Hettinger [Note: Hettinger strongly disclaims the "dismissive" characterization.]) led Victor Stinner to start a new thread on python-dev to directly discuss the interpreter startup time, separate from the named tuple issue. He collected some data that showed that the startup time for the in-development Python 3.7 is 2.3 times longer than Python 2.7. He also compared the startup of the Python-based Mercurial source code management system to that of Git (Mercurial is 45 times slower) as well as comparing the startup times of several other scripting languages (Python falls into the middle of the pack there). In the thread, Pitrou pointed out the importance of "anecdotal data", which Hettinger's tweet had dismissed:

Python has come a long way from its roots as a teaching language. There is clearly going to be some tension between the needs of languages geared toward teaching and those of languages used for production-quality applications of various kinds. That means there is a balance to be struck, which is something the core developers (and, in particular, Van Rossum) have been good at over the years. One suspects that startup time—and the named tuple implementation—can be optimized without sacrificing that.

Comments (13 posted)

Source-code management system security updates

It turns out that even rather different source-code management systems can have similar vulnerabilities. This can be seen in the Git v2.14.1, Mercurial 4.3, and Subversion 1.9.7 releases (plus updates of older releases). In each case, it's possible to provide a malicious repository URL that ends up executing code; these URLs can be buried out of sight in existing repositories. Updating would be a good idea, regardless of which system you use.

Comments (16 posted)

Security quotes of the week

— Peter Ney, Karl Koscher, Lee Organick, Luis Ceze, Tadayoshi Kohno

— Cory Doctorow

Comments (7 posted)

Kernel release status

The current development kernel is 4.13-rc5, released on August 13.

The August 14 regression report lists 11 known problems in the 4.13-rc5 kernel.

Stable updates: It was a busy week for stable releases. 4.12.6, 4.9.42, 4.4.81, and 3.18.64 were released on August 11, followed quickly by 4.12.7, 4.9.43, 4.4.82, and 3.18.65 on August 13. On August 16, the 4.12.8, 4.9.44, 4.4.83, and 3.18.66 stable kernels were released.

Comments (none posted)

Quote of the week

— Rusty Russell

Comments (1 posted)

Bassi: Dev v Ops

Emmanuele Bassi writes about the mismatch between the traditional distribution packaging model and what the world seems to actually want. "The more I think about it, the less I understand how that ever worked in the first place. It is not a mystery, though, why it’s a dying model. When I say that 'nobody develops applications like the Linux distributions encourages and prefers' I’m not kidding around: Windows, macOS, iOS, Electron, and Android application developers are heavily based on the concept of a core set of OS services; a parallel installable blocks of system dependencies shipped and retired by the OS vendor; and a bundling system that allows application developers to provide their own dependencies, and control them."

Comments (150 posted)

Solus 3 released

The Solus distribution project has announced the availability of Solus 3. "This is the third iteration of Solus since our move to become a rolling release operating system. Unlike the previous iterations, however, this is a release and not a snapshot. We’ve now moved away from the 'regular snapshot' model to accommodate the best hybrid approach possible - feature rich releases with explicit goals and technology enabling, along with the benefits of a curated rolling release operating system." Headline features include support for the Snap packaging format, a lot of desktop changes, and numerous software updates. (LWN looked at Solus in 2016).

Comments (none posted)

GNOME turns 20

The GNOME project was founded by Miguel de Icaza and Federico Mena Quintero on August 15, 1997, so today the project celebrates its 20th birthday. "There have been 33 stable releases since the initial release of GNOME 1.0 in 1999. The latest stable release, GNOME 3.24 “Portland,” was well-received. “Portland” included exciting new features like the GNOME Recipes application and Night Light, which helps users avoid eyestrain. The upcoming version of GNOME 3.26 “Manchester,” is scheduled for release in September of this year. With over 6,000 contributors, and 8 million lines of code, the GNOME Project continues to thrive in its twentieth year."

Comments (40 posted)

Thank you from Krita

Earlier this month we reported that the Krita Foundation was having some financial difficulties. The Krita Foundation has an update with thanks to all who donated. "So, even though we’re going to get another accountant’s bill of about 4500 euros, we’ve still got quite a surplus! As of this moment, we have €29,657.44 in our savings account! That means that we don’t need to do a fund raiser in September. Like we said, we’ve still got some features to finish."

Comments (19 posted)

Wirzenius: Retiring Obnam

Lars Wirzenius announces that he is ending development of the Obnam backup system. "After some careful thought, I fear that the maintainability problems of Obnam can realistically only be solved by a complete rewrite from scratch, and I'm not up to doing that. If you use Obnam, you should migrate to some other backup solution. Don't worry, you have until the end of the year. I will be around and I intend to fix any serious bugs in Obnam; in particular, security flaws. But you should start looking for a replacement sooner rather than later." LWN looked at Obnam in 2012.

Comments (25 posted)

Development quote of the week

— Daniel Silverstone

Comments (none posted)

• Debian Project News (August 14)

• DistroWatch Weekly (August 14)

• KaOS Monthly Status (August)

• Lunar Linux Weekly News (August 11)

• Ubuntu Kernel Team Weekly Summary (August 9)

• Ubuntu Kernel Team Weekly Summary (August 15)

• Ubuntu Server Development Summary (August 15)

• Ubuntu Weekly Newsletter (August 14)

• Emacs News (August 7)

• Emacs News (August 14)

• These Weeks in Firefox (August 16)

• GCC 7.3 Status Report (August 14)

• What's cooking in git.git (August 11)

• What's cooking in git.git (August 14)

• Git Rev News (August 16)

• LLVM Weekly (August 14)

• LXC/LXD/LXCFS Weekly Status (August 11)

• LXC/LXD/LXCFS Weekly Status (August 14)

• OCaml Weekly News (August 15)

• OpenStack Technical Committee Report (August 15)

• Perl Weekly (August 14)

• PostgreSQL Weekly News (August 14)

• Python Weekly Newsletter (August 10)

• Ruby Weekly News (August 10)

• This Week in Rust (August 15)

• Wikimedia Tech News (August 14)

• Fedora council election - Result announcement (August 15)

• Fedora FESCO meeting minutes (August 11)

• GNOME Foundation Board Minutes (June 20)

• GNOME Foundation Board Minutes (June 27)

• GNOME Foundation Board Minutes (July 4)

• GNOME Foundation Board Minutes (July 11)

• GNOME Foundation Board Minutes (July 18)

• Ubuntu Server Team meeting minutes (August 15)

OpenWrt Summit CFP

OpenWrt Summit will take place October 26-27 in Prague, Czech Republic. The call for papers closes August 31. "The first day will be much like the last two years, with talks and panels. The second day will feature workshops and developer sprints, as well as the opportunity to deep dive on topics discussed on the first day."

Full Story (comments: none)

CFP Deadlines: August 17, 2017 to October 16, 2017

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

Deadline	Event Dates	Event	Location
August 18	November 11 November 12	Intel® HPC Developer Conference	Denver, CO, USA
August 21	December 6 December 8	CloudNativeCon + KubeCon North America 2017	Austin, TX, USA
August 21	October 16 October 20	Tcl/Tk Conference 2017	Houston, TX, USA
August 24	November 4 November 5	PyCon HK 2017	Hong Kong, Hong Kong
August 27	October 21 October 22	Datenspuren	Dresden, Germany
August 31	November 7 November 9	Cuban Free Technologies Conferences	Havana, Cuba
August 31	November 4 November 5	PyCon India 2017	Delhi, India
August 31	October 28 October 29	freenode #live	Bristol, UK
August 31	October 26 October 27	OpenWrt Summit	Prague, Czech Republic
September 1	October 5 October 6	PyCon South Africa	Cape Town, South Africa
September 1	October 27	Tracing Summit 2017	Prague, Czech Republic
September 3	October 21 October 22	All Systems Go!	Berlin, Germany
September 8	September 8 September 10	ORConf 2017	Hebden Bridge, UK
September 15	November 4 November 5	OpenFest 2017	Sofia, Bulgaria
September 20	November 8 November 10	Netdev 2.2	Seoul, South Korea
September 30	November 18 November 19	Technical Dutch Open Source Event	Eindhoven, Netherlands
September 30	November 18 November 19	Toulouse mini-DebConf 2017	Toulouse, France
October 1	December 6 December 7	Linux-Lab	Firenze, Italy
October 7	November 11	Linux Developer Conference Brazil	São Paulo, Brazil
October 15	April 26 April 27	FLOSSUK – Spring Conference	Edinburgh, Scotland

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

Events: August 17, 2017 to October 16, 2017

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

Date(s)	Event	Location
August 13 August 18	DjangoCon US	Spokane, WA, USA
August 16 August 18	Golang UK conference	London, UK
August 18 August 20	State of the Map	Aizuwakamatsu, Fukushima, Japan
August 18 August 20	QtCon Brasil 2017	São Paulo, Brasil
August 19 August 20	Free and Open Source Software Conference	St. Augustin (near Cologne), Germany
August 22 August 29	Nextcloud Conference	Berlin, Germany
August 23 August 25	JupyterCon	New York, NY, USA
August 25 August 26	Swiss Perl Workshop	Villars-sur-Ollon, Switzerland
August 25 August 27	GNU Hackers' Meeting 2017	Kassel, Germany
August 26	FOSSCON	Philadelphia, PA, USA
August 28 September 1	10th European Conference on Python in Science	Erlangen, Germany
September 6 September 8	PostgresOpen	Silicon Valley, CA, USA
September 6 September 9	Radare conference 2017	Barcelona, Spain
September 7	ML Family Workshop	Oxford, UK
September 8 September 9	PyCon Japan	Tokyo, Japan
September 8	OCaml Users and Developers Workshop	Oxford, UK
September 8 September 10	GNU Tools Cauldron 2017	Prague, Czech Republic
September 8 September 10	ORConf 2017	Hebden Bridge, UK
September 11 September 14	Open Source Summit NA 2017	Los Angeles, CA, USA
September 13 September 15	Linux Plumbers Conference 2017	Los Angeles, CA, USA
September 13 September 15	MesosCon North America	Los Angeles, CA, USA
September 14 September 15	Linux Security Summit	Los Angeles, CA, USA
September 15 September 17	Balkan Computer Congress	Vojvodina, Serbia
September 18 September 20	O’Reilly Artificial Intelligence Conference	San Francisco, CA, USA
September 18 September 19	OpenMP Conference	Stony Brook, NY, USA
September 20 September 22	X.org Developers Conference	Mountain View, CA, USA
September 21 September 22	International Workshop on OpenMP	Stony Brook, NY, USA
September 21 September 24	EuroBSDcon 2017	Paris, France
September 22 September 24	VideoLAN developers days	Paris, France
September 25 September 26	Open Source Backup Conference 2017	Köln, Germany
September 26	OpenStack Days UK	London, UK
September 26	Embedded Recipes 2017	Paris, France
September 27 September 29	Kernel Recipes 2017	Paris, France
September 27 September 29	Alpine Linux Persistence and Storage Summit	Lizumerhuette, Austria
September 29 September 30	Ohio LinuxFest	Columbus, OH, USA
September 30 October 1	RustFest Zürich	Zurich, Switzerland
October 2 October 4	O'Reilly Velocity Conference	New York, NY, USA
October 3	PostgresqlConf South Africa	Cape Town, South Africa
October 4 October 5	Lustre Administrator and Developer Workshop	Paris, France
October 5	Open Hardware Summit 2017	Denver, CO, USA
October 5 October 6	PyCon South Africa	Cape Town, South Africa
October 6 October 8	PyGotham	New York, NY, USA
October 6 October 7	Seattle GNU/Linux Conference	Seattle, WA, USA
October 6 October 8	Festival of the Commons	Athens, Greece
October 7 October 8	MiniDebConf Prishtina	Prishtina, Kosovo
October 7 October 8	Silicon Valley Code Camp	San Jose, CA, USA
October 10 October 12	Qt World Summit	Berlin, Germany
October 11 October 13	LibreOffice Conference 2017	Rome, Italy
October 14 October 16	GNOME.Asia Summit	Chongqing, China

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

Alert summary August 10, 2017 to August 16, 2017

Dist.	ID	Release	Package	Date
Arch Linux	ASA-201708-9		audiofile	2017-08-15
Arch Linux	ASA-201708-3		firefox	2017-08-10
Arch Linux	ASA-201708-2		flashplugin	2017-08-10
Arch Linux	ASA-201708-6		git	2017-08-14
Arch Linux	ASA-201708-8		jdk7-openjdk	2017-08-14
Arch Linux	ASA-201708-1		lib32-flashplugin	2017-08-10
Arch Linux	ASA-201708-5		libsoup	2017-08-10
Arch Linux	ASA-201708-10		libytnef	2017-08-15
Arch Linux	ASA-201708-7		mercurial	2017-08-14
Arch Linux	ASA-201708-12		spice	2017-08-15
Arch Linux	ASA-201708-13		strongswan	2017-08-15
Arch Linux	ASA-201708-14		subversion	2017-08-15
Arch Linux	ASA-201708-4		varnish	2017-08-10
Arch Linux	ASA-201708-11		xorg-server	2017-08-15
CentOS	CESA-2017:2456	C6	firefox	2017-08-15
CentOS	CESA-2017:2478	C6	httpd	2017-08-15
CentOS	CESA-2017:2424	C6	java-1.7.0-openjdk	2017-08-15
Debian	DSA-3939-1	stable	botan1.10	2017-08-12
Debian	DLA-1056-1	LTS	cvs	2017-08-13
Debian	DSA-3940-1	stable	cvs	2017-08-13
Debian	DLA-1053-1	LTS	firefox-esr	2017-08-12
Debian	DSA-3928-1	stable	firefox-esr	2017-08-10
Debian	DSA-3930-1	stable	freeradius	2017-08-10
Debian	DSA-3943-1	stable	gajim	2017-08-14
Debian	DSA-3934-1	stable	git	2017-08-10
Debian	DSA-3940-1	stable	iortcw	2017-08-13
Debian	DLA-1058-1	LTS	krb5	2017-08-14
Debian	DLA-1055-1	LTS	libgd2	2017-08-12
Debian	DSA-3938-1	stable	libgd2	2017-08-12
Debian	DLA-1054-1	LTS	libgxps	2017-08-12
Debian	DLA-1057-1	LTS	libraw	2017-08-14
Debian	DSA-3929-1	stable	libsoup2.4	2017-08-10
Debian	DSA-3933-1	stable	pjproject	2017-08-10
Debian	DLA-1051-1	LTS	postgresql-9.1	2017-08-10
Debian	DSA-3935-1	stable	postgresql-9.4	2017-08-10
Debian	DSA-3936-1	stable	postgresql-9.6	2017-08-10
Debian	DLA-1052-1	LTS	subversion	2017-08-11
Debian	DSA-3932-1	stable	subversion	2017-08-10
Debian	DSA-3942-1	stable	supervisor	2017-08-13
Debian	DLA-??????	LTS	xchat	2017-08-10
Debian	DSA-3937-1	stable	zabbix	2017-08-12
Fedora	FEDORA-2017-127e76d78d	F25	cacti	2017-08-09
Fedora	FEDORA-2017-7c039552fa	F25	community-mysql	2017-08-09
Fedora	FEDORA-2017-ee93493bea	F26	community-mysql	2017-08-09
Fedora	FEDORA-2017-191d7ec089	F26	cups-filters	2017-08-15
Fedora	FEDORA-2017-f2df9d7772	F25	curl	2017-08-14
Fedora	FEDORA-2017-f1ffd18079	F26	curl	2017-08-13
Fedora	FEDORA-2017-3df020e756	F25	firefox	2017-08-12
Fedora	FEDORA-2017-8ba7572cfd	F25	git	2017-08-14
Fedora	FEDORA-2017-b1b3ae6666	F26	git	2017-08-13
Fedora	FEDORA-2017-ff06ff0ec9	F25	gsoap	2017-08-10
Fedora	FEDORA-2017-d2174c28ed	F26	gsoap	2017-08-10
Fedora	FEDORA-2017-90ad72e684	F25	irssi	2017-08-10
Fedora	FEDORA-2017-f452765e1e	F25	jackson-databind	2017-08-11
Fedora	FEDORA-2017-6a75c816fa	F26	jackson-databind	2017-08-12
Fedora	FEDORA-2017-adc7d95627	F26	kernel	2017-08-14
Fedora	FEDORA-2017-b9433ad88e	F25	knot-resolver	2017-08-10
Fedora	FEDORA-2017-4762689cb7	F26	knot-resolver	2017-08-10
Fedora	FEDORA-2017-0ca78fabc5	F26	libgxps	2017-08-13
Fedora	FEDORA-2017-872a0a9a85	F25	libsoup	2017-08-14
Fedora	FEDORA-2017-b0ec173bd1	F26	libsoup	2017-08-13
Fedora	FEDORA-2017-920b27e8f4	F26	openjpeg2	2017-08-13
Fedora	FEDORA-2017-b812362f61	F25	php-horde-Horde-Core	2017-08-10
Fedora	FEDORA-2017-1929be4354	F26	php-horde-Horde-Core	2017-08-10
Fedora	FEDORA-2017-26f9e09c8a	F25	php-horde-Horde-Form	2017-08-10
Fedora	FEDORA-2017-ca6f3b5770	F26	php-horde-Horde-Form	2017-08-10
Fedora	FEDORA-2017-17f457262c	F25	php-horde-Horde-Url	2017-08-10
Fedora	FEDORA-2017-6775ec59f1	F26	php-horde-Horde-Url	2017-08-10
Fedora	FEDORA-2017-7c19905c9b	F25	php-horde-horde	2017-08-10
Fedora	FEDORA-2017-1081235137	F26	php-horde-horde	2017-08-10
Fedora	FEDORA-2017-692c05119d	F25	php-horde-kronolith	2017-08-10
Fedora	FEDORA-2017-ceb60ebf8f	F26	php-horde-kronolith	2017-08-10
Fedora	FEDORA-2017-34d34904f5	F25	php-horde-nag	2017-08-10
Fedora	FEDORA-2017-d1c86c61f2	F26	php-horde-nag	2017-08-10
Fedora	FEDORA-2017-449b22158f	F25	php-horde-turba	2017-08-10
Fedora	FEDORA-2017-f52687b573	F26	php-horde-turba	2017-08-10
Fedora	FEDORA-2017-d9cac37bd8	F26	postgresql	2017-08-14
Fedora	FEDORA-2017-d7739ff31b	F25	potrace	2017-08-15
Fedora	FEDORA-2017-44bfb0f3e5	F26	potrace	2017-08-12
Fedora	FEDORA-2017-03893a3b58	F26	pspp	2017-08-09
Fedora	FEDORA-2017-4ede204115	F25	python-dbusmock	2017-08-12
Fedora	FEDORA-2017-191d7ec089	F26	qpdf	2017-08-15
Fedora	FEDORA-2017-5f2b220c7c	F26	spatialite-tools	2017-08-13
Fedora	FEDORA-2017-571e659c85	F25	sqlite	2017-08-14
Fedora	FEDORA-2017-5f2b220c7c	F26	sqlite	2017-08-13
Fedora	FEDORA-2017-56b8f257af	F25	sscep	2017-08-15
Fedora	FEDORA-2017-a5fc805283	F26	sscep	2017-08-14
Fedora	FEDORA-2017-951b6a78d4	F26	subversion	2017-08-14
Fedora	FEDORA-2017-bfbc5de1b1	F25	varnish	2017-08-15
Mageia	MGASA-2017-0267	6	cacti	2017-08-14
Mageia	MGASA-2017-0262	6	ffmpeg	2017-08-13
Mageia	MGASA-2017-0268	5, 6	firefox	2017-08-15
Mageia	MGASA-2017-0266	5, 6	git	2017-08-14
Mageia	MGASA-2017-0265	5, 6	heimdal	2017-08-13
Mageia	MGASA-2017-0255	5, 6	jackson-databind	2017-08-12
Mageia	MGASA-2017-0260	5	kernel-linus	2017-08-13
Mageia	MGASA-2017-0258	6	kernel-linus	2017-08-13
Mageia	MGASA-2017-0261	5	kernel-tmb	2017-08-13
Mageia	MGASA-2017-0259	6	kernel-tmb	2017-08-13
Mageia	MGASA-2017-0256	5, 6	krb5	2017-08-12
Mageia	MGASA-2017-0272	5, 6	libsoup	2017-08-16
Mageia	MGASA-2017-0271	5	mingw32-nsis	2017-08-16
Mageia	MGASA-2017-0254	5, 6	perl-XML-LibXML	2017-08-10
Mageia	MGASA-2017-0257	5, 6	php-phpmailer	2017-08-13
Mageia	MGASA-2017-0270	5, 6	phpldapadmin	2017-08-15
Mageia	MGASA-2017-0264	5, 6	ruby-rubyzip	2017-08-13
Mageia	MGASA-2017-0263	5, 6	supervisor	2017-08-13
Mageia	MGASA-2017-0253	6	varnish	2017-08-09
Mageia	MGASA-2017-0269	5	x11-server	2017-08-15
openSUSE	openSUSE-SU-2017:2151-1	42.2 42.3	firefox	2017-08-12
openSUSE	openSUSE-SU-2017:2169-1	42.2	kernel	2017-08-15
openSUSE	openSUSE-SU-2017:2171-1	42.3	kernel	2017-08-15
openSUSE	openSUSE-SU-2017:2149-1	42.2 42.3	librsvg	2017-08-12
openSUSE	openSUSE-SU-2017:2153-1	42.2 42.3	libsoup	2017-08-12
openSUSE	openSUSE-SU-2017:2119-1	42.2 42.3	mariadb	2017-08-10
openSUSE	openSUSE-SU-2017:2125-1	42.2 42.3	nasm	2017-08-10
openSUSE	openSUSE-SU-2017:2158-1	42.2 42.3	ncurses	2017-08-12
openSUSE	openSUSE-SU-2017:2123-1	42.2 42.3	pspp	2017-08-10
openSUSE	openSUSE-SU-2017:2120-1	42.2 42.3	rubygem-rubyzip	2017-08-10
openSUSE	openSUSE-SU-2017:2155-1	42.3	tcmu-runner	2017-08-12
Oracle	ELSA-2017-2299	OL7	NetworkManager and libnl3	2017-08-09
Oracle	ELSA-2017-1865	OL7	X.org	2017-08-09
Oracle	ELSA-2017-2388	OL7	evince	2017-08-09
Oracle	ELSA-2017-2456	OL6	firefox	2017-08-11
Oracle	ELSA-2017-2456	OL7	firefox	2017-08-11
Oracle	ELSA-2017-2389	OL7	freeradius	2017-08-09
Oracle	ELSA-2017-1859	OL7	golang	2017-08-09
Oracle	ELSA-2017-2478	OL6	httpd	2017-08-15
Oracle	ELSA-2017-2479	OL7	httpd	2017-08-15
Oracle	ELSA-2017-2424	OL6	java-1.7.0-openjdk	2017-08-09
Oracle	ELSA-2017-2424	OL7	java-1.7.0-openjdk	2017-08-09
Oracle	ELSA-2017-1842-1	OL7	kernel	2017-08-15
Oracle	ELSA-2017-2473	OL7	kernel	2017-08-15
Oracle	ELSA-2017-2459	OL7	libsoup	2017-08-10
Oracle	ELSA-2017-2423	OL7	log4j	2017-08-09
Oracle	ELSA-2017-2335	OL7	pki-core	2017-08-09
Oracle	ELSA-2017-2445	OL7	qemu-kvm	2017-08-09
Oracle	ELSA-2017-2471	OL7	spice	2017-08-15
Oracle	ELSA-2017-2480	OL7	subversion	2017-08-15
Red Hat	RHSA-2017:2456-01	EL6 EL7	firefox	2017-08-10
Red Hat	RHSA-2017:2457-01	EL6	flash-plugin	2017-08-10
Red Hat	RHSA-2017:2478-01	EL6	httpd	2017-08-15
Red Hat	RHSA-2017:2479-01	EL7	httpd	2017-08-15
Red Hat	RHSA-2017:2481-01	EL6 EL7	java-1.7.1-ibm	2017-08-15
Red Hat	RHSA-2017:2469-01	EL6 EL7	java-1.8.0-ibm	2017-08-14
Red Hat	RHSA-2017:2472-01	EL5.9	kernel	2017-08-15
Red Hat	RHSA-2017:2473-01	EL7	kernel	2017-08-15
Red Hat	RHSA-2017:2459-01	EL7	libsoup	2017-08-10
Red Hat	RHSA-2017:2471-01	EL7	spice	2017-08-14
Red Hat	RHSA-2017:2480-01	EL7	subversion	2017-08-15
Scientific Linux	SLSA-2017:2478-1	SL6	httpd	2017-08-15
Slackware	SSA:2017-221-01		curl	2017-08-09
Slackware	SSA:2017-223-01		git	2017-08-11
Slackware	SSA:2017-223-02		libsoup	2017-08-11
Slackware	SSA:2017-223-03		mercurial	2017-08-11
Slackware	SSA:2017-221-02		mozilla	2017-08-09
Slackware	SSA:2017-223-04		subversion	2017-08-11
Slackware	SSA:2017-227-01		xorg	2017-08-15
SUSE	SUSE-SU-2017:2175-1	OS6 SLE12	java-1_8_0-openjdk	2017-08-16
SUSE	SUSE-SU-2017:2150-1	OS6 SLE12	kernel	2017-08-12
SUSE	SUSE-SU-2017:2131-1	SLE12	kernel	2017-08-11
SUSE	SUSE-SU-2017:2142-1	SLE12	kernel	2017-08-11
SUSE	SUSE-SU-2017:2130-1	OS6 SLE12	libsoup	2017-08-10
SUSE	SUSE-SU-2017:2129-1	SLE12	libsoup	2017-08-10
SUSE	SUSE-SU-2017:2163-1	SLE11	subversion	2017-08-14
Ubuntu	USN-3391-1	14.04 16.04 17.04	firefox	2017-08-15
Ubuntu	USN-3387-1	14.04 16.04 17.04	git	2017-08-10
Ubuntu	USN-3386-1	14.04	kernel	2017-08-10
Ubuntu	USN-3389-2	12.04	libgd2	2017-08-14
Ubuntu	USN-3389-1	14.04 16.04 17.04	libgd2	2017-08-14
Ubuntu	USN-3383-1	14.04 16.04 17.04	libsoup2.4	2017-08-10
Ubuntu	USN-3392-1	16.04	linux, linux-aws, linux-gke, linux-raspi2, linux-snapdragon	2017-08-15
Ubuntu	USN-3385-1	16.04	linux, linux-aws, linux-gke, linux-raspi2, linux-snapdragon	2017-08-10
Ubuntu	USN-3384-1	17.04	linux, linux-raspi2	2017-08-10
Ubuntu	USN-3384-2	16.04	linux-hwe	2017-08-10
Ubuntu	USN-3386-2	12.04	linux-lts-trusty	2017-08-10
Ubuntu	USN-3392-2	14.04	linux-lts-xenial	2017-08-15
Ubuntu	USN-3385-2	14.04	linux-lts-xenial	2017-08-10
Ubuntu	USN-3382-1	14.04 16.04 17.04	php5, php7.0	2017-08-10
Ubuntu	USN-3390-1	14.04 16.04 17.04	postgresql-9.3, postgresql-9.5, postgresql-9.6	2017-08-15
Ubuntu	USN-3388-1	14.04 16.04 17.04	subversion	2017-08-10
Ubuntu	USN-3391-2	14.04 16.04 17.04	ubufox	2017-08-16

Full Story (comments: none)