Semi-automatic document scanning with Paperwork

The paperless office, much like the year of the Linux desktop, always seems to remain just out of reach. In large part, this is because there is little that one person can do to prevent other people from printing and sending hard-copy documents. But there are tools to help convert these unwanted papers into digital form that can be integrated, to one degree or another, with the filesystems and databases that keep track of everything else. One such tool is Paperwork, a graphical tool to scan, extract text from, and automatically index paper documents.

Scanning, itself, is close to being treated as a solved problem on Linux desktops. If the goal is merely to scan images of paper documents, there are loads of existing applications to do just that. Where Paperwork makes its claims of superiority, though, is in its support for recognizing text on the page, extracting it into a searchable form, then intelligently assigning labels that reflect semantic meaning.

Making this work requires generating some metadata from each scanned page, and storing it in a systematic fashion inside the directory structure alongside the scan. Paperwork uses the Tesseract optical character recognition (OCR) library to detect and extract page text. It then stores the extracted text in a foo.words file. Next, the scanned text is indexed and added to Paperwork's database (which allows the user to search across the document collection). Finally, a Bayesian text classifier is run on the text to suggest relevant labels. The user can also manually attach keywords to any scanned document; these keywords and the labels are also stored in files within the directory, making them, too, accessible to external programs.

Paperwork is written in Python 2 and is available for installation from the Python Package Index. This should pull in most of the dependencies, although there is a dependency checker (called paperwork-chkdeps) included in the package. The latest release is version 0.3.1, from February 26. Once installed, the application is launched with paperwork. Any SANE-supported scanner should be usable, but Paperwork can also import image files and PDFs, so having a scanner on hand is not required.

Paperwork's workflow is largely automated. First, the user creates a new document in the internal collection, then they must scan pages to add to that document (or, alternatively, import pages from external files). Once each page has been added to the document, though, Paperwork tries automatically determine the orientation of the text, then runs the Tesseract OCR scanner on the page in the background. Whenever the user hovers the cursor over the page, the interface pops up the words that Tesseract has detected; there is also a menu entry to show all of the detected text. The user can continue to scan and add new pages until all have been added, then save the result.

After completing the OCR pass over all the pages in a new document, Paperwork attempts to automatically assign labels to categorize the text. In practice, the classifier engine that takes this step needs a corpus of documents with existing labels in order to do its job. Thus, the user will have to manually assign every label to the first document, and will likely have to delete labels assigned overzealously to the first several documents. In the long run, the usefulness of the labels hinges on having a set of somewhat related documents. A weird outlier will either end up unlabeled or mislabeled. One regrettable missing feature is an ability to re-run the classifier on one or more documents; there is a feature to re-run the OCR step, so perhaps there is hope for the future.

The search feature lets the user type words into the search box, and presents a live-updated list of matching documents below. Click on any of the matching documents in the list, and Paperwork will open it in a viewer window highlighting the location of each search term. Multi-word search terms are not supported, nor are logical operators.

The simplicity of the search feature might sound like a big limitation—after all, with a lot of documents, some way to narrow down the search would be nice. But the quality of the OCR stage is likely to be more important. Tesseract has come a long way in recent years; I tested it shortly after its initial open-source release ten years ago, when the scan results from other OCR engines were likely to be riddled with elementary spelling mistakes. Tesseract has always been better than the competition, but in those early years it tended to perform poorly on small font sizes, and it tended to erroneously flag images and shadows as text blocks.

For the sake of comparison, I ran paperwork on a some of the smallest text I could find: the legalese in the warranty booklet for a cell phone. Tesseract did admirably; it tagged several shadows, but with a single exception it did not "recognize" letters in them as it might have in the past. I only found two instances where it split a word into two segments, and none where it combined two words into one. Moreover, I do not think there were any spelling mistakes, which is a noteworthy achievement. It also seems to be geared toward detecting black-on-white text, to the point where it occasionally misses lighter print or text within images.

That said, free-software OCR is capable of doing more. Tesseract outputs text in the hOCR format, an XML format that stores each detected word along with the coordinates of its bounding box in the source image. Several other projects exist that can build on this word-level information to detect lines, paragraphs, and even larger page structure (think columns of text that wrap around images). The OCRopus engine does this internally, while GNOME's OCRFeeder can do page-layout detection on top of Tesseract output. While Paperwork does not need to detect page layout in order to run simple searches, at least reconstructing sentences would allow users to search for multi-word phrases.

Paperwork bills itself as a "scan and forget" tool, so it may be asking too much to expect it to detect page layout. As a mostly automated "document ingest" application, it certainly succeeds where other scanning programs for Linux desktops fall flat. What remains to be seen is whether scanning and forgetting works well over the long haul. The project is a small operation at present, without posted plans for where it intends to go in the future. The automatic labeling of contents will surely improve over time as Paperwork gets more familiar with a corpus of documents, but the bare-bones search functionality is likely to become a pain as one accumulates more and more scanned documents.

Comments (8 posted)

Cyanogen deactivates WhisperPush in favor of Signal

In late 2013, the CyanogenMod project introduced the WhisperPush service, a secure-messaging transport that provided end-to-end encryption and identity verification. In February 2015, however, CyanogenMod shut down the service and advised users to migrate to the Signal service provided by Open Whisper Systems. Although Signal is renowned by experts for its solid security underpinnings, the demise of WhisperPush still comes at a cost for end users.

In 2013, Open Whisper Systems was maintaining two distinct Android apps: TextSecure, which provided encrypted instant messaging, and RedPhone, which provided encrypted voice calls. WhisperPush was built on top of an independent implementation of the TextSecure protocol, and enabled CyanogenMod users to exchange messages with one another as well as with any TextSecure user.

By the time work began in earnest for CyanogenMod 12.1, though, Open Whisper Systems had evolved the TextSecure protocol considerably, merging TextSecure's functionality with that of RedPhone to develop Signal. CyanogenMod briefly mounted an effort to drop the WhisperPush app and merge support for the service into its general-purpose Messaging app but, by January 2016, the project decided that the maintenance effort was not worth the support costs.

For CyanogenMod, most of those support costs seem to have been in running the server end of the WhisperPush service, rather than in developing the app. The service required a running a message-passing server to relay encrypted exchanges between users, but also a separate verification framework. WhisperPush, like TextSecure, used SMS text messages to verify user accounts "out of band"—that is, by sending the verification codes over the normal phone system, rather than through the WhisperPush service.

Running that service incurs a separate set of costs, including maintaining phone numbers in each region of the world where WhisperPush was available. Add to those costs the rapidly growing popularity of Signal among CyanogenMod users, and running the independent service no longer made sense for Cyanogen (the company).

The blog post announcing the shutdown encourages users to move to Signal, noting along the way that Open Whisper Systems helped develop WhisperPush in the beginning and has been a friendly partner along the way. The shutdown was finalized on February 1. Those who praise Signal are quick to point out that it, like WhisperPush, is open-source software on both the client and server side. Furthermore, Signal is now available for iOS (and is in beta testing as a Chrome-extension–based "desktop app"), making it useful to a wider assortment of users.

But there are also downsides to Signal, starting with the fact that it relies on Google's proprietary Google Play Services system to relay various event notifications (although, it should be noted, not to relay encrypted messages themselves). This introduces a possible privacy risk. As a single hub through which all Signal apps send some traffic, Google Play Services might be used by an attacker or law-enforcement agent as a place to collect metadata about Signal users. As many pundits have noted in the wake of the NSA surveillance scandal, metadata can be used to collect quite a bit of information about users even when message contents remain encrypted.

Additionally, the reliance on Google Play Services means that the Signal network has a dependency on a third-party service not under Open Whisper Systems's control. If the Google service ceases to be available (again, perhaps at the behest of law enforcement), that would interfere with all Signal users.

But the most fundamental issue may be that the shutdown of WhisperPush returns the "TextSecure ecosystem" to its previous state of being a monolithic service. Even if Signal users numbered far more than WhisperPush users, the fact that the two services were federated made both more resilient to trouble. If the Open Whisper Systems servers were taken down or compromised, the alternative might still be viable.

Certainly, motivated developers can develop their own interoperable implementations of the Signal protocol; the free-software community often takes up such causes and often with great success. There is one such effort at present, named LibreSignal, but Open Whisper Systems officially regards self-hosted Signal servers as unsupported. Interoperability with WhisperPush persisted for as long as it did because of the good working relationship that already existed between the projects.

Open Whisper Systems's resistance to service federation is unfortunate, but perhaps the project could be persuaded to relax that stance if a viable service produces reliable code and demonstrates the importance of providing users with a choice. For the time being, however, the decommissioning of WhisperPush leaves security-minded mobile users with one fewer avenues for safeguarding their private communication.

Comments (none posted)

Tvheadend versus MythTV

Recently, I took advantage of an unforeseen hardware problem to experiment with replacing one of the longest-running services on my home network: the MythTV service that records local broadcast television. The replacement I explored was Tvheadend (TVH), which provides a recording back-end and electronic program guide (EPG) but no dedicated playback front-end. For a number of reasons, TVH is easier to work with, although—for the time being—it does not boast quite as many features at MythTV.

To provide some background, the tuner hardware I use with MythTV is a pair of networked HDHomeRun devices. Each one is connected only to an antenna and they pick up only a handful of channels; there is no cable or satellite service in the mix. This puts my recording needs staunchly on the low end of the spectrum compared to other MythTV users, but such modest requirements do not make MythTV more cooperative to configure, use, or troubleshoot. When one of the HDHomeRun tuners started exhibiting flaky performance, I bought a replacement and decided to put the new device to the test with TVH—at least temporarily—just to gauge the difference.

MythTV has been around since 2002; it predates the digital-television transition and, thus, has a fair amount of technical debt to manage—stemming from the need to support analog tuners and encoders and due to the age of the codebase itself. TVH is much newer; it is focused specifically on supporting DVB and IP television (IPTV) services. Here in the United States, DVB is generally only found on free-to-air (FTA) satellite systems (DVB-S), while broadcast signals are sent in ATSC. Luckily, the HDHomeRun product line is the exception to TVH's DVB-centric focus (probably because the devices themselves are plug-and-play and the video formats are virtually identical MPEG-2 streams), so the devices let one record ATSC broadcasts.

Head on

I tested TVH version 4.0.8 running on an Ubuntu 14.04 machine—the same one running the MythTV backend. That older distribution choice is an artifact of using MythTV; MythTV updates have a nasty habit of breaking in subtle ways—to the point where users are usually advised to only run the service on long-term-support (LTS) releases. For deployment on a fresh system, TVH supports plenty of more recent distributions, as well as FreeBSD and Android.

The TVH installation process is simple enough; the installer prompts the user to create a username/password combination for use inside the application itself. Other users can be created after the fact, to separate configuration from recording privileges. The program runs as a single process (as the hts user) that exposes a web interface on http://localhost:9981 . There are also access control list (ACL) and key-based options available to further restrict access, although they are not enabled by default.

System configuration is done entirely in the web interface. Notably, TVH uses a somewhat different nomenclature to describe the relationship between the available signals, program streams, and "channels" that one needs to enumerate. A "network" refers to a broadcast medium (e.g., over-the-air antenna, satellite provider, IPTV source, etc.); a "mux" refers to a tunable frequency that might carry one or more "services" (which constitute what most people call "channels" in the vernacular lingo). But TVH does automatically discover most of the available tuning hardware and, when told what "network" to associate with a tuner, it will automatically scan to pick up whatever "muxes" and "services" it can find. The intent of this complex model is to allow TVH to combine multiple signal sources (terrestrial, satellite, and broadcast) into a single channel map, glossing over a number of potential differences in how the components are labeled. Consulting the user guide is helpful, though, particularly for making sense out of all of the configuration minutiae.

After configuring program reception, the next most critical setup task is getting EPG information. In my test, this was TVH's weakest point by far. Although the program supports an array of EPG sources, none of them worked for over-the-air broadcast in the US. Worse, the relevant chapter in the manual is filled with empty sections and the forums are filled with frustrated users asking the same questions and getting no solutions. Eventually, I tracked down an external blog post that pointed toward a solution; sadly, the solution is an ugly workaround for what is (apparently) TVH's broken support for the XMLTV guide-data grabber. It seems, however, that users in DVB regions of the globe have a much easier time with this step.

With EPG data in place, one can schedule single or recurring recordings from within the web interface. The UI for doing so is not sophisticated; there is a long list of programs in a spreadsheet-style list (XMLTV grabs two weeks' worth of EPG data at a time) and one can search or filter it on a number of fields (episode titles, service, content tags, etc.). The giant list of programs is less user-friendly than the classic "TV Guide" grid, but at least the search and filter functions are easy to use—which cannot be said for MythTV, where searching and filtering features are split into several sections placed rather far apart from each other in the configuration-screen hierarchy.

As for recordings themselves, TVH does little to nothing with them after they are saved to disk; the intent is that users will access their content through another front-end like Kodi. On the plus side, this makes managing content easier in some respects: normal filesystem tools are all that one needs to track and delete files, or one can simply rely on the tools built into the front-end. In contrast, MythTV relies on a background process that schedules deletions using a lengthy list of overlapping criteria. TVH also allows complete freedom in where individual recordings are stored and how the files are named; MythTV provides neither feature.

The late night wars

Setup and configuration is the hardest part of using MythTV. For starters, MythTV's back-end process (which handles EPG and scheduling recordings) can only be configured through a GUI application, making it a poor fit for headless systems. More importantly, though, that configuration tool uses a mix of keyboard-only commands that are hard to discover and onscreen elements that can only be accessed with a mouse. Many of the settings must be altered by stepping sequentially through a lengthy series of screens (at times, ten or more).

And the interface itself is not the only awkward factor: tweaking MythTV's behavior is difficult. To give one brief example, the decision of which tuner should be used to record a particular program (e.g., to cope with one antenna receiving a signal stronger than another) involves at least six settings: the "priority" of the tuner/channel mapping, an "preferred input" setting attached to the recording rule, the "priority" setting of the recording rule, separate "priority" points assigned for HDTV and wide-screen broadcasts, and the order in which the tuners were initially configured during setup. How exactly they interact is one of the project's enduring mysteries.

On that type of issue, TVH is far ahead of the competition. The desired documentation is clearly missing in places, but setup is certainly simpler and better organized than MythTV's. That said, it is also possible that TVH's design seems friendlier to those who have experience with Unix systems, because it relies on several system services. The EPG grabber, for example, adds crontab entries to schedule updates, whereas MythTV runs a separate background daemon to fetch and update guide data. Which approach is "better" may be an opinion question, but crontab is far better documented.

The other vital factor to keep in mind if one is debating a move from MythTV to TVH is that TVH is still limited primarily to DVB recording hardware. In contrast, a great many MythTV users record programs from cable or satellite set-top boxes using external encoders like the Hauppauge HD-PVR. As near as I can tell, TVH does not support this hardware use case at all, though there are some potential workarounds if one is willing to write external scripts. And, to be fair, MythTV's support for these devices relies on its share of external workaround scripts, too—they simply ship with the code.

Stay tuned

As I alluded to in September, I have been trying to streamline and simplify the various services running throughout the house, and reports were that TVH would be less convoluted to use than MythTV. Based on a few days of testing, this appears to be the case when it comes to managing hardware and scheduling recordings, although TVH still falls short on EPG support for the region I live in.

According to the project, the upcoming 4.2 release will improve support for the North American ATSC broadcast format—among other things, adding the ability to extract embedded EPG information directly from the broadcast stream. So it is a release that I plan to watch for. Those users living in DVB regions of the world will probably have an easier time getting TVH up and running; for those users, the program offers substantial improvements over MythTV.

Comments (5 posted)

TLS certificate management on Android

In theory, the TLS certificate system increases security by letting users verify that they are connecting to the sites that they think they are. In practice it hasn't worked out as well as one might hope for a number of reasons; these range from intermediary sites that look like man-in-the-middle (MITM) attacks to inept and fraudulent certificate authorities. Sometimes it seems like the systems we use are set up in ways designed to make security difficult; Android's handling of user-supplied certificates is a case in point.

Whenever an application makes a TLS connection to another host, it should validate the certificate it receives from that host to be sure that the connection has not been intercepted. One aspect of that validation is ensuring that the certificate is issued to the expected site; many apps (on Android and beyond) tend not to bother with that step, assuming that any certificate they get is good enough. There is another important step, though: ensuring that the certificate has been signed by a certificate authority (CA) that the user trusts. After all, anybody can create a certificate that claims to belong to, say, lwn.net, but the established CAs are not supposed to sign them without having somehow convinced themselves that the requestor actually owns the name.

Verifying the provenance of a certificate requires a database of the CAs that are trusted to sign certificates. On full-fledged Linux distributions, that database often comes from Mozilla, with perhaps a few distribution-specific tweaks. On Android, the CA database is managed centrally, so the policies established by Google control the trusting of certificates for most Android apps.

A complicating factor is that certificates that are not signed by one of the "trusted" CAs are common and have many legitimate uses. In some cases, the operator of a web site may just not want to deal with the trouble and expense of getting a recognized certificate. In other cases, there may be a need to set up one's own trusted CA that can issue arbitrary certificates. That is often done in institutional environments to assist with the operation of web proxies and virtual private networks. Such a certificate can also enable just the sort of MITM attack that TLS was meant to thwart; some companies will use them to monitor traffic into and out of their networks, for example.

Android makes it possible for a user to import a new CA certificate; after that, the device will trust certificates that have been signed by that CA. There is just one little difficulty: Android insists on putting up a scary warning at each boot, saying that "a third party is capable of monitoring your network activity". This happens despite the fact that the user has already been through a multi-step, warning-heavy process to install the certificate. There is, it seems, no straightforward way to make it go away.

Unsurprisingly, Android users who have reason to install their own CA certificates find this annoying. Many of them, perhaps, have a dim view of the trustworthiness of some of the CA certificates provided out of the box, and don't like having to slog through warnings to use a certificate they actually do trust. There have been various bug reports filed regarding this problem, but Google's response has been clear: the system is working as intended:

In other words, the only way to get a truly trusted CA certificate installed on Android is to go through the entire CA process for companies that want to sell certificates to the world as a whole. It seems likely that your typical user wanting to install their own CA certificate will balk at that idea.

There are a few unpleasant things that can result from this sort of policy. One is that users will become (even more) used to brushing aside scary warnings without thinking about them. If the system is forever crying wolf, it will be unsurprising if users are not paying attention the one time that there is a true wolf to worry about. Another outcome is that users have a stronger incentive to root their devices so that apps like movecerts, which directly manipulate the certificate store to make the warnings go away, can be run. Rooting the device and running privileged apps, even open-source ones, presents some obvious security hazards of its own.

Bringing security into a discussion often introduces strange distortions, and TLS is especially prone to that. Web browsers will frighten users over self-signed certificates, but have no objection to sites that don't use TLS at all. In the Android case, users who have attempted to make proactive choices about their security are bombarded with warnings, while those using apps that fail to validate certificates hear nothing. The security circus, it seems, is still playing in all three rings.

Comments (55 posted)

Security quotes of the week

— Cory Doctorow

— Bruce Schneier

Comments (none posted)

An OpenSSL advisory and the "DROWN" attack

The OpenSSL project has disclosed a new high-profile vulnerability. This one, known as CVE-2016-800, or "DROWN", affects servers that still have the old SSLv2 protocol enabled. Yes, it has its own domain name and logo. "DROWN allows attackers to break the encryption and read or steal sensitive communications, including passwords, credit card numbers, trade secrets, or financial data. Our measurements indicate 33% of all HTTPS servers are vulnerable to the attack." The solution is to just disable SSLv2 completely. Note that there are several other vulnerabilities (with a lower presumed severity) fixed in the OpenSSL 1.0.2g and 1.0.1s releases.

Comments (19 posted)

bsh: code execution

Package(s):	bsh	CVE #(s):	CVE-2016-2510
Created:	February 29, 2016	Updated:	August 1, 2016
Description:	From the Debian LTS advisory: An application that includes BeanShell on the classpath may be vulnerable if another part of the application uses Java serialization or XStream to deserialize data from an untrusted source. A vulnerable application could be exploited for remote code execution, including executing arbitrary shell commands.
Alerts:	Gentoo 201607-17 bsh 2016-07-30 openSUSE openSUSE-SU-2016:0833-1 bsh2 2016-03-19 openSUSE openSUSE-SU-2016:0788-1 bsh2 2016-03-16 SUSE SUSE-SU-2016:0699-1 bsh2 2016-03-09 SUSE SUSE-SU-2016:0700-1 bsh2 2016-03-09 Ubuntu USN-2923-1 bsh 2016-03-08 Debian DSA-3504-1 bsh 2016-03-04 Debian-LTS DLA-443-1 bsh 2016-02-29

Comments (none posted)

drupal7: multiple vulnerabilities

Package(s):	drupal7	CVE #(s):	CVE-2016-3162 CVE-2016-3163 CVE-2016-3164 CVE-2016-3165 CVE-2016-3166 CVE-2016-3167 CVE-2016-3168 CVE-2016-3169 CVE-2016-3170 CVE-2016-3171
Created:	February 29, 2016	Updated:	March 16, 2016
Description:	Multiple security vulnerabilities have been found in the Drupal content management framework. See the Drupal advisory for details. See also the oss security CVE assignments.
Alerts:	Fedora FEDORA-2016-eeb0f0c94f drupal7 2016-03-09 Fedora FEDORA-2016-45d4920315 drupal7 2016-03-09 Fedora FEDORA-2016-266406ab92 drupal6 2016-03-05 Fedora FEDORA-2016-8411497132 drupal6 2016-03-05 Mageia MGASA-2016-0087 drupal 2016-03-02 Debian DSA-3498-1 drupal7 2016-02-28

Comments (none posted)

graphite2: multiple vulnerabilities

Package(s):	graphite2	CVE #(s):	CVE-2016-1977 CVE-2016-2790 CVE-2016-2791 CVE-2016-2792 CVE-2016-2793 CVE-2016-2794 CVE-2016-2795 CVE-2016-2796 CVE-2016-2797 CVE-2016-2798 CVE-2016-2799 CVE-2016-2800 CVE-2016-2801 CVE-2016-2802
Created:	March 2, 2016	Updated:	April 5, 2016
Description:	Graphite2 1.3.6 fixes multiple vulnerabilities. See the graphite security advisory for details.
Alerts:	Gentoo 201701-63 graphite2 2017-01-24 openSUSE openSUSE-SU-2016:1767-1 thunderbird 2016-07-10 openSUSE openSUSE-SU-2016:1778-1 thunderbird 2016-07-11 openSUSE openSUSE-SU-2016:1769-1 thunderbird 2016-07-11 Gentoo 201605-06 nss 2016-05-31 Ubuntu USN-2934-1 thunderbird 2016-04-27 Ubuntu USN-2917-3 firefox 2016-04-19 Ubuntu USN-2917-2 firefox 2016-04-07 Slackware SSA:2016-095-01 thunderbird 2016-04-04 SUSE SUSE-SU-2016:0909-1 firefox, nspr, nss 2016-03-30 openSUSE openSUSE-SU-2016:0894-1 thunderbird 2016-03-26 openSUSE openSUSE-SU-2016:0876-1 thunderbird 2016-03-24 SUSE SUSE-SU-2016:0820-1 firefox 2016-03-18 Debian DSA-3523-1 iceweasel 2016-03-20 Debian DSA-3520-1 icedove 2016-03-18 Arch Linux ASA-201603-21 thunderbird 2016-03-20 Slackware SSA:2016-077-01 mozilla-firefox 2016-03-17 Scientific Linux SLSA-2016:0460-1 thunderbird 2016-03-16 Oracle ELSA-2016-0460 thunderbird 2016-03-16 Oracle ELSA-2016-0460 thunderbird 2016-03-16 Mageia MGASA-2016-0115 thunderbird 2016-03-16 CentOS CESA-2016:0460 thunderbird 2016-03-16 CentOS CESA-2016:0460 thunderbird 2016-03-16 CentOS CESA-2016:0460 thunderbird 2016-03-16 Red Hat RHSA-2016:0460-01 thunderbird 2016-03-16 SUSE SUSE-SU-2016:0777-1 firefox nspr nss 2016-03-15 Ubuntu USN-2927-1 graphite2 2016-03-14 SUSE SUSE-SU-2016:0727-1 firefox, nspr, nss 2016-03-11 openSUSE openSUSE-SU-2016:0731-1 firefox nss nspr 2016-03-12 openSUSE openSUSE-SU-2016:0733-1 Firefox 2016-03-12 Debian DSA-3515-1 graphite2 2016-03-13 Oracle ELSA-2016-0373 firefox 2016-03-09 Oracle ELSA-2016-0373 firefox 2016-03-09 Oracle ELSA-2016-0373 firefox 2016-03-09 Mageia MGASA-2016-0105 firefox 2016-03-09 Debian DSA-3510-1 iceweasel 2016-03-09 Arch Linux ASA-201603-4 firefox 2016-03-09 Ubuntu USN-2917-1 firefox 2016-03-09 Slackware SSA:2016-068-01 firefox 2016-03-08 Scientific Linux SLSA-2016:0373-1 firefox 2016-03-09 CentOS CESA-2016:0373 firefox 2016-03-09 CentOS CESA-2016:0373 firefox 2016-03-09 CentOS CESA-2016:0373 firefox 2016-03-09 Red Hat RHSA-2016:0373-01 firefox 2016-03-09 Mageia MGASA-2016-0097 graphite2 2016-03-07 Fedora FEDORA-2016-dec1faadc5 graphite2 2016-03-02

Comments (none posted)

ia32-libs: multiple vulnerabilities

Package(s):	ia32-libs	CVE #(s):
Created:	February 29, 2016	Updated:	March 2, 2016
Description:	From the Debian LTS advisory: The ia32-libs and ia32-libs-gtk packages contain 32 bit versions of various libraries for use on 64 bit systems. This update rolls in all security fixes made to these libraries since the start of Squeeze LTS.
Alerts:	Debian-LTS DLA-436-1 ia32-libs 2016-02-28

Comments (none posted)

jabberd: cryptographically insecure

Package(s):	jabberd	CVE #(s):
Created:	February 29, 2016	Updated:	March 2, 2016
Description:	From the Fedora advisory: fixes "Dialback secrets are generated using a non-cryptographically secure PRNG" See the jabberd bug report for more details.
Alerts:	Fedora FEDORA-2016-ba6fd98830 jabberd 2016-02-29

Comments (none posted)

KDE Frameworks: multiple vulnerabilities

Package(s):	KDE Frameworks	CVE #(s):
Created:	March 1, 2016	Updated:	March 2, 2016
Description:	From the openSUSE bug reports: bug 955280: session not restored after logout/login. bug 963680: Unable to create new link to application. bug 967668: KDE Frameworks 5.19.0 fixes multiple vulnerabilities.
Alerts:	openSUSE openSUSE-SU-2016:0612-1 KDE Frameworks 2016-03-01

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2015-8812 CVE-2016-2383 CVE-2016-2384 CVE-2016-0617
Created:	February 29, 2016	Updated:	March 15, 2016
Description:	From the Red Hat bugzilla: A flaw was found in the CXGB3 kernel driver when the network was considered congested. The kernel would incorrectly misinterpret the congestion as an error condition and incorrectly free/clean up the skb. When the device would then send the skb's queued, these structures would be referenced and may panic the system or allow an attacker to escalate privileges in a use-after-free scenario. (CVE-2015-8812) When ctx access is used, the kernel often needs to expand/rewrite instructions, so after that patching, branch offsets have to be adjusted for both forward and backward jumps in the new eBPF program, but for backward jumps it fails to account the delta. Meaning, for example, if the expansion happens exactly on the insn that sits at the jump target, it doesn't fix up the back jump offset. (CVE-2016-2383) A vulnerability was found in the Linux kernel. There is a possibility of double-free on 'umidi' object. The 'umidi' object will be free'd on the error path by snd_usbmidi_free() when tearing down the rawmidi interface causing the system panic. (CVE-2016-2384) A flaw was found in the Linux kernel's hugetlbfs handling of punching holes in hugetlbfs files with either truncate or fallocate. When truncating a hugetlbfs file, this bug could prevent some pages from being unmapped. If pages are not properly unmapped during truncate, the kernel bug is hit which leads the system to panic. In the fallocate hole punch case, this bug could prevent pages from being unmapped as in the truncate case also. However, for hole punch the result is that unmapped pages will not be removed during the operation. For hole punch, it is also possible that more pages than desired will be unmapped. This unnecessary unmapping will cause page faults to reestablish the mappings on subsequent page access. (CVE-2016-0617)
Alerts:	Oracle ELSA-2016-2574 kernel 2016-11-10 Red Hat RHSA-2016:2584-02 kernel-rt 2016-11-03 Red Hat RHSA-2016:2574-02 kernel 2016-11-03 openSUSE openSUSE-SU-2016:2649-1 kernel 2016-10-26 openSUSE openSUSE-SU-2016:2144-1 kernel 2016-08-24 SUSE SUSE-SU-2016:2074-1 kernel 2016-08-15 SUSE SUSE-SU-2016:1764-1 kernel 2016-07-08 Ubuntu USN-2967-2 linux-ti-omap4 2016-05-09 Ubuntu USN-2967-1 kernel 2016-05-09 SUSE SUSE-SU-2016:1203-1 kernel 2016-05-03 SUSE SUSE-SU-2016:1102-1 kernel 2016-04-19 SUSE SUSE-SU-2016:1019-1 kernel 2016-04-12 Scientific Linux SLSA-2016:2574-2 kernel 2016-12-14 Ubuntu USN-2948-2 linux-lts-utopic 2016-04-11 openSUSE openSUSE-SU-2016:1008-1 kernel 2016-04-12 Ubuntu USN-2947-3 linux-raspi2 2016-04-06 Ubuntu USN-2947-2 linux-lts-wily 2016-04-06 Ubuntu USN-2949-1 linux-lts-vivid 2016-04-06 Ubuntu USN-2948-1 linux-lts-utopic 2016-04-06 Ubuntu USN-2946-2 linux-lts-trusty 2016-04-06 Ubuntu USN-2946-1 kernel 2016-04-06 Ubuntu USN-2947-1 kernel 2016-04-06 SUSE SUSE-SU-2016:0911-1 kernel 2016-03-30 Ubuntu USN-2930-3 linux-raspi2 2016-03-16 SUSE SUSE-SU-2016:0785-1 kernel 2016-03-16 Ubuntu USN-2928-2 linux-ti-omap4 2016-03-14 Ubuntu USN-2930-2 linux-lts-wily 2016-03-14 Ubuntu USN-2932-1 linux-lts-vivid 2016-03-14 Ubuntu USN-2931-1 linux-lts-utopic 2016-03-14 Ubuntu USN-2929-2 linux-lts-trusty 2016-03-14 Ubuntu USN-2928-1 kernel 2016-03-14 Ubuntu USN-2929-1 kernel 2016-03-14 Ubuntu USN-2930-1 kernel 2016-03-14 Fedora FEDORA-2016-9fbe2c258b kernel 2016-03-05 Debian DSA-3503-1 kernel 2016-03-03 Debian-LTS DLA-439-1 linux-2.6 2016-02-29 Fedora FEDORA-2016-e7162262b0 kernel 2016-02-28 Fedora FEDORA-2016-7e12ae5359 kernel 2016-02-28

Comments (none posted)

libebml: two vulnerabilities

Package(s):	libebml	CVE #(s):	CVE-2015-8790 CVE-2015-8791
Created:	February 29, 2016	Updated:	March 2, 2016
Description:	From the CVE entries: The EbmlUnicodeString::UpdateFromUTF8 function in libEBML before 1.3.3 allows context-dependent attackers to obtain sensitive information from process heap memory via a crafted UTF-8 string, which triggers an invalid memory access. (CVE-2015-8790) The EbmlElement::ReadCodedSizeValue function in libEBML before 1.3.3 allows context-dependent attackers to obtain sensitive information from process heap memory via a crafted length value in an EBML id, which triggers an invalid memory access. (CVE-2015-8791)
Alerts:	Debian DSA-3538-1 libebml 2016-03-31 Debian-LTS DLA-438-1 libebml 2016-02-28

Comments (none posted)

libqt5-qtbase: two vulnerabilities

Package(s):	libqt5-qtbase	CVE #(s):
Created:	March 1, 2016	Updated:	March 2, 2016
Description:	From the openSUSE bug reports: 865241: Konqueror allows cipher suites with less than 128 bit encryption. 957006: when opening /dev/ folder with dolphin (as su) window opens but scroll down doesn't work.
Alerts:	openSUSE openSUSE-SU-2016:0613-1 libqt5-qtbase 2016-03-01

Comments (none posted)

okhttp: certificate pinning bypass

Package(s):	okhttp	CVE #(s):	CVE-2016-2402
Created:	March 1, 2016	Updated:	March 2, 2016
Description:	From the Red Hat bugzilla: A vulnerability was discovered in OkHttp that allows an attacker to bypass certificate pinning. OkHttp did not validate that the pinned certificate was in the chain to a trusted certificate authority.
Alerts:	Fedora FEDORA-2016-65b7608d8b okio 2016-02-29 Fedora FEDORA-2016-65b7608d8b okhttp 2016-02-29

Comments (none posted)

openssl: two vulnerabilities

Package(s):	openssl	CVE #(s):	CVE-2016-0703 CVE-2016-0704
Created:	March 2, 2016	Updated:	March 2, 2016
Description:	From the Red Hat advisory: It was discovered that the SSLv2 servers using OpenSSL accepted SSLv2 connection handshakes that indicated non-zero clear key length for non-export cipher suites. An attacker could use this flaw to decrypt recorded SSLv2 sessions with the server by using it as a decryption oracle.(CVE-2016-0703) It was discovered that the SSLv2 protocol implementation in OpenSSL did not properly implement the Bleichenbacher protection for export cipher suites. An attacker could use a SSLv2 server using OpenSSL as a Bleichenbacher oracle. (CVE-2016-0704)
Alerts:	SUSE SUSE-SU-2016:1057-1 openssl 2016-04-15 Gentoo 201603-15 openssl 2016-03-20 SUSE SUSE-SU-2016:0786-1 sles12-docker-image 2016-03-16 SUSE SUSE-SU-2016:0778-1 sles11sp4-docker-image 2016-03-15 SUSE SUSE-SU-2016:0748-1 sles12sp1-docker-image 2016-03-14 openSUSE openSUSE-SU-2016:0720-1 openssl 2016-03-11 Scientific Linux SLSA-2016:0372-1 openssl098e 2016-03-09 CentOS CESA-2016:0372 openssl098e 2016-03-09 CentOS CESA-2016:0372 openssl098e 2016-03-09 Red Hat RHSA-2016:0372-01 openssl098e 2016-03-09 SUSE SUSE-SU-2016:0678-1 OpenSSL 2016-03-07 SUSE SUSE-SU-2016:0641-1 openssl 2016-03-03 SUSE SUSE-SU-2016:0631-1 compat-openssl097g 2016-03-02 openSUSE openSUSE-SU-2016:0638-1 openssl 2016-03-02 openSUSE openSUSE-SU-2016:0637-1 openssl 2016-03-02 SUSE SUSE-SU-2016:0621-1 openssl 2016-03-01 SUSE SUSE-SU-2016:0624-1 openssl 2016-03-01 SUSE SUSE-SU-2016:0617-1 openssl 2016-03-01 SUSE SUSE-SU-2016:0620-1 openssl 2016-03-01 openSUSE openSUSE-SU-2016:0628-1 openssl 2016-03-02 Red Hat RHSA-2016:0306-01 openssl 2016-03-01 Red Hat RHSA-2016:0304-01 openssl 2016-03-01 Red Hat RHSA-2016:0303-01 openssl 2016-03-01

Comments (none posted)

openssl: multiple vulnerabilities

Package(s):	openssl	CVE #(s):	CVE-2016-0702 CVE-2016-0705 CVE-2016-0797 CVE-2016-0798 CVE-2016-0799
Created:	March 1, 2016	Updated:	March 14, 2016
Description:	From the Debian advisory: CVE-2016-0702: Yuval Yarom from the University of Adelaide and NICTA, Daniel Genkin from Technion and Tel Aviv University, and Nadia Heninger from the University of Pennsylvania discovered a side-channel attack which makes use of cache-bank conflicts on the Intel Sandy-Bridge microarchitecture. This could allow local attackers to recover RSA private keys. CVE-2016-0705: Adam Langley from Google discovered a double free bug when parsing malformed DSA private keys. This could allow remote attackers to cause a denial of service or memory corruption in applications parsing DSA private keys received from untrusted sources. CVE-2016-0797: Guido Vranken discovered an integer overflow in the BN_hex2bn and BN_dec2bn functions that can lead to a NULL pointer dereference and heap corruption. This could allow remote attackers to cause a denial of service or memory corruption in applications processing hex or dec data received from untrusted sources. CVE-2016-0798: Emilia Käsper of the OpenSSL development team discovered a memory leak in the SRP database lookup code. To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user is now disabled even if the user has configured a seed. Applications are advised to migrate to the SRP_VBASE_get1_by_user function. CVE-2016-0799: Guido Vranken discovered an integer overflow in the BIO_*printf functions that could lead to an OOB read when printing very long strings. Additionally the internal doapr_outch function can attempt to write to an arbitrary memory location in the event of a memory allocation failure. These issues will only occur on platforms where sizeof(size_t) > sizeof(int) like many 64 bit systems. This could allow remote attackers to cause a denial of service or memory corruption in applications that pass large amounts of untrusted data to the BIO_*printf functions. Additionally the EXPORT and LOW ciphers were disabled since they could be used as part of the DROWN (CVE-2016-0800) and SLOTH (CVE-2015-7575) attacks, but note that the oldstable (wheezye) and stable (jessie) distributions are not affected by those attacks since the SSLv2 protocol has already been dropped in the openssl package version 1.0.0c-2.
Alerts:	Red Hat RHSA-2016:2073-01 openssl 2016-10-18 Oracle ELSA-2016-3576 openssl 2016-06-21 openSUSE openSUSE-SU-2016:1566-1 nodejs 2016-06-14 Scientific Linux SLSA-2016:0996-1 openssl 2016-06-08 Fedora FEDORA-2016-e1234b65a2 mingw-openssl 2016-05-21 SUSE SUSE-SU-2016:1360-1 openssl 2016-05-19 openSUSE openSUSE-SU-2016:1332-1 mysql-community-server 2016-05-18 Fedora FEDORA-2016-1aaf308de4 community-mysql 2016-05-16 Fedora FEDORA-2016-7c48036d73 community-mysql 2016-05-15 SUSE SUSE-SU-2016:1290-1 openssl 2016-05-12 openSUSE openSUSE-SU-2016:1273-1 compat-openssl098 2016-05-11 Red Hat RHSA-2016:0996-01 openssl 2016-05-10 SUSE SUSE-SU-2016:1267-1 compat-openssl098 2016-05-09 Scientific Linux SLSA-2016:0722-1 openssl 2016-05-09 Oracle ELSA-2016-0722 openssl 2016-05-09 CentOS CESA-2016:0722 openssl 2016-05-09 Red Hat RHSA-2016:0722-01 openssl 2016-05-09 openSUSE openSUSE-SU-2016:1242-1 libopenssl0_9_8 2016-05-05 openSUSE openSUSE-SU-2016:1239-1 libopenssl0_9_8 2016-05-05 openSUSE openSUSE-SU-2016:1241-1 libopenssl0_9_8 2016-05-05 SUSE SUSE-SU-2016:1057-1 openssl 2016-04-15 Gentoo 201603-15 openssl 2016-03-20 SUSE SUSE-SU-2016:0786-1 sles12-docker-image 2016-03-16 SUSE SUSE-SU-2016:0778-1 sles11sp4-docker-image 2016-03-15 SUSE SUSE-SU-2016:0748-1 sles12sp1-docker-image 2016-03-14 Fedora FEDORA-2016-e6807b3394 openssl 2016-03-13 openSUSE openSUSE-SU-2016:0720-1 openssl 2016-03-11 SUSE SUSE-SU-2016:0678-1 OpenSSL 2016-03-07 Arch Linux ASA-201603-2 openssl 2016-03-07 Arch Linux ASA-201603-3 lib32-openssl 2016-03-07 Fedora FEDORA-2016-2802690366 openssl 2016-03-03 SUSE SUSE-SU-2016:0641-1 openssl 2016-03-03 SUSE SUSE-SU-2016:0631-1 compat-openssl097g 2016-03-02 Slackware SSA:2016-062-02 openssl 2016-03-02 openSUSE openSUSE-SU-2016:0638-1 openssl 2016-03-02 openSUSE openSUSE-SU-2016:0637-1 openssl 2016-03-02 openSUSE openSUSE-SU-2016:0640-1 libopenssl0_9_8 2016-03-03 Mageia MGASA-2016-0093 openssl 2016-03-02 SUSE SUSE-SU-2016:0621-1 openssl 2016-03-01 SUSE SUSE-SU-2016:0624-1 openssl 2016-03-01 SUSE SUSE-SU-2016:0617-1 openssl 2016-03-01 SUSE SUSE-SU-2016:0620-1 openssl 2016-03-01 Scientific Linux SLSA-2016:0302-1 openssl 2016-03-01 Scientific Linux SLSA-2016:0301-1 openssl 2016-03-01 Oracle ELSA-2016-0302 openssl 2016-03-01 Oracle ELSA-2016-0301 openssl 2016-03-01 Oracle ELSA-2016-0301 openssl 2016-03-01 openSUSE openSUSE-SU-2016:0627-1 openssl 2016-03-02 openSUSE openSUSE-SU-2016:0628-1 openssl 2016-03-02 CentOS CESA-2016:0302 openssl 2016-03-01 CentOS CESA-2016:0301 openssl 2016-03-01 Red Hat RHSA-2016:0302-01 openssl 2016-03-01 Red Hat RHSA-2016:0301-01 openssl 2016-03-01 Ubuntu USN-2914-1 openssl 2016-03-01 CentOS CESA-2016:0301 openssl 2016-03-01 Debian DSA-3500-1 openssl 2016-03-01

Comments (none posted)

openssl: cross-protocol attack

Package(s):	openssl	CVE #(s):	CVE-2016-0800
Created:	March 1, 2016	Updated:	March 2, 2016
Description:	From the OpenSSL advisory: A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites as a Bleichenbacher RSA padding oracle. Note that traffic between clients and non-vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server. This vulnerability is known as DROWN.
Alerts:	openSUSE openSUSE-SU-2016:1239-1 libopenssl0_9_8 2016-05-05 openSUSE openSUSE-SU-2016:1241-1 libopenssl0_9_8 2016-05-05 SUSE SUSE-SU-2016:1057-1 openssl 2016-04-15 Gentoo 201603-15 openssl 2016-03-20 SUSE SUSE-SU-2016:0786-1 sles12-docker-image 2016-03-16 SUSE SUSE-SU-2016:0778-1 sles11sp4-docker-image 2016-03-15 SUSE SUSE-SU-2016:0748-1 sles12sp1-docker-image 2016-03-14 openSUSE openSUSE-SU-2016:0720-1 openssl 2016-03-11 Scientific Linux SLSA-2016:0372-1 openssl098e 2016-03-09 CentOS CESA-2016:0372 openssl098e 2016-03-09 CentOS CESA-2016:0372 openssl098e 2016-03-09 Red Hat RHSA-2016:0372-01 openssl098e 2016-03-09 SUSE SUSE-SU-2016:0678-1 OpenSSL 2016-03-07 Arch Linux ASA-201603-2 openssl 2016-03-07 Arch Linux ASA-201603-3 lib32-openssl 2016-03-07 SUSE SUSE-SU-2016:0641-1 openssl 2016-03-03 SUSE SUSE-SU-2016:0631-1 compat-openssl097g 2016-03-02 Slackware SSA:2016-062-02 openssl 2016-03-02 openSUSE openSUSE-SU-2016:0638-1 openssl 2016-03-02 openSUSE openSUSE-SU-2016:0637-1 openssl 2016-03-02 openSUSE openSUSE-SU-2016:0640-1 libopenssl0_9_8 2016-03-03 Mageia MGASA-2016-0093 openssl 2016-03-02 SUSE SUSE-SU-2016:0621-1 openssl 2016-03-01 SUSE SUSE-SU-2016:0624-1 openssl 2016-03-01 SUSE SUSE-SU-2016:0617-1 openssl 2016-03-01 SUSE SUSE-SU-2016:0620-1 openssl 2016-03-01 Scientific Linux SLSA-2016:0302-1 openssl 2016-03-01 Scientific Linux SLSA-2016:0301-1 openssl 2016-03-01 openSUSE openSUSE-SU-2016:0627-1 openssl 2016-03-02 openSUSE openSUSE-SU-2016:0628-1 openssl 2016-03-02 CentOS CESA-2016:0302 openssl 2016-03-01 CentOS CESA-2016:0301 openssl 2016-03-01 Red Hat RHSA-2016:0306-01 openssl 2016-03-01 Red Hat RHSA-2016:0305-01 openssl 2016-03-01 Red Hat RHSA-2016:0304-01 openssl 2016-03-01 Red Hat RHSA-2016:0303-01 openssl 2016-03-01 Red Hat RHSA-2016:0302-01 openssl 2016-03-01 Red Hat RHSA-2016:0301-01 openssl 2016-03-01 CentOS CESA-2016:0301 openssl 2016-03-01

Comments (none posted)

openstack-glance: authorization bypass

Package(s):	openstack-glance	CVE #(s):	CVE-2016-0757
Created:	February 29, 2016	Updated:	March 7, 2016
Description:	From the Red Hat advisory: An authorization vulnerability in OpenStack Image service was discovered, which allowed image-status manipulation using locations. By removing the last location of an image, an authenticated user could change the status from 'active' to 'queue'. A malicious tenant could exploit this flaw to silently replace owned image data, regardless of its original creator or visibility settings. Only environments with show_multiple_locations set to true (not default) were affected.
Alerts:	Red Hat RHSA-2016:0358-01 openstack-glance 2016-03-07 Red Hat RHSA-2016:0352-01 openstack-glance 2016-03-03 Red Hat RHSA-2016:0354-01 openstack-glance 2016-03-03 Red Hat RHSA-2016:0309-01 openstack-glance 2016-02-29

Comments (none posted)

pcre3: code execution

Package(s):	pcre3	CVE #(s):	CVE-2016-3191
Created:	February 29, 2016	Updated:	August 12, 2016
Description:	From the pcre bug report: PCRE does not validate that handling the (*ACCEPT) verb will occur within the bounds of the cworkspace stack buffer, leading to a stack buffer overflow.
Alerts:	openSUSE openSUSE-SU-2016:2805-1 pcre 2016-11-15 Red Hat RHSA-2016:1132-01 rh-mariadb100-mariadb 2016-05-26 Mageia MGASA-2016-0204 pcre 2016-05-24 Oracle ELSA-2016-1025 pcre 2016-05-11 Scientific Linux SLSA-2016:1025-1 pcre 2016-05-11 Red Hat RHSA-2016:1025-01 pcre 2016-05-11 openSUSE openSUSE-SU-2016:3099-1 pcre 2016-12-12 Ubuntu USN-2943-1 pcre3 2016-03-29 Debian-LTS DLA-441-1 pcre3 2016-02-29

Comments (none posted)

pcre: denial of service

Package(s):	pcre	CVE #(s):	CVE-2016-1283
Created:	March 2, 2016	Updated:	June 21, 2016
Description:	From the CVE entry: The pcre_compile2 function in pcre_compile.c in PCRE 8.38 mishandles the /((?:F?+(?:^(?(R)a+\"){99}-))(?J)(?'R'(?'R'<((?'RR'(?'R'\){97)?J)?J)(?'R'(?'R'\){99|(:(?|(?'R')(\k'R')|((?'R')))H'R'R)(H'R))))))/ pattern and related patterns with named subgroups, which allows remote attackers to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror.
Alerts:	openSUSE openSUSE-SU-2016:2805-1 pcre 2016-11-15 Gentoo 201607-02 libpcre 2016-07-09 Slackware SSA:2016-172-02 pcre 2016-06-20 Red Hat RHSA-2016:1132-01 rh-mariadb100-mariadb 2016-05-26 Mageia MGASA-2016-0204 pcre 2016-05-24 openSUSE openSUSE-SU-2016:3099-1 pcre 2016-12-12 Ubuntu USN-2943-1 pcre3 2016-03-29 Fedora FEDORA-2016-f5af8e27ce pcre 2016-03-16 Arch Linux ASA-201603-18 pcre 2016-03-13 Fedora FEDORA-2016-65833b5dbc pcre 2016-03-02

Comments (none posted)

perl: ambiguous environment

Package(s):	perl	CVE #(s):	CVE-2016-2381
Created:	March 1, 2016	Updated:	March 14, 2016
Description:	From the Debian advisory: Stephane Chazelas discovered a bug in the environment handling in Perl. Perl provides a Perl-space hash variable, %ENV, in which environment variables can be looked up. If a variable appears twice in envp, only the last value would appear in %ENV, but getenv would return the first. Perl's taint security mechanism would be applied to the value in %ENV, but not to the other rest of the environment. This could result in an ambiguous environment causing environment variables to be propagated to subprocesses, despite the protections supposedly offered by taint checking.
Alerts:	openSUSE openSUSE-SU-2016:2313-1 perl 2016-09-15 Gentoo 201701-75 perl 2017-01-30 openSUSE openSUSE-SU-2016:0881-1 perl 2016-03-24 Fedora FEDORA-2016-1fb63e3bf3 perl 2016-03-13 Arch Linux ASA-201603-9 perl 2016-03-10 Mageia MGASA-2016-0099 perl 2016-03-07 Fedora FEDORA-2016-5d4fc5ecc9 perl 2016-03-03 Ubuntu USN-2916-1 perl 2016-03-02 Debian DSA-3501-1 perl 2016-03-01

Comments (none posted)

pillow: code execution

Package(s):	pillow	CVE #(s):	CVE-2016-2533
Created:	February 29, 2016	Updated:	March 2, 2016
Description:	From the Red Hat bugzilla: A heap-based buffer overflow flaw was reported in Pillow's PCD decoding. By tricking an unsuspecting user or automated script into processing a specially crafted PCD image file, an attacker could cause the Python process to crash, or, potentially, execute arbitrary code with the privileges of the Python script processing the image. The problem is that the "ImagingPcdDecode()" function in PcdDecode.c increases a the unpack buffer pointer by 4 bytes (=32bit color), although the buffer is only supposed to hold 24bits of color (=3 bytes). This ultimately leads to an array indexing error resulting in an out-of-bounds write.
Alerts:	Ubuntu USN-3090-2 pillow 2016-09-30 Ubuntu USN-3090-1 Pillow 2016-09-27 Ubuntu USN-3080-1 python-imaging 2016-09-15 Gentoo 201612-52 pillow 2016-12-31 Debian DSA-3499-1 pillow 2016-02-28

Comments (none posted)

pixman: code execution

Package(s):	pixman	CVE #(s):	CVE-2014-9766
Created:	February 25, 2016	Updated:	March 23, 2016
Description:	From the Debian LTS advisory: It was discovered that there was a buffer overflow in pixman, a pixel-manipulation library for X and cairo.
Alerts:	Debian DSA-3525-1 pixman 2016-03-22 Ubuntu USN-2918-1 pixman 2016-03-03 Debian-LTS DLA-429-1 pixman 2016-02-24

Comments (none posted)

python-django: two vulnerabilities

Package(s):	python-django	CVE #(s):	CVE-2016-2512 CVE-2016-2513
Created:	March 2, 2016	Updated:	April 8, 2016
Description:	From the Ubuntu advisory: Mark Striemer discovered that Django incorrectly handled user-supplied redirect URLs containing basic authentication credentials. A remote attacker could possibly use this issue to perform a cross-site scripting attack or a malicious redirect. (CVE-2016-2512) Sjoerd Job Postmus discovered that Django incorrectly handled timing when doing password hashing operations. A remote attacker could possibly use this issue to perform user enumeration. (CVE-2016-2513)
Alerts:	Debian DSA-3544-1 python-django 2016-04-07 Red Hat RHSA-2016:0502-01 python-django 2016-03-24 Red Hat RHSA-2016:0506-01 python-django 2016-03-24 Red Hat RHSA-2016:0505-01 python-django 2016-03-24 Red Hat RHSA-2016:0504-01 python-django 2016-03-24 Red Hat RHSA-2016:0503-01 python-django 2016-03-24 Fedora FEDORA-2016-b004d6d8f7 python-django 2016-03-17 Fedora FEDORA-2016-11183ea08d python-django 2016-03-17 Ubuntu USN-2915-3 python-django 2016-03-07 Ubuntu USN-2915-2 python-django 2016-03-07 Mageia MGASA-2016-0096 python-django 2016-03-07 Ubuntu USN-2915-1 python-django 2016-03-01

Comments (none posted)

squid: denial of service

Package(s):	squid3	CVE #(s):	CVE-2016-2569 CVE-2016-2571
Created:	March 1, 2016	Updated:	November 11, 2016
Description:	From the CVE entries: CVE-2016-2569: Squid 3.x before 3.5.15 and 4.x before 4.0.7 does not properly append data to String objects, which allows remote servers to cause a denial of service (assertion failure and daemon exit) via a long string, as demonstrated by a crafted HTTP Vary header. CVE-2016-2571: http.cc in Squid 3.x before 3.5.15 and 4.x before 4.0.7 proceeds with the storage of certain data after a response-parsing failure, which allows remote HTTP servers to cause a denial of service (assertion failure and daemon exit) via a malformed response.
Alerts:	Oracle ELSA-2016-2600 squid 2016-11-10 Red Hat RHSA-2016:2600-02 squid 2016-11-03 SUSE SUSE-SU-2016:2089-1 squid3 2016-08-16 openSUSE openSUSE-SU-2016:2081-1 squid 2016-08-16 SUSE SUSE-SU-2016:1996-1 squid3 2016-08-09 Fedora FEDORA-2016-b3b9407940 squid 2016-07-13 Gentoo 201607-01 squid 2016-07-09 Fedora FEDORA-2016-7b40eb9e29 squid 2016-05-06 Fedora FEDORA-2016-7b40eb9e29 libecap 2016-05-06 Scientific Linux SLSA-2016:2600-2 squid 2016-12-14 Debian DSA-3522-1 squid3 2016-03-20 Ubuntu USN-2921-1 squid3 2016-03-07 Mageia MGASA-2016-0095 squid 2016-03-07 Debian-LTS DLA-445-2 squid3 2016-03-03 Debian-LTS DLA-445-1 squid3 2016-02-29

Comments (none posted)

tomcat: multiple vulnerabilities

Package(s):	tomcat	CVE #(s):	CVE-2015-5174 CVE-2015-5345 CVE-2015-5351 CVE-2016-0706 CVE-2016-0714 CVE-2016-0763
Created:	February 29, 2016	Updated:	November 11, 2016
Description:	From the CVE entries: Directory traversal vulnerability in RequestUtil.java in Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.65, and 8.x before 8.0.27 allows remote authenticated users to bypass intended SecurityManager restrictions and list a parent directory via a /.. (slash dot dot) in a pathname used by a web application in a getResource, getResourceAsStream, or getResourcePaths call, as demonstrated by the $CATALINA_BASE/webapps directory. (CVE-2015-5174) The Mapper component in Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.67, 8.x before 8.0.30, and 9.x before 9.0.0.M2 processes redirects before considering security constraints and Filters, which allows remote attackers to determine the existence of a directory via a URL that lacks a trailing / (slash) character. (CVE-2015-5345) The (1) Manager and (2) Host Manager applications in Apache Tomcat 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M2 establish sessions and send CSRF tokens for arbitrary new requests, which allows remote attackers to bypass a CSRF protection mechanism by using a token. (CVE-2015-5351) Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M2 does not place org.apache.catalina.manager.StatusManagerServlet on the org/apache/catalina/core/RestrictedServlets.properties list, which allows remote authenticated users to bypass intended SecurityManager restrictions and read arbitrary HTTP requests, and consequently discover session ID values, via a crafted web application. (CVE-2016-0706) The session-persistence implementation in Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M2 mishandles session attributes, which allows remote authenticated users to bypass intended SecurityManager restrictions and execute arbitrary code in a privileged context via a web application that places a crafted object in a session. (CVE-2016-0714) The setGlobalContext method in org/apache/naming/factory/ResourceLinkFactory.java in Apache Tomcat 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M3 does not consider whether ResourceLinkFactory.setGlobalContext callers are authorized, which allows remote authenticated users to bypass intended SecurityManager restrictions and read or write to arbitrary application data, or cause a denial of service (application disruption), via a web application that sets a crafted global context. (CVE-2016-0763)
Alerts:	Oracle ELSA-2016-2599 tomcat 2016-11-10 Red Hat RHSA-2016:2599-02 tomcat 2016-11-03 Scientific Linux SLSA-2016:2045-1 tomcat6 2016-10-11 CentOS CESA-2016:2045 tomcat6 2016-10-11 Oracle ELSA-2016-2045 tomcat6 2016-10-10 Red Hat RHSA-2016:2045-01 tomcat6 2016-10-10 Ubuntu USN-3024-1 tomcat6, tomcat7 2016-07-05 Debian DSA-3609-1 tomcat8 2016-06-29 Debian DSA-3552-1 tomcat7 2016-04-17 Scientific Linux SLSA-2016:2599-2 tomcat 2016-12-14 Fedora FEDORA-2016-e6651efbaf tomcat 2016-03-25 Debian DSA-3530-1 tomcat6 2016-03-25 openSUSE openSUSE-SU-2016:0865-1 tomcat 2016-03-23 SUSE SUSE-SU-2016:0839-1 tomcat6 2016-03-21 SUSE SUSE-SU-2016:0822-1 tomcat 2016-03-18 SUSE SUSE-SU-2016:0769-1 tomcat 2016-03-15 Mageia MGASA-2016-0090 tomcat 2016-03-02 Debian-LTS DLA-435-1 tomcat6 2016-02-27

Comments (none posted)

vlc: multiple vulnerabilities

Package(s):	vlc	CVE #(s):
Created:	February 29, 2016	Updated:	March 2, 2016
Description:	From the Mageia advisory: The vlc package has been updated to version 2.2.2, which fixes several bugs and possible security issues. See the NEWS file for details.
Alerts:	Mageia MGASA-2016-0083 vlc 2016-02-26

Comments (none posted)

xen: denial of service

Package(s):	xen	CVE #(s):	CVE-2016-2270 CVE-2016-2271
Created:	February 29, 2016	Updated:	March 7, 2016
Description:	From the CVE entries: Xen 4.6.x and earlier allows local guest administrators to cause a denial of service (host reboot) via vectors related to multiple mappings of MMIO pages with different cachability settings. (CVE-2016-2270) VMX in Xen 4.6.x and earlier, when using an Intel or Cyrix CPU, allows local HVM guest users to cause a denial of service (guest crash) via vectors related to a non-canonical RIP. (CVE-2016-2271)
Alerts:	SUSE SUSE-SU-2016:1745-1 xen 2016-07-06 SUSE SUSE-SU-2016:1445-1 Xen 2016-05-30 SUSE SUSE-SU-2016:1318-1 xen 2016-05-17 Debian-LTS DLA-479-1 xen 2016-05-18 SUSE SUSE-SU-2016:1154-1 xen 2016-04-26 openSUSE openSUSE-SU-2016:0995-1 xen 2016-04-08 SUSE SUSE-SU-2016:0955-1 xen 2016-04-05 Gentoo 201604-03 xen 2016-04-05 SUSE SUSE-SU-2016:0873-1 xen 2016-03-24 Debian DSA-3519-1 xen 2016-03-17 Mageia MGASA-2016-0098 xen 2016-03-07 Fedora FEDORA-2016-f8121efdac xen 2016-03-06 Fedora FEDORA-2016-e48f4bd14f xen 2016-02-26

Comments (none posted)

xerces-c: code execution

Package(s):	xerces-c	CVE #(s):	CVE-2016-0729
Created:	February 26, 2016	Updated:	April 18, 2016
Description:	From the Debian-LTS advisory: Gustavo Grieco discovered that xerces-c, a validating XML parser library for C++, mishandles certain kinds of malformed input documents, resulting in buffer overflows during processing and error reporting. These flaws could lead to a denial of service in applications using the xerces-c library, or potentially, to the execution of arbitrary code.
Alerts:	openSUSE openSUSE-SU-2016:1808-1 xerces-c 2016-07-15 Fedora FEDORA-2016-7615febbd6 mingw-xerces-c 2016-07-06 Fedora FEDORA-2016-87e8468465 mingw-xerces-c 2016-07-06 Fedora FEDORA-2016-0a061f6dd9 mingw-xerces-c 2016-07-05 Gentoo 201612-46 xerces-c 2016-12-24 openSUSE openSUSE-SU-2016:1121-1 xerces-c 2016-04-21 Fedora FEDORA-2016-880b91c090 xerces-c 2016-04-18 Fedora FEDORA-2016-ae9ac16cf3 xerces-c 2016-04-13 openSUSE openSUSE-SU-2016:0966-1 xerces-c 2016-04-07 CentOS CESA-2016:0430 xerces-c 2016-03-10 Oracle ELSA-2016-0430 xerces-c 2016-03-10 Scientific Linux SLSA-2016:0430-1 xerces-c 2016-03-10 Red Hat RHSA-2016:0430-01 xerces-c 2016-03-10 Mageia MGASA-2016-0088 xerces-c 2016-03-02 Debian DSA-3493-1 xerces-c 2016-02-25 Debian-LTS DLA-433-1 xerces-c 2016-02-25

Comments (none posted)

xymon: multiple vulnerabilities

Package(s):	xymon	CVE #(s):	CVE-2016-2054 CVE-2016-2055 CVE-2016-2056 CVE-2016-2057 CVE-2016-2058
Created:	February 29, 2016	Updated:	May 26, 2016
Description:	From the Debian advisory: CVE-2016-2054: The incorrect handling of user-supplied input in the "config" command can trigger a stack-based buffer overflow, resulting in denial of service (via application crash) or remote code execution. CVE-2016-2055: The incorrect handling of user-supplied input in the "config" command can lead to an information leak by serving sensitive configuration files to a remote user. CVE-2016-2056: The commands handling password management do not properly validate user-supplied input, and are thus vulnerable to shell command injection by a remote user. CVE-2016-2057: Incorrect permissions on an internal queuing system allow a user with a local account on the xymon master server to bypass all network-based access control lists, and thus inject messages directly into xymon. CVE-2016-2058: Incorrect escaping of user-supplied input in status webpages can be used to trigger reflected cross-site scripting attacks.
Alerts:	Debian-LTS DLA-488-1 xymon 2016-05-25 Mageia MGASA-2016-0177 xymon 2016-05-18 Debian DSA-3495-1 xymon 2016-02-29

Comments (none posted)

Kernel release status

The current development kernel is 4.5-rc6, released on February 28. Linus said: "I'd like to say that things are on track for the usual release timing, but let's see how things look next week. If rc7 hasn't started to shrink, I may end up deciding that this is one of the releases when we do an rc8 too. Too early to tell. There's nothing particularly scary going on, but I'd have liked it even calmer this week."

Stable updates: 4.4.3, 3.14.62, and 3.10.98 were released on February 26.

The 4.4.4 (342 changes), 3.14.63 (130 changes), and 3.10.99 (80 changes) updates are in the review process as of this writing; they can be expected on or after March 3. With these kernels, Greg Kroah-Hartman says, the queue of patches waiting to go into stable updates has finally been emptied.

Comments (none posted)

Welte: Report from the VMware GPL court hearing

On his blog, Harald Welte has a report on a hearing in Germany regarding VMware's alleged GPL violations. Welte is a former kernel developer as well as the founder of gpl-violations.org, so he has quite an interest in the case, which was brought by Christoph Hellwig and is being funded by the Software Freedom Conservancy. To Welte's eye, it seems that there are two questions at issue: whether vmklinux and vmkernel are considered to be one or separate works (in a copyright sense) and whether Hellwig has the standing to sue: "This situation is used by the VMware defense in claiming that overall, they could only find very few functions that could be attributed to Christoph, and that this may altogether be only 1% of the Linux code they use in VMware ESXi. The court recognized this as difficult, as in German copyright law there is the concept of fading. If the original work by one author has been edited to an extent that it is barely recognizable, his original work has faded and so have his rights. The court did not state whether it believed that this has happened. To the contrary, the indicated that it may very well be that only very few lines of code can actually make a significant impact on the work as a whole. However, it is problematic for them to decide, as they don't understand source code and software development. So if (after further briefs from both sides and deliberation of the court) this is still an open question, it might very well be the case that the court would request a [technical] expert report to clarify this to the court."

Comments (34 posted)

The persistent memory "I know what I'm doing" flag

As was described in Neil Brown's article last week, developers working on persistent memory appear to be converging on a solution for the fsync() system call. A working fsync() will enable applications to ensure that the data they have written is safely stored to persistent memory; importantly, applications that have been written correctly for POSIX filesystems in general will work correctly on persistent memory without the need to be aware of the difference. But some developers want to write code that is specific to persistent memory as a way of maximizing performance. A patch catering to the needs of those developers inspired a lengthy conversation on how to best ensure that data written to persistent memory is not lost, and how development in this area should proceed in general.

The problem with the emerging fsync() solution, according to Boaz Harrosh, is that it requires the kernel to maintain a radix tree of all pages that might have dirty lines of data in the CPU caches. If an application has been written with persistent memory in mind, though, it can avoid leaving data in the caches. That data can be explicitly flushed by the application or, as an alternative, non-temporal writes can be used to bypass the CPU caches entirely. If the application is using these techniques, Boaz said, there is no need for the kernel to flush cache lines for the relevant persistent memory, so it can avoid the wasted overhead of maintaining the radix tree.

The kernel currently has no way of knowing that an application is taking care of its own cache-management needs, though. Fixing that is the goal of this patch set posted by Boaz in February. It adds a new flag for the mmap() system call named MAP_PMEM_AWARE. If an application maps a file stored in persistent memory with this flag, and the filesystem supports the DAX direct-access mechanism, the kernel can assume that the application will deal with cache management and, as a result, the kernel need not track pages with potentially dirty cache lines. Boaz claims considerably improved performance when running with this patch.

Some concerns

It is fair to say that this patch was not universally acclaimed. There were a number of objections to providing this kind of functionality, the first of which being that an application that does its own cache management will still have to make calls to fsync() (or msync()) to ensure that its data is truly persistent. That is because this data does not stand alone; it is stored within a filesystem, and the application has no knowledge of whether there is any filesystem metadata that must also be flushed out to be sure that the data can be accessed. The only way to be sure that the metadata is consistent on disk is to call fsync(), just like applications dealing with data on more traditional storage media.

In theory, an application can allocate and write an entire file, then call fsync() to get it all to persistent storage with the goal that, afterward, it can rewrite the data within the file without causing any further metadata changes (other than timestamps, which are not important for retrieving that data). But filesystems can be performing actions like data deduplication, delayed allocation, or, as Christoph Hellwig pointed out, copy-on-write operations. So it is true that the only way to be sure that data is truly, safely persistent is to call fsync(); the MAP_PMEM_AWARE flag would not eliminate that requirement.

Boaz protested that eliminating the need to call fsync() was never the purpose of the patch set. Instead, it aims to make those calls much faster; other overhead, especially associated with page faults in areas backed by persistent memory, would also be significantly reduced. Unfortunately, the worries about MAP_PMEM_AWARE didn't end there.

For example, consider the interaction between applications using this flag and others that are not aware of persistent memory. Such applications (which might be something as simple as mv or a backup utility) may also create metadata changes needing flushing, and they may create dirty cache lines in the persistent-memory area that the "aware" application knows nothing about. Experience with direct I/O has shown that such interactions can be subtle, difficult to notice, and impossible to fix.

Perhaps the biggest worry, though, is that application developers will rush out and proclaim that their code is "aware" without actually understanding everything they need to do to guarantee the integrity of their data. As Dave Chinner put it: "Almost any app developer that says they understand how filesystems provide data integrity is almost always completely wrong." If the kernel provides these developers with an "I know what I'm doing" flag, the reasoning goes, they will soon write code that demonstrates the lack of that knowledge — to their users' detriment.

One might just say that any such applications are buggy; they will either be fixed or replaced with something better. But, as Dave continued, he made it clear that he didn't see things happening that way.

That last point is key: filesystem developers, in their own defense, will end up ignoring this new flag because the alternative is to face the wrath of users who blame them for their lost data. The ext4 data-loss wars in 2009 have left some lasting scars; filesystem developers do not wish to find themselves in that position again.

Data integrity first

Developers had one more reason to oppose this patch — one that had little to do with the specifics of the patch itself. DAX and its associated persistent-memory functionality are still new, and problems are still being found with them. Dave made the claim that the core problem of safely storing data via DAX has not yet been solved, so it is not appropriate to be looking at optimizations. For now, the focus has to be on making things reliable; after that, there will be time to look at where the performance issues lie and do some optimization work.

Failure to solve the correctness issues first, he said, will just lead to more problems as more features are added. He drew a parallel with Btrfs which, he said, didn't solve the "known hard problems" early and, as a result, is stuck with "entrenched deficiencies" that are nearly impossible to fix. If those known hard problems are not solved first with DAX, it may well end up in the same situation.

He would also like to see optimization work focused on the general case, instead of on providing opt-out mechanisms for a few programs. Fixing performance issues rather than bypassing them will provide benefits for everybody, a better outcome than just enabling a few applications to implement their own optimized solutions. If, instead, those applications opt out, they will not benefit from core-code improvements and, consequently, those improvements will be less likely to happen.

Pushing back on and delaying work that kernel developers would like to see merged is never a pleasant experience. That work was done for a reason; rejecting it often means that at least some of that work was done in vain, and hard feelings can often result. But experience has shown that resisting work that seems premature or not consistent with long-term goals leads to a better, more maintainable kernel in the long run. The DAX infrastructure is going to have to serve as an important kernel-supported approach to persistent memory for a long time; the community cannot afford to get this one wrong. So there may well be a solid case to be made for conservatism in this area for now.

Comments (6 posted)

Airplane mode and rfkill

The closest that many get to the kernel's rfkill subsystem is when they press a button on their laptop (e.g. WiFi off, airplane mode) to save power, board a plane, or reduce interruptions. The plumbing to link that key press to a light that goes off, or maybe on, should be fairly straightforward but, as some recent patches show, there is still room for improvement. To understand the nature of these improvements, a little introduction to rfkill will be helpful.

The rfkill subsystem supports the creation of rfkill devices. When a driver registers a device capable of transmitting RF (e.g. WiFi or Bluetooth adapters), it will also register an rfkill device associated with the transmitter. Each such device will have an index number, a name such as "eeepc-wlan" or "phy1", and two state flags: "hard blocked" (RFKILL_STATE_HARD_BLOCKED) is read-only and is expected to reflect some physical disablement while "soft blocked" (RFKILL_STATE_SOFT_BLOCKED) is read/write and can be used to enable or disable transmission.

Each device also has a type (RFKILL_TYPE_*) from the list WLAN, BLUETOOTH, UWB (ultra-wideband), WIMAX, WWAN (wireless WAN), GPS, FM, and NFC. GPS is an interesting addition to the list as GPS transmitters are rare. GPS receivers do have powered antenna and powering these down is sometimes appropriate; that could be seen as fitting the role of rfkill.

For linking with an input key, the rfkill subsystem registers an input handler that is automatically attached to any input device that can report one of the keys KEY_WLAN, KEY_BLUETOOTH, KEY_UWB, KEY_WIMAX, or KEY_RFKILL — or one that can report a change to the SW_RFKILL_ALL switch. The distinction between a key and a switch is that a key reports an "off" event when released, while a switch has two equally stable states. The key events toggle an internal rfkill state and cause all rfkill devices of the relevant type to be either blocked or unblocked, where KEY_RFKILL applies to all types. The switch is a little more heavy-handed as will be described later.

On the output side, each rfkill device registers an LED trigger that can be assigned to any LED that Linux controls. This assignment can be effected with a kernel driver, by using device tree (the "linux,default-trigger" attribute), or by writing to /sys/class/leds/$LED/trigger. There are usually a large number of triggers available, from simple states like "none" and "default-on" to the more complex "BAT0-charging-blink-full-solid" that might be registered by a battery controller. The "rfkillNN" trigger (where "NN" is the index number of the relevant rfkill) turns the LED on if transmission is not blocked, and off if it is either hard- or soft-blocked. This makes it suitable for an LED marked with a transmitter symbol, but not so suitable for one marked with an airplane: in that case one would expect the light to be on when transmission is blocked, rather than off.

This is where the patches from João Paulo Rechi Vita come in. Rechi Vita is putting together support for some new ASUS laptops and wanted to enable the LED next to the airplane symbol. To support this he created a new LED trigger called "rfkill-airplane-mode" that causes any associated LED to light up when in airplane mode. This might seem simple enough, but first you need to be sure you have a clear understanding of what airplane mode means, and agreement on whether the kernel should even know about such a thing.

To see what it could mean in the context of the rfkill subsystem, it is important to understand that there are some more soft-block flags beyond the one per device. The flags exist at three different levels. At the top level is a global flag. When it is toggled using the KEY_RFKILL key or set using, for example, "rfkill block all", all of the flags at all levels are set to match the new value of the global flag. The middle level has one flag for each type of rfkill device; one for WLAN, one for BLUETOOTH, etc. When these are toggled using a relevant key or set with a command like "rfkill unblock bluetooth", the soft flag for all devices of that type is set to match the new value of the per-type flag. The third level is the per-device soft-blocked flags that we have already met. When these are set, the corresponding per-type flag and the global flag are left unchanged, so the settings can become inconsistent. It is quite possible for a specific WLAN device to be unblocked while both the global setting and the mid-level WLAN setting are blocked. This could be achieved with commands like:

    # rfkill block all
    # rfkill block wlan
    # rfkill unblock phy0

That understanding is enough to fill in the blanks concerning the SW_RFKILL_ALL switch. When that switch is activated all of the soft-block flags, per-device, per-type, and global, are set to "blocked" after first saving a copy of the per-type and global flags. While the switch is active none of the toggle keys will work, though settings can still be changed using the rfkill command-line tool. When the switch is deactivated, the toggle keys are re-enabled and the various flags can either be left unchanged, restored to their previous setting, or forced on, depending on the "master_switch_mode" module parameter.

Since both the SW_RFKILL_ALL switch and the KEY_RFKILL key affect the global blocked flag, it makes some sense for that value to drive the airplane-mode LED. Had Rechi Vita created a trigger called "rfkill-all-inverted" that might have been the end of the story. The proposed "rfkill-airplane-mode" raised questions though. Marcel Holtmann wondered if the concept of airplane mode had any place in the kernel at all, since it is really a regulatory concept rather than a technical concept, and it is subject to change with place and time. Another concern, which seemed to be implied but never quite stated, was that, since transmitters can be turned back on individually without changing the global blocked status, it wasn't clear that the global soft-blocked status meant anything more than "the next toggle will turn everything back on", which is rather indirect.

It was generally felt that these concerns were more theoretical than practical and didn't need much attention. Providing that a user-space daemon could implement a more nuanced behavior if it chose, the simple answer is probably the best. A user-space daemon can always take complete control of any LED by simply setting the trigger to "none" and controlling the brightness directly, but Rechi Vita provided something a little better. With his latest patches, a daemon can take control of the airplane-mode setting and set it explicitly the way it wants. It is fairly easy to receive notifications of changes to rfkill devices, so any policy for the LED that can be imagined can be implemented. Having this option removes the need for the daemon to discover which LED it needs to control, and means that if the daemon dies the behavior will revert to the default, which may not be perfect behavior, but isn't that bad.

It is not immediately clear that these benefits justify giving the kernel a concept of airplane mode — even a user-modifiable one. Restarting daemons that die is a solved problem, so that aspect provides no real benefit. Not needing to discover the appropriated LED is more interesting. If a daemon wanted to discover input keys and switches that relate to RF transmission, there are a well-defined set of event names that can be searched for — you could probably even script something using evtest.

Discovering LEDs is not so easy. All that can be used is the names of the LEDs and, while these are supposed to be of the form "devicename:color:function", there is no standard list of functions. The mac80211 module uses "radio" for a function name, while the ASUS platform driver defines "asus::wlan". The Intel iwl driver defines LEDs with names like "phy0-led" which doesn't match the pattern at all. Rechi Vita has a separate patch that creates an LED called "asus-wireless::airplane_mode", which is pleasingly unambiguous, but only really helpful if other developers follow this lead. Teaching the kernel about airplane mode might not be the most elegant response to this lack of standardization, but it should work; Linux is nothing if not pragmatic.

Once these patches land, we will be a little closer to being able to have a light that comes on in airplane mode. Only two steps remain on my notebook: getting events when the airplane-mode key is pressed, and being able to control the airplane-mode LED. This functionality is often controlled through ACPI; the details seem to vary unpredictably from model to model. Whether Rechi Vita's other patches will help on a model which is a full six months old is an open question.

Comments (3 posted)

Coverage-guided kernel fuzzing with syzkaller

If your software deals with untrusted user input, it's a good idea to run a fuzzer against the program. For the Linux kernel, the most effective fuzzer of recent years has been Dave Jones's Trinity system call tester. But there's a new system call fuzzer in town, Dmitry Vyukov's syzkaller, and early results from it look promising — over 150 bugs uncovered in the mainline kernel (plus several dozen in Google's internal kernels) in a few months of operation.

Fuzzing in user space

The basic idea of fuzzing — feeding huge numbers of random inputs into a program and watching for crashes — has been around for a long time, but a naive implementation that just blindly emits random data is too inefficient to find all but the most shallow bugs. One technique for finding deeper bugs is to use a "template-based" fuzzer, which generates input variations from built-in knowledge about the possible/valid patterns (i.e. templates) for the program under test — information that needs to be manually created for each particular target (or class of targets).

However, more recently, "coverage-guided" fuzzers have appeared, notably Michał Zalewski's american fuzzy lop (which LWN covered back in September) and Clang's LibFuzzer, which operate without target-specific templates. Instead, these fuzzers work with an instrumented build of the binary under test, so that code coverage information is exposed. The fuzzer tries to maximize the amount of code covered (building an ever-expanding corpus of test inputs along the way), by mutating existing inputs and saving anything that hits new code.

As well as detecting out-and-out crashes, fuzzers also work well in combination with tools that expose latent bugs, such as Clang's sanitizers — compiler options that add instrumentation to the generated code so that incorrect behavior generates an error at run-time:

• AddressSanitizer (ASAN), which detects memory access errors.
• ThreadSanitizer (TSAN), which detects data races between different threads.
• MemorySanitizer (MSAN), which detects uninitialized reads: code whose behavior relies on memory contents that have not been initialized to a specific value.
• UndefinedBehaviorSanitizer (UBSAN), which detects the use of various features of C/C++ that are explicitly listed as resulting in undefined behavior.

(Most, but not all, of the sanitizers have been ported from Clang to GCC; however, it remains the case that the most useful tools appear first, or even exclusively, for Clang/LLVM — another reason to hope for the complete success of the LLVMLinux project.)

Fuzzing the kernel

The Linux kernel is certainly a piece of software that is exposed to untrusted user input, so it is an important target for fuzzing. The kernel is also sufficiently high-profile that it has been worth writing specific, template-based fuzzers for different areas of it, such as the filesystem or the perf_event subsystem. For the system call interface in general, the Trinity fuzz tester is the main tool that is currently used. It fuzzes the kernel in an intelligent way that is driven by per-system call templates.

In recent months, Vyukov and a team from Google have brought coverage-guided fuzz testing to the kernel with syzkaller, which uses a hybrid approach. As with Trinity, syzkaller relies on templates that indicate the argument domains for each system call, but it also uses feedback from code coverage information to guide the fuzzing.

The need for instrumentation does make syzkaller more complicated to set up than Trinity. To start with, the compiler option to generate the needed coverage data has only recently been added to GCC (as -fsanitize-coverage=trace-pc), so the kernel needs to be built with a fresh-from-tip version of GCC.

It is worth noting that Jones has considered feedback-guided fuzzing for Trinity in the past, but found the coverage tools that were available at the time to be too slow. The Google team behind syzkaller is primarily made up of compiler developers rather than kernel developers, so they may have an easier job of upgrading the tools to match the task in hand.

Another complication is that the coverage data needs to be tracked on a per-task basis and exported from the kernel to the outside world (via a debugfs entry at /sys/kernel/debug/kcov). The kernel patch to do this, and to invoke the relevant compiler options (all under CONFIG_KCOV), is currently under discussion but looks likely to be merged soon.

As mentioned above, the most effective bug-hunting occurs when the system call fuzzing is combined with tools that make latent bugs more visible. The kernel version of AddressSanitizer, KASAN, is the most straightforward of the sanitizers to enable (it is already included in the kernel as the CONFIG_KASAN build option), and it's also helpful to turn on various kernel debug features that expose incorrect use of internal kernel APIs, such as:

• CONFIG_PROVE_LOCKING to catch potential deadlocks.
• CONFIG_PROVE_RCU to catch potential bugs in RCU-using code.
• CONFIG_DEBUG_ATOMIC_SLEEP to find code that calls potentially-sleeping functions in an atomic section.

Using these options means that errors get emitted for bugs that might otherwise pass unnoticed ninety-nine times out of a hundred (but which are correspondingly harder to find and fix on the hundredth roll of the dice).

With these preliminaries in place, syzkaller can then be run over a set of QEMU virtual machines running the instrumented kernel under test. The structure of the various syzkaller processes is described by the diagram below, which was taken from the project's documentation (and where red text indicates configuration entries).

The results

To see the results of syzkaller in action, we attempt to reproduce a null-dereference bug in System V shared-memory processing that was first reported in October 2015. We speed up the process by narrowing the range of system calls tested to just those mentioned in that email thread, via the enable_syscalls parameter in syzkaller's configuration file. We also make sure our test kernel is built with full namespace support; this allows the fuzzer to run its tests in individual sandboxes that do not interfere with each other (using the dropprivs configuration flag). This is particularly useful when dealing with an interprocess resource like shared memory.

While the fuzzer is running, it provides a minimal web server to allow the user to see progress. The main status page displays fuzzing statistics and a list of the tested system calls; each of the latter provides links to further pages:

• A corpus page showing the sequences of system calls that have been run that include the given system call. For example, the page for remap_file_pages() might include "shmget-shmat-remap_file_pages" as a summary of particular sequence of system calls that has been run by the fuzzer.
• A coverage page that shows which parts of the kernel source code were hit (provided that the kernel was configured with CONFIG_DEBUG_INFO and addr2line is in the PATH), either during the processing of a specific corpus input or during all corpus inputs that include the given system call.
• A priority page that shows the biases used when randomly generating other system calls to run in combination with the given system call. These priorities are partly based on compatible argument types (for example, syzkaller is more likely to combine two system calls that both take socket file descriptor arguments), and partly based on the frequency with which particular pairs of system calls appear in the current corpus (indicating that the pair has been effective in hitting new code in the past).

After running for a while, syzkaller generates a report file that includes a kernel oops; this file includes a log of the sequences of system calls that were being run, together with the log output for a null pointer dereference. Feeding the main fault address from the oops output into the addr2line tool reveals that the problem is in shm_lock(), which is being called from shm_open() as part of processing a remap_file_pages() system call.

However, we still have to narrow down the precise sequence that causes the problem, as the report file includes 204 distinct sequences of system calls. The syz-repro tool helps with this process; starting from the configuration file and the crash report file, it first narrows down to the particular sequence that triggers the crash — usually one of the few immediately preceding the log output. Next, it repeatedly attempts to minimize that particular sequence of system calls, by generating simpler versions of the sequence and checking that they still induce a crash.

In our example, after a few iterations of syz-repro, a fairly short sequence of system calls pops out:

    mmap(&(0x7f0000000000)=nil, (0x2000), 0x3, 0x32, \
         0xffffffffffffffff, 0x0)
    r0 = shmget(0x5, (0x2000), 0x200, &(0x7f0000b03000)=nil)
    shmat(r0, &(0x7f0000b03000)=nil, 0x6000)
    shmctl(r0, 0x3, &(0x7f0000000000+0xe4b)={ \
           0x3, <r1=>0xffffffffffffffff, 0x0, 0xffffffffffffffff, \
	   0xffffffffffffffff, 0x1, 0xfa, 0x3, 0xee, 0x10000, 0x6520, \
	   0x5, 0xffffffffffffffff, 0x0, 0x0})
    shmctl(r0, 0xe, &(0x7f0000000000+0x28f)={ \
           0x1000, <r2=>0xffffffffffffffff, \
	   <r3=>0xffffffffffffffff, 0x0, <r4=>0x0, 0x7, \
	   0x100000000, 0x5, 0x6, 0x0, 0x2, 0x4, <r5=>0x0, \
	   0xffffffffffffffff, 0xef0})
    shmctl(r0, 0xc, &(0x7f0000002000-0x50)={ \
           0x80, r1, r4, r2, r3, 0x7, 0x10000, 0x5, 0xff, 0x80000000, \
	   0x9, 0x3, r5, 0xffffffffffffffff, 0x2})
    shmctl(r0, 0x0, &(0x7f0000001000-0x50)={ \
           0x1, 0x0, 0x0, 0xffffffffffffffff, 0x0, 0x1, 0x5, 0x5059, \
	   0x3, 0x6301, 0x8001, 0xfffffffffffffffd, 0xffffffffffffffff, \
           0x0, 0x6})
    remap_file_pages(&(0x7f0000b03000)=nil, (0x2000), 0x0, 0x7, \
                     0x21dd964cfba54855)

To confirm that this is a reproducible bug scenario, we feed this system call script into syzkaller's syz-prog2c utility, which generates a 100-line program that reproduces the problem on the test kernel.

At this point, a bit of human intervention helps to reduce the size of the program further. Looking at the shmctl() invocations, we notice that the first two calls are for IPC_INFO and SHM_INFO, both of which read values from the kernel rather than modifying anything. Next, we might also suspect that SHM_UNLOCK is a no-op, as nothing has been locked. After removing those calls and their data setup, we are left with an extremely short program that does indeed reproduce our null dereference (at least for now — a fix is on its way):

    #include <unistd.h>
    #include <sys/syscall.h>
    #include <string.h>
    
    long r[5];
    
    int main()
    {
    	memset(r, -1, sizeof(r));
    	r[0] = syscall(SYS_mmap, 0x20000000ul, 0x2000ul, 0x3ul, 0x32ul,
	               0xfffffffffffffffful, 0x0ul);
    	r[1] = syscall(SYS_shmget, 0x5ul, 0x2000ul, 0x200ul, 0x20b03000ul, 0, 0);
    	r[2] = syscall(SYS_shmat, r[1], 0x20b03000ul, 0x6000ul, 0, 0, 0);
    	r[3] = syscall(SYS_shmctl, r[1], 0x0ul, 0x20000fb0ul, 0, 0, 0);
    	r[4] = syscall(SYS_remap_file_pages, 0x20b03000ul, 0x2000ul,
	               0x0ul, 0x7ul, 0x21dd964cfba54855ul, 0);
    	return 0;
    }

Unfortunately, not all problems are as straightforward to reproduce and isolate as this one. Bugs may only be triggered by interactions between multiple test programs (when the procs configuration option is greater than one) if persistent or global resources are involved. More commonly, bugs may only be triggered by interactions between different threads in the same program; the fuzzing process deliberately executes system calls in parallel across multiple threads — which increases the chances of finding bugs at the cost of making it harder to narrow down the reproduction scenario. (Building the kernel with KTSAN enabled is particularly helpful for finding multithreaded problems, as it makes latent data races explicitly visible.)

To help with reproduction, syzkaller includes a tool (syz-execprog) for re-running a crash script under various options. The -threaded option governs whether the system call script is run across multiple threads, and (if it is) the -collide option forces the threads to explicitly execute system calls in parallel. To catch heisenbugs, the -repeat option also allows the script to be re-run arbitrarily many times.

Although these tools don't guarantee a simple reproduction scenario, they seem to be effective in practice — the majority of the syzkaller-generated bug reports have included a short reproducer program, greatly simplifying the process of finding and fixing the underlying bug. The corpus of test inputs can be a helpful resource for quick regression testing of new kernel versions.

What's next

The syzkaller project is under active development, so things are moving fast. As mentioned above, the necessary patches for GCC have gone upstream and should appear in the next version; the concomitant kernel patch is being discussed. Once both are available by default, running syzkaller will only be slightly more inconvenient than running Trinity.

Because syzkaller is a hybrid of a template-based and a coverage-guided fuzzer, it does work best when provided with information about the usage patterns of system calls. To that end, the syzkaller developers are keen to work with kernel developers so that support for particular kernel subsystems can be reviewed and extended (which may well involve making the system call template mechanisms more sophisticated). They would also like to extend architecture support beyond the current somewhat x86_64-specific situation, and would like to further automate the process of extracting a reproducer program (and minimizing the size of that program).

But overall, syzkaller appears to be a worthy addition to the battery of kernel test tools, and its successes reinforce the idea that fuzzing should be considered a best practice for any software project that takes user input.

Comments (8 posted)

Solus: focusing on desktop Linux

The often-predicted (if only in jest) year of the Linux desktop has long since been written off as an illusion by much of our community. But it seems that predictions of the death of the Linux desktop (or of desktop computing in general) are also somewhat premature; developers continue to work on desktop environments and users remain interested in that work. The Solus Project produces a strongly desktop-focused distribution; the March 2 release of Solus 1.1 Shannon provides a good opportunity to look at what this group has been up to.

Many new distributions start with an existing project and extend it; Solus has not chosen to take that path. Instead, it is a new distribution built from the beginning with, naturally, its own package-management system and package format. As the "Why Solus?" page asserts: "We don’t need to patch or work around the work of others, we deliver one well designed unit to our end users." This work is focused exclusively on the desktop experience, with no interest in catering to other use cases; "if you’re thinking about running a Solus server, forget about it."

Running Solus

The project's download page offers a single ISO image for x86-64 systems; other architectures are not supported. Users with UEFI secure boot enabled will also discover that the Solus developers have not included secure boot support; it must be disabled before the installation image can run. Once that is done, the result is a fairly typical live system running directly from the installation media, with the option to install (via a typical, multi-step process) onto a local drive.

Solus is based on GNOME 3 components, so it's not surprising that the resulting system looks and feels a lot like a normal GNOME 3 desktop, with some obvious tweaks. Initially the user gets an empty screen, with the usual dark panel at the top. The Solus developers have moved away from the GNOME Shell, though, replacing it with a system called Budgie. The first thing a GNOME user is likely to notice is that Budgie dispenses with the active upper-left corner used by GNOME Shell; those of us who find the active corner to be, even after years, a daily inspiration for loud profanity, will not miss it.

Clicking on the circular icon found at the left end of the panel results in a hierarchical application menu with a search bar. Finding applications is easy enough; clicking on an application will always result in a new window appearing. Budgie does not retain GNOME Shell's (also profanity-inspiring) practice of taking the user to a random, existing window if the selected application is already running. The application menu remembers recent choices, so, once the user has found out how to get a terminal, that option is readily at hand. There does not appear to be a way to explicitly wire "favorite" applications into the top-level menu.

The applications themselves are mostly what one would expect from a GNOME-based system: gnome-terminal, Firefox, Thunderbird, RhythmBox, etc. VLC is installed as well; the Solus project makes a point of installing the necessary codecs to play popular media formats, apparently without the worries that can keep such software out of other distributions. There is a settings application that looks suspiciously like the GNOME equivalent, but with the icons replaced.

Software is managed through a separate application, which can also look for and install updates. The number of packages is somewhat limited, apparently by the choice of the Solus developers. Their stated intent is to produce a focused distribution where all of the pieces work together rather than supporting the largest possible list of packages. The software shipped in the 1.1 release is current as of this writing (4.4.3 kernel, for example). There is no build number as part of the package version numbers; that suggests that, once a given package is built, no new builds for that particular version will be done. Among other things, that implies that backporting of fixes is not done.

Clicking on the right end of the panel will produce a dropdown menu in typical GNOME fashion, but the Solus developers have made some changes here as well, calling the result "Raven." The calendar has moved into this window; there are also audio controls and the ability to tweak the desktop's theme or add a small set of applets to the panel. A separate tab in this window contains a list of recent notifications.

Budgie supports multiple workspaces, but does not seem to emphasize them; one has to dig to find the "workspace switcher" applet deep within the Raven window. There is no obvious way to move windows between workspaces.

Security

Anybody contemplating using a Linux distribution is well advised to look hard at its security practices. Unless a system is never connected to the net, it will be exposed to threats, and it will turn out to have vulnerabilities. Distributions that are not managed with security in mind will end up leaving their users vulnerable, sooner or later.

The available evidence suggests that Solus is not, at this point, as serious about security as one would like. The project has announced that it is signing its releases — but that practice only started in late February. Better late than never, but it would have been better yet if they had thought of this some time ago.

If there is any sort of mechanism for the signing of individual Solus packages (and verifying those signatures), it is not mentioned anywhere in the documentation.

The Solus project does not issue security advisories, so there is no way to know which vulnerabilities exist in the distribution or whether they have been fixed. Like rolling-release distributions, Solus seems to depend on the practice of installing just-released software as a way of patching vulnerabilities. The project does seem to be good at staying on that leading edge; the 4.4.3 kernel, for example, only came out five days before the Solus 1.1 release, and the distribution has the DROWN-proof OpenSSL 1.0.2g release, which was one day old at the time of the Solus release.

But throwing new packages into the repository is an incomplete security policy at best. If the distribution's developers are not tracking vulnerabilities in the software they ship, they have no way of knowing how secure their distribution is. Users will have even less of an idea, of course. One might argue that Solus is young and still trying to find its feet, and that argument is not without merit. But, if the Solus developers are serious about providing a top-quality Linux desktop experience, they are going to need to make security an explicit part of their strategy.

To summarize, what Solus seems to offer is a new attempt at creating a distribution with an exclusive focus on the needs of desktop users. Much work has been done to pare the distribution down to what the developers think those users need and to make it work as well as possible. The result is indeed a nice desktop distribution, even if its relative lack of maturity shows through in places. One can only wish the Solus developers luck as they seek to revitalize the development of desktop Linux.

Comments (2 posted)

Distribution quotes of the week

-- Rich Freeman

-- Andrew S. Tanenbaum

Comments (2 posted)

Calamares 2.0 is out

The Calamares team has announced the release of Calamares 2.0, a major release that brings many new features and improvements over the 1.1 series. "Calamares is a distribution-independent system installer, with an advanced partitioning feature for both manual and automated partitioning operations. It is the first installer with an automated “Replace Partition” option, which makes it easy to reuse a partition over and over for distribution testing. Calamares is designed to be customizable by distribution maintainers without need for cumbersome patching, thanks to third party branding and external modules support."

Comments (none posted)

Debian 6 Squeeze has reached end-of-life

The Debian Long Term Support (LTS) team has announced that Debian 6 ("Squeeze") support has reached its end-of-life on February 29, 2016, five years after its initial release on February 6, 2011. "The LTS Team will prepare the transition to Debian 7 ("wheezy"), which is the current oldstable release. The LTS team will take over support from the Security Team on April 26, 2016." Wheezy will be supported by the LTS team until May 31, 2018.

Full Story (comments: none)

Xenial Xerus Beta 1

The first beta of Ubuntu 16.04 ("Xenial Xerus") is available for Lubuntu, Ubuntu Cloud, Ubuntu GNOME, Ubuntu MATE, UbuntuKylin, Ubuntu Studio and Xubuntu. "While these Beta 1 images have been tested and work, except as noted in the release notes, Ubuntu developers are continuing to improve Xenial Xerus. In particular, once newer daily images are available, system installation bugs identified in the Beta 1 installer should be verified against the current daily image before being reported in Launchpad."

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 650 (February 29)
• Five Things in Fedora (February 26)
• Linux Mint Monthly News (February)
• openSUSE Tumbleweed Review of the week 2016/8 (February 26)
• Ubuntu Weekly Newsletter, Issue 456 (February 28)

Comments (none posted)

Fedora project leader Matthew Miller reveals what's in store for Fedora in 2016 (PCWorld)

PCWorld talks with Matthew Miller about where Fedora is heading in the near future. "Fedora wants to start converting people who aren’t already Linux users over to the platform. This doesn’t mean targeting the average desktop user—Fedora Workstation is still focused on being a developer-targeted environment. But “developers are people too,” says Miller. Developers want to play games on their laptops and have a polished desktop experience, just like anyone else. So Fedora is still working on that stuff."

Comments (none posted)

RebeccaBlackOS Is a Class Act (LinuxInsider)

LinuxInsider takes a look at RebeccaBlackOS. "RebeccaBlackOS offers a sampling of Wayland and several new desktop shells to run on it. One of them is the 5 Hawaii Desktop. Weston so far is being touted as the default desktop shell for Wayland. This is the reference implementation of Wayland compositor written by Wayland developers. A few separate teams of developers are working toward a compilation of releases running Wayland and its related Weston compositor. One such plan is by a developer who goes by the handle "Nerdopolis." He is the brains behind RBOS. His distro attempts to showcase Wayland running several desktop environments that load by selection when you log in to Wayland's display manager."

Comments (none posted)

OpenStack and "open core"

The "open core" model, where certain features are reserved for an "enterprise edition" that is not open source, is not particularly popular with a large segment of the open-source community. There are certainly businesses that rely on the practice, but the ideas behind open core run counter to the ethos of open source in many ways. The OpenStack community has recently grappled with the definition of open core, which is explicitly disallowed as part of the project's principles (the "Four Opens"). It is not a simple question, as there are clearly gray areas, some of which came up in the discussion.

In early February, OpenStack technical committee (TC) chair Thierry Carrez posted a question to the project's development mailing list: what does "no open core" mean in 2016? The policy was adopted in 2010, when Rackspace was the sole owner of OpenStack, in order to differentiate it from Eucalyptus, which was another open-source cloud platform that was pursuing the open-core strategy. It was meant to send "strong signals that we would never follow such a strategy", which was "essential to form a real community".

But things are far different today, Carrez continued; there is a non-profit foundation at the helm, but there are also components that are proprietary and closed source being sold by member companies in their "enterprise editions". There are "drivers that expose functionality in proprietary components". (That situation led Bradley Kuhn to recently state that he knows of no OpenStack distributions that do not have at least some proprietary pieces.) Those pieces are clearly not a part of the OpenStack project, but how does that all mesh with "no open core"? He gave his view:

As he and others noted, the definitions of "fully-functional" and "production-grade" are somewhat unclear, but Carrez thought his take might make a reasonable starting point. While he didn't mention it specifically in that post, it became clear in the thread that there is at least one project that may fall outside of those boundaries. Poppy, which is not an official part of OpenStack but is part of the wider ecosystem, provides an interface to content delivery networks (CDNs) so that OpenStack installations can offer CDN-as-a-service. The problem is that there are no viable open-source CDN implementations, which means that it requires "proprietary software or a commercial entity" to use—or even to test.

Interoperating with commercial services is not typically seen as adding open-core functionality, exactly. As TC member Doug Hellmann put it:

There is a moribund open-source CDN in the OpenCDN project, but a CDN is far more than just code. Ryan Brown pointed that out: "Open source projects aren't usually set up around making big capital expenditures and buying lots of bandwidth, so the lack of a FOSS CDN isn't exactly Poppy's fault." But even if there were an open-source CDN, and Poppy supported it, would that be sufficient? TC member Flavio Percoco raised that question:

There was some talk of having Poppy provide some kind of "reference" open-source CDN, but that is not really something that the Poppy project wants to take on. There is no existing project to use, but there is more to it than that, as Poppy project member Amit Gandhi noted:

But OpenStack projects need to be able to be tested using the umbrella project's infrastructure. That will become problematic without an open-source CDN, as OpenStack Foundation cross-project developer coordinator Mike Perez explained:

But Hellmann doesn't see Poppy as being all that much different from other OpenStack pieces:

But without some support for an open-source option, Sean M. Collins argued, Poppy doesn't really fit into the OpenStack project:

Carrez circled back to the more general question of defining open core for OpenStack on February 22. He considered some alternate wordings from his original post, but worried that those left the door open to real open-core services in OpenStack. In the end, he suggested that perhaps it was best left up to the TC to decide what open core means on a case-by-case basis. That idea seems to have won the day—no real opposition to it was heard.

Meanwhile, the Poppy question came up at the TC meeting on February 23 (log). While some were not convinced that Poppy was open core in the true sense of that term, it was still not accepted into the OpenStack project. In a close vote, seven of the thirteen members felt that it still didn't meet the requirements to be included. It can still be hosted using OpenStack infrastructure, but will not be an official part of OpenStack.

That situation may change, especially if Poppy comes up with a way to be tested and tried without requiring proprietary services. It seems clear that the project is not intended to sell any additional OpenStack components—which is a major part of the objections to open core—but it still doesn't quite live up to the "open" in OpenStack.

Comments (7 posted)

Quotes of the week

— Matthew Garrett sees the light.

— Joey Hess on writing documentation before code.

Comments (none posted)

OpenSSH 7.2 is available

OpenSSH 7.2 has been released. While this update is primarily a bugfix release, it also disables, by default, several algorithms in the ssh client. The disabled ciphers include "blowfish-cbc, cast128-cbc, all arcfour variants and the rijndael-cbc aliases for AES", while the disabled hash algorithms include all MD5-based and truncated HMAC algorithms. The algorithms in question were already disabled in sshd in an earlier release. The announcement also notes that a "near future" release will refuse all RSA keys smaller than 1024 bits.

Full Story (comments: none)

Buildroot 2016.02 released

Version 2016.02 of the Buildroot build-automation toolkit has been released. The update adds support for GCC 5.3.x, configuration support for several new boards, and support for MIPS Codescape toolchains. Notably, this release also drops support for legacy uClibc, in favor of uClibc-ng.

Full Story (comments: none)

Development newsletters from the past week

• What's cooking in git.git (February 25)
• What's cooking in git.git (February 26)
• What's cooking in git.git (March 2)
• LLVM Weekly (February 29)
• OCaml Weekly News (March 1)
• OpenStack Developer Digest (February 26)
• Perl Weekly (February 29)
• PostgreSQL Weekly News (February 28)
• Python Weekly (February 25)
• Ruby Weekly (February 25)
• This Week in Rust (February 29)
• Wikimedia Tech News (February 29)

Comments (none posted)

Lord: The case for an embeddable Gecko

At his blog, Chris Lord advocates for developing Mozilla's Gecko web renderer into an embeddable engine—something that Mozilla has long resisted. He lists a long series of disruptive technologies (starting with the original iPhone in 2007) that have made use of open-source embedded web runtimes—all of which, of course, went with a project other than Gecko and, thus, represent missed opportunities. "It’s hard to predict what the next technology trend will be, but there’s is a strong likelihood it’ll involve the web, and there’s a possibility it may not come from a company/group/individual with an existing web rendering engine or particular allegiance." In conclusion, he argues, "if we want to form the basis of the next big thing, it’s not enough to be experimenting in new areas. We need to enable other people to experiment in new areas using our technology."

Comments (none posted)

Malcolm: GCC 6: -Wmisleading-indentation vs “goto fail;”

David Malcolm takes a look at a new compiler warning in GCC 6, -Wmisleading-indentation. "At a high level, the underlying implementation looks at control statements (if/else, while, for), and if it sees them guard a single statement without braces, it looks at the followup statement. It complains if both have the same indentation. That’s a simplified description – we spent a fair amount of time working on heuristics in the warning, to try to ensure that it warns for all cases that are reasonable to warn for, whilst not complaining unduly for indentation that’s merely bad (rather than being actively misleading). We’ve also tested it with a variety of coding styles: GNU, K&R, Linux kernel, etc."

Comments (177 posted)

Raspberry Pi 3 is out

The Raspberry Pi 3 has been released and is on sale now for $35. "For Raspberry Pi 3, Broadcom have supported us with a new SoC, BCM2837. This retains the same basic architecture as its predecessors BCM2835 and BCM2836, so all those projects and tutorials which rely on the precise details of the Raspberry Pi hardware will continue to work. The 900MHz 32-bit quad-core ARM Cortex-A7 CPU complex has been replaced by a custom-hardened 1.2GHz 64-bit quad-core ARM Cortex-A53. Combining a 33% increase in clock speed with various architectural enhancements, this provides a 50-60% increase in performance in 32-bit mode versus Raspberry Pi 2, or roughly a factor of ten over the original Raspberry Pi." (Thanks to Forrest Cook)

Comments (51 posted)

NetDev 1.1 slides now available

Slides from the talks at NetDev are available. Videos should be available soon.

Full Story (comments: none)

Free Software Supporter -- Issue 95, March 2016

This edition of the Free Software Foundation's monthly newsletter covers LibrePlanet, FSF's winter fundraiser, Licensing and Compliance Lab interviews Michael Zahniser, Defective By Design comments to the U.S. Copyright Office, Encryption: probably better than a box of chocolates, I Love Free Software Day 2016, and several other topics.

Full Story (comments: none)

FSFE Newsletter - March 2016

The Free Software Foundation Europe's monthly newsletter covers "I love Free Software" Day 2016, "No cloud" went viral, European Free Software Policy Meeting 2016, and more.

Full Story (comments: none)

Garrett: I bought some awful light bulbs so you don't have to

Matthew Garrett digs into a Linux-running light bulb and is not impressed with what he finds. "The OS detection reported Linux, which wasn't hugely surprising - there was no GPL notice or source code included with the box, but I'm way past the point of shock at that. It also reported that there was a telnet daemon running. I connected and got a login prompt. And then I typed admin as the username and admin as the password and got a root prompt. So, there's that."

Comments (77 posted)

The Linux Foundation Partners with Women Who Code (Linux.com)

Linux.com reports that the Linux Foundation has partnered with Women Who Code (WWC) to provide free and discounted passes to Linux Foundation events for WWC members. "Women Who Code was created in 2011 and is best known for its weekly publication the CODE Review and free technical study groups, hack nights, career development, and speaking events featuring influential technology industry experts and investors. Their focus on education aligns with our goal to increase access to Linux and open source learning materials, helping to grow the Linux and open source talent pool, increases diversity in technology and provides the pathway to the most lucrative jobs in IT."

Comments (none posted)

SFC: GPL Violations Related to Combining ZFS and Linux

The Software Freedom Conservancy (SFC) has put out an analysis of the recently announced plans of Canonical to provide and support ZFS as part of Ubuntu 16.04. There are some license-compatibility questions within the community, but Canonical believes that it is within its rights to distribute the CDDLv1-licensed zfs.ko kernel module with the GPLv2-licensed kernel. SFC, however, disagrees: "We are sympathetic to Canonical's frustration in this desire to easily support more features for their users. However, as set out below, we have concluded that their distribution of zfs.ko violates the GPL. We have written this statement to answer, from the point of view of many key Linux copyright holders, the community questions that we've seen on this matter. Specifically, we provide our detailed analysis of the incompatibility between CDDLv1 and GPLv2 — and its potential impact on the trajectory of free software development — below. However, our conclusion is simple: Conservancy and the Linux copyright holders in the GPL Compliance Project for Linux Developers believe that distribution of ZFS binaries is a GPL violation and infringes Linux's copyright. We are also concerned that it may infringe Oracle's copyrights in ZFS. As such, we again ask Oracle to respect community norms against license proliferation and simply relicense its copyrights in ZFS under a GPLv2-compatible license."

Comments (75 posted)

SFLC: The Linux Kernel, CDDL and Related Issues

The Software Freedom Law Center weighs in on the ZFS controversy with a long and somewhat academic posting. The TL;DR is that it depends on what the kernel developers want. "No existing record conclusively or convincingly demonstrates whether the only relevant licensing community, the holders of kernel copyright, intends a literal or equitable interpretation of its license terms under present circumstances. As so often in the long history of our law, both literal and equitable postures of interpretation are completely tenable, and reasonable people in the relevant roles may justifiably disagree. The matter is smaller than that which divided the Pharisees from the Saducees, but from a legal theory point of view it is of the same fundamental kind."

Comments (54 posted)

SciPy 2016: call for papers

SciPy 2016, the 15th annual Scientific Computing with Python conference, will be held July 11-17 in Austin, Texas. The deadline for tutorial proposals is March 21. Talks and posters may be proposed until March 25. Early-bird registration is open until May 22.

Full Story (comments: none)

CFP Deadlines: March 3, 2016 to May 2, 2016

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

Deadline	Event Dates	Event	Location
March 6	July 17 July 24	EuroPython 2016	Bilbao, Spain
March 9	June 1 June 2	Apache MesosCon	Denver, CO, USA
March 10	May 14 May 15	Open Source Conference Albania	Tirana, Albania
March 12	April 26	Open Source Day 2016	Warsaw, Poland
March 15	April 28 May 1	Mini-DebCamp & DebConf	Vienna, Austria
March 20	April 28 April 30	Linuxwochen Wien 2016	Vienna, Austria
March 25	July 11 July 17	SciPy 2016	Austin, TX, USA
April 1	May 26	NLUUG - Spring conference 2016	Bunnik, The Netherlands
April 2	May 2 May 3	PyCon Israel 2016	Tel Aviv, Israel
April 7	April 8 April 10	mini Linux Audio Conference 2016	Berlin, Germany
April 8	August 2 August 5	Flock to Fedora	Krakow, Poland
April 15	June 27 July 1	12th Netfilter Workshop	Amsterdam, Netherlands
April 15	June 22 June 26	openSUSE Conference 2016	Nürnberg, Germany
April 24	August 20 August 21	Conference for Open Source Coders, Users and Promoters	Taipei, Taiwan
April 26	August 22 August 24	LinuxCon NA	Toronto, Canada
April 27	August 12 August 14	GNOME Users and Developers European Conference	Karlsruhe, Germany
April 30	June 11	TÜBIX 2016	Tübingen, Germany
April 30	October 27 October 28	Rust Belt Rust	Pittsburgh, PA, USA
April 30	August 25 August 26	The Prometheus conference	Berlin, Germany
May 1	August 24 August 26	KVM Forum 2016	Toronto, Canada

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

Events: March 3, 2016 to May 2, 2016

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

Date(s)	Event	Location
March 1 March 6	Internet Freedom Festival	Valencia, Spain
March 8 March 10	Fluent 2016	San Francisco, CA, USA
March 9 March 11	18th German Perl Workshop	Nürnberg, Germany
March 10 March 12	Studencki Festiwal Informatyczny (Students' Computer Science Festival)	Cracow, Poland
March 11 March 13	PyCon SK 2016	Bratislava, Slovakia
March 11 March 13	Zimowisko Linuksowe TLUG	Puck, Poland
March 14 March 17	Open Networking Summit	Santa Clara, CA, USA
March 14 March 18	CeBIT 2016 Open Source Forum	Hannover, Germany
March 16 March 17	Great Wide Open	Atlanta, GA, USA
March 18 March 20	FOSSASIA 2016 Singapore	Singapore, Singapore
March 19 March 20	LibrePlanet	Boston, MA, USA
March 19 March 20	Chemnitzer Linux Tage 2016	Chemnitz, Germany
March 23	Make Open Source Software 2016	Bucharest, Romania
March 29 March 31	Collaboration Summit	Lake Tahoe, CA, USA
April 1	DevOps Italia	Bologna, Italy
April 4 April 8	OpenFabrics Alliance Workshop	Monterey, CA, USA
April 4 April 6	Web Audio Conference	Atlanta, GA, USA
April 4 April 6	Embedded Linux Conference	San Diego, CA, USA
April 4 April 6	OpenIoT Summit	San Diego, CA, USA
April 5 April 7	Lustre User Group 2016	Portland, OR, USA
April 6	PostgreSQL and PostGIS, Session #8	Lyon, France
April 7 April 8	SRECon16	Santa Clara, CA, USA
April 8 April 10	mini Linux Audio Conference 2016	Berlin, Germany
April 9 April 10	OSS Weekend	Bratislava, Slovakia
April 11 April 13	O’Reilly Software Architecture Conference	New York, NY, USA
April 15 April 17	PyCon Italia Sette	Firenze, Italia
April 15 April 17	Akademy-es 2016	Madrid, Spain
April 15 April 18	Libre Graphics Meeting	London, UK
April 16	15. Augsburger Linux Info Tag	Augsburg, Germany
April 18 April 19	Linux Storage, Filesystem & Memory Management Summit	Raleigh, NC, USA
April 18 April 20	PostgreSQL Conference US 2016	New York, NY, USA
April 20 April 21	Vault 2016	Raleigh, NC, USA
April 21 April 24	GNOME.Asia Summit	Delhi, India
April 23	DevCrowd 2016	Szczecin, Poland
April 23 April 24	LinuxFest Northwest	Bellingham, WA, USA
April 25 April 27	Cuba International Free Software Conference	Havana, Cuba
April 25 April 29	OpenStack Summit	Austin, TX, USA
April 26	Open Source Day 2016	Warsaw, Poland
April 26 April 28	Open Source Data Center Conference	Berlin, Germany
April 28 April 30	Linuxwochen Wien 2016	Vienna, Austria
April 28 May 1	Mini-DebCamp & DebConf	Vienna, Austria
April 30	Linux Presentation Day 2016.1	many cities, Germany
May 1 June 29	Open Source Innovation Spring	Paris, France

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