The scarcity of college graduates with FOSS experience

In the education track at SCALE 14x in Pasadena, Gina Likins spoke about the surprisingly difficult task of getting information about open-source development practices into undergraduate college classrooms. That scarcity makes it hard to find new college graduates who have experience with open source. Although the conventional wisdom is that open source "is everywhere," the college computer-science (CS) or software-engineering (SE) classroom has proven to be a tough nut to crack—and may remain so for quite some time.

Likins works on Red Hat's University Outreach team—a group that does not do recruiting, she emphasized. Rather, the team travels to campuses around the United States and engages with teachers, administrators, and students about open source in the classroom. The surprise is how little open source one finds, at least in CS and SE degrees. Employers expect graduates to be familiar with open-source projects and tools (e.g., using Git, bug trackers, and so forth), she said, and incoming students report expecting to find it in the curriculum, but it remains a rarity.

Likins identified several practical obstacles that, based on the team's conversations with instructors, seem to stand in the way at many schools. First, instructors generally do not have the freedom to create new courses. CS and SE degree plans tend to be packed as it is, designed to cover a set array of topics with little wiggle room. And that limitation is on top of the usual restrictions on instructor time, classroom space, and departmental budget. Furthermore, there is the chicken-and-egg problem: "open source" as a topic is not well-established, so creating a new course to address it is largely undocumented and more time consuming than other potential new topics.

Second, the existing CS and SE curriculum guidelines do not include open source and do not leave sufficient room to incorporate it as an add-on topic. In a sense, of course, this problem overlaps with the preceding one, since departmental degree plans tend to have little flexibility. But Likins highlighted a more specific issue: there is only one "standard" for CS curriculum available, and it is published by the Association for Computing Machinery (ACM). Thus, the ACM guidelines are essentially the only ones in use, and in the 518 pages of detailed topics, open source is addressed only once. That occurrence is the "Foundations of the Open Source Movement" sub-topic, which is one elective among seven sub-topics within the "Intellectual Property" topic, itself one of ten topics within the "Social Issues and Professional Practice" knowledge area, which is one of 18 "knowledge areas" in the guidelines. In other words, open source is not exactly a central issue for the ACM.

Third, many instructors exhaust their available spare time working on publishable research (either for tenure and promotion or for grant support), and open source is not a topic that is covered in any research journals or at any academic conferences. Most of the CS-related journals and conferences are run by the ACM, Likins said. In addition, few technology journals are interested in research about educational techniques and no education conference has an "open source" track. Put together, these factors leave instructors interested in open source with nowhere to take their research.

Fourth, open-source projects simply move at a different pace than academia. While six-month cadences have been the norm for distribution and large-project releases over the past few years, she said, academic departments tend to plan four years ahead. While open-source software events often have call-for-papers (CFP) deadlines a few months before the event, academic conferences like that of ACM's SIGSCE (the Special-Interest Group for Computer Science Education) have CFP deadlines a full year out. Since open source moves so fast, it is difficult to plan material so much further out on the calendar.

Fifth, CS and SE instructors tend to be risk-averse. Few have any experience with open source, which makes it awkward to bring up in a course—lest the instructor get stuck on an issue to which they do not know the answer in the middle of a class. Most instructors are kept busy enough by their teaching duties and research that they do not have time to set aside for learning open-source tools and concepts.

What to do

After painting the rather dire picture of open source's absence in the undergraduate classroom, Likins went on to list several things that interested community members could do to make a positive impact. The first was to support programs that introduce instructors to open source. There are several such endeavors. Red Hat runs a summer short course called the Professors' Open Source Software Experience (POSSE) and OpenHatch has run workshops called Open Source Comes to Campus in the past (although it appears to have no such events planned for 2016). POSSE is supported by a US National Science Foundation (NSF) grant and is free for instructors to attend.

Formal programs like POSSE may not be an option for every instructor, though. Likins noted that, on several occasions, the University Outreach team has encountered universities with official "incubator"–style programs run with industry partners and requiring a six-figure buy-in from each company just to be allowed on campus. Fortunately, there are also several online resources for instructors, such as Foss2serve (which hosts classroom materials and teaching aids) and TeachingOpenSource.org (which is a community forum). She also encouraged attendees to share success stories, since many educators face the same basic questions when they first look at open source as a topic (such as how to grade students' work when that work is part of a larger, collaborative project).

There are also several areas of direct "evangelism" that tend to bear fruit, she said. One is encouraging instructors to teach version control—a topic that, surprisingly enough, is often overlooked, but serves as an excellent gateway to open-source concepts. Another is to tell recruiters at one's employer to ask about open-source software contributions when they talk to universities. For instance, asking a CS or SE department if its students have GitHub histories.

Community members can reach out to nearby universities on these topics, but they can also encourage schools in other subjects that relate to open source. There are several other movements that address openness and transparency in the academic sphere, such as open-access research and open data.

A lively question-and-answer period ended the session. Audience members raised several other possibilities for getting open-source concepts into the classroom, such as reaching out to vocational and technical schools. One audience member who is a CS student at a nearby university suggested engaging with teaching assistants (TAs). Her class had studied version control with Git, she reported, but it was taught by a programming class's TA, not its professor.

Other audience members pointed out that there is already a strong presence for open-source software in other places in universities, such as in IT programs. Lance Albertson of Oregon State University's Open Source Lab (OSU OSL) commented that the lab had started in a non-academic division of the university and only recently had made inroads into the activities of the undergraduate CS program. He also noted that a great many universities embrace open-source software in a big way at the Masters and PhD level, but it still does not filter into undergraduate curriculum.

The disconnect between undergraduate CS and SE programs and the open-source community is a perplexing problem; one without a simple solution. On the plus side, the community is taking the issue seriously and working to bridge the gap.

Comments (40 posted)

Whole-house audio with free hardware and software

The Black Forest fire destroyed over 500 Colorado houses in June 2013; one of those belonged to longtime Debian developer Bdale Garbee. As he reported during his talk at the 2016 linux.conf.au Multimedia and Music miniconf, the house has been redesigned and rebuilt and life is generally better now. Part of the rebuilding process included the incorporation of a whole-house audio system; naturally, Bdale took a unique approach to that task. His talk showed what can be done when one starts from scratch — and doesn't mind designing a circuit board along the way.

A common approach to whole-house audio is to use a network — typically WiFi — to distribute audio bits to various places within the house. Companies like Sonos and others happily sell that kind of system; there are, Bdale said, a number of free-software projects working to replicate those products. His approach was different, though. The system was designed around speakers built into the ceiling of each room; all are wired back to a central audio server installed in a mechanical closet. In other words, analog audio, rather than a digital stream, is distributed around the house.

There are plenty of proprietary products that follow that sort of design as well. They are typically built around a two-dimensional crossbar switch that can connect specific audio sources to any of a number of audio zones. He would have been happy enough with a proprietary solution, he said; in the end, it's just an appliance installed into the house. There was, though, one absolute deal-breaker: his due-diligence work turned up the existence of probable GPL-infringement issues with these products. Just reading the manuals was enough to make it clear that they were Linux-based, but there was no mention of software licenses, and no downloadable firmware in any form, much less source code. So some other sort of solution was called for.

The revised plan called for the builder to put in the speakers and wire them back to the central closet, but to install no server; Bdale would supply that part. He spent some time looking into commercially available amplifiers and switches, but he found them to be "clunky and expensive." The products were designed as if they were to be installed into professional recording studios; they had a level of complexity that he just didn't need. If only, he said, there were a nice USB-attached device with stereo output, the rest could easily be assembled from available hardware and software. Such things do exist, of course, but there were none that met his requirements; they required things like wall-wart power supplies, something that gets awkward when you mean to install nine of them. So he ended up designing his own hardware.

The result was the small board shown to the right. It features a PCM2705C digital-to-analog converter — essentially a USB stereo audio chip. Among its advantages are the fact that it already has good support in the Linux kernel. Tied to that is a TPA3118D2 class-D audio amplifier with 30 watts/channel of output power. Some of his audiophile friends evidently give him grief about using a class-D amplifier, but, he said, these amplifiers are good enough for a system built around ceiling-mounted speakers.

(Given that, as he said earlier in the talk, his previous office audio system was a tablet playing out of its built-in speaker, there can be no doubt that the new system sounds much better even if the gold-cable crowd would turn up its collective nose at it).

Nine of these modules (which go by the name usbclassd) are plugged into a MinnowBoard Max system. That board provides what's needed: a network interface and a USB port. The Intel architecture also seems to be important: some of the software components needed to obtain audio from commercial streaming services (he mentioned Spotify in particular) are binary-only. He is not entirely happy with that but, he said, keeping the family happy trumps adherence to open-source software principles.

The MinnowBoard is running a minimal Debian system; in general, he said, the earlier one can get out of the distribution's installer, the better. The directory tree for media is automounted (using NFS) from another server on the network. The audio software system is built around Mopidy. It was, he said, designed to be part of a desktop environment, so running it on this type of audio server is moving it a bit out of its native mode, but it works well enough. It supports the MPD protocol allowing for remote control, and has a web-interface protocol as well. He is not, he said, using Debian's packaged version of Mopidy since he needs the proprietary Spotify plugin which, naturally, Debian does not provide.

One interesting problem that had to be worked out is USB enumeration. The usbclassd boards are plugged into an inexpensive ten-port hub obtained online; those hubs, he said, are "randomly wired." The usbclassd boards lack unique serial IDs (something he could have added with another chip, but chose not to), so there is no way to tell them apart in the software. Fortunately, with a fixed hardware configuration, USB enumeration in the kernel is deterministic so, once he worked out which was which, it was a simple matter to map each device to the zone it serves.

One of the nice features of the amplifier he chose is that it can power down when the USB interface suspends itself. But, after realizing that those amplifiers were hot when no music was being played, he realized that things didn't quite work as he had expected. The USB audio interface doesn't suspend itself when there is no packet traffic; it depends on the suspend state of the interface in general. USB autosuspend tends not to be enabled by default, since there is a lot of second-rate hardware that doesn't support it well. His hardware does support it, though. A simple udev rule tweak was enough to get around that issue. It is still necessary to actually stop the audio stream out of Mopidy to get things to suspend, though; simply pausing it is not sufficient.

Getting back to Mopidy, he noted that it is designed to only support a single audio stream — a bit of a mismatch to his use case, with nine independent zones. His solution is to just run nine instances of Mopidy; it's a "clunky workaround," but it works. Each instance has its own MPD socket; the Mopidy Mobile app can be configured to know about all of the zones.

His final topic was clock skew. Digital audio interfaces work by streaming a series of samples to the digital-to-analog converter; that converter converts them to audio at the rate determined by the on-board clock. If you are feeding the same stream to multiple boards simultaneously, even small differences in the clock rate will accumulate over time. That can lead to the different zones being out of phase (an audiophile issue that Bdale found kind of laughable, especially given that the different zones are in different rooms) or eventual buffer underruns on the board with the faster clock. Bdale said that he could have gotten around this issue by creating a nine-output board with a single clock; a member of the audience suggested he could look into the clock synchronization support in GStreamer (which Mopidy uses). The simple fact, though, is that he doesn't really care about this issue. That could be reviewed if he ever develops the wish to drive multiple zones in parallel, but it is not an issue now.

The system is working, and the entire family seems to be happy with it. There are always improvements that can be made (he mentioned replacing the power-supply fan with "one that has ball bearings"), but, in a sense, the project can be seen as complete. For the curious, some more information, including schematics for the usbclassd board, can be found on his web site.

[Your editor thanks LCA for assisting with his travel expenses.]

Comments (26 posted)

Maslow's hierarchy and expanding the open-source community

On the last day of SCALE 14x, Sarah Sharp delivered the morning keynote, speaking about what individual community members can do to foster increased diversity in the open-source community. Sharp took a unique approach to the question, though; she looked at the factors identified in Maslow's hierarchy of needs, examining what those in the open-source community can do at each level to help people participate fully.

The hierarchy, she said, was first articulated by Abraham Maslow in his 1943 paper "A theory of human motivation." It describes five levels through which human motivation progresses, starting at the most fundamental and with each subsequent level building on the those below. For people to reach their fullest potential, each level's requirements must be satisfied, progressively up the hierarchy. That is, it is impossible to work on level three until levels one and two are satisfied.

The exact terms applied to each level can vary a bit depending on where one looks; Sharp described them, from the lowest level on up, as "homeostasis," "security," "community," "esteem," and "self-actualization." Homeostasis is the physical-survival need. In general usage, this means needs like food and water. For a geek in the open-source community, Sharp said, the equivalent need is the ability to get into "deep hack mode" where a person sufficiently tunes out the world to pour themselves into their projects.

To get there, Sharp said, a geek needs four things: sufficient uninterrupted time, some sort of computer, the electricity to run it, and (usually) some form of Internet access. But not everyone has access to all four. Uninterrupted time is a scarce commodity for many people—in particular, for anyone who is the caregiver to someone else (children or the elderly, for instance). And caregivers today are statistically more likely to be women than men—and, disproportionately, women of color.

Things the community can do to help people with limited time, she said, include providing daycare at events like conferences or hackathons, and not treating periods of inactivity (as can happen when caregiving duties become particularly time-consuming) as a negative—which is a particularly common bias when assessing job applicants' resumes. Individuals can also support initiatives like OpenHatch that try to provide "non-standard entry points" to open-source participation.

As for computer access, it is often taken for granted these days, but reality is more complicated. Even in the US, there is a significant disparity in computer ownership based on race, and an even bigger disparity based on income. Furthermore, the statistics quoted often focus on "households with a computer" or similar metrics—but they do not tell the whole story. A household might have a computer, but in many cases it belongs to one member of the household (say, the father or an older sibling), and others in the house have limited or no access to it.

And many of the computers in such statistics tend to be low-end devices like Chromebooks when, too often, the open-source community assumes everyone has access to a powerful PC (e.g., one fast enough to run a virtual machine at comfortable speed or with hundreds of gigabytes of storage). To accommodate people with reduced access to computers, she said, projects can set up development servers on which community members can run builds or do other work. They can also donate systems to non-profits that revamp them to distribute to low-income households, or contribute to low-cost-computing projects like Raspberry Pi.

Electricity and Internet access are not distributed evenly, either. In particular, it is easy to overlook the fact that people in developing regions often pay by the byte for their Internet access. This creates a barrier to entry, as many open-source projects expect new volunteers to download enormous source-code bundles or to contact the project through always-on services like IRC. A 500MB data plan in India, she said, costs the equivalent of 17 hours of average wages (and 500MB happens to be roughly the size of a current kernel source bundle). It takes an average of ten page clicks to file a bug report, she said, which at the average web page size works out to nearly an hour's wages in India. That makes bug reporting a rather unappealing way to contribute.

Projects can help reduce these barriers to entry by consciously reducing their web site's footprint (in terms of of bandwidth and page-click count), by fully supporting asynchronous communication channels, and by bundling important resources like documentation with source-code downloads. In addition, she noted that Git still does not support interrupting and resuming download operations, which is an important bug to fix. And few web sites make any effort to detect when a session is over a slow or unreliable connection; site owners would do well to fall back to low-bandwidth versions of a site in such circumstances.

The homeostasis level occupied the longest portion of the talk, Sharp said, but that is because it is the most fundamental. The next most fundamental level is security, which means ensuring that each individual feels personally safe. Sharp did not want to spend time debating the frequency of online harassment, she said. Instead, she referred the audience to the Petrie Multiplier, which describes why members of a minority within a group encounter bad behavior with considerably greater frequency than do those in the majority. All else being equal, a few bad actors disproportionately make participating in the group unpleasant for those in the minority, just due to the minority:majority ratio.

The takeaway, Sharp said, is that projects should not discount reports of bad behavior experienced by those in the minority. If someone says they have experienced bad behavior, the community ought to believe it even if it does not seem to match with their own experience. Codes of conduct are what most projects employ to make people feel safe in their community; Sharp said it was good to see more and more projects using them, but cautioned that they should not be taken for a "magic checkmark." They only work when they are put into action. She also advised projects that "rolling your own" code of conduct is a bad idea akin to rolling your own cryptography. Instead, projects should contact experienced professionals like Frame Shift Consulting or Safety First PDX.

Codes of conduct are effective at cutting down on negative incidents, but they do not encourage participation—which is the goal at the community level of the hierarchy. Many projects would like to encourage more diverse participants, she said, but if 90% of all newcomers fail to make a contribution and drop out, minorities cannot be expected to do better.

She cited several things that projects can do to encourage new participants, including taking a look at on-boarding procedures and at documentation. Leaving newcomers to explore on their own is unlikely to succeed; projects need to document how to communicate with the project, how to get started with builds, how the release cycle works, and what the coding style and testing procedures are like. It is important to identify appropriate tasks for beginners and for intermediate participants, and to provide mentors.

The esteem level concerns recognizing a person's work, giving them attribution for their contributions, and acknowledging their successes. The key factor for enabling such recognition is providing open doors and invitations. It is too easy for us to unintentionally overlook individuals that do not match our preconceived expectations, Sharp said, and to accidentally limit who hears our invitations by advertising them only to the circles of people we already know or who resemble the people we know.

Projects can help improve this situation by deliberately focusing on growing new contributors into leadership roles: documenting what those leadership roles involve, appointing backup and "vacation maintainers," and seeking out those with diverse perspectives. Open-source projects already have a bad habit of burning out longstanding leaders and contributors, she said; introducing planned succession for leadership roles would alleviate that problem as well.

The last level, at the top of the hierarchy, is self-actualization, which means being able to reach your full potential at the things you are passionate about. It is important to recognize that self-actualization may mean something quite different to one person than another, Sharp said. For some, self-actualization means helping other people reach their full potential. She then listed a number of individuals who choose to work on projects that encourage diversity, like Mariella Paulino of Code For Progress, Asheesh Laroia and Karen Rustad Tölva of OpenHatch, Leslie Hawthorne of Google Summer of Code, and Karen Sandler of Outreachy.

But one does not need to start a large project to help other people achieve their goals, Sharp said in conclusion. Her own story, she explained, involved numerous allies along the way who encouraged her in her journey through the technical community—from her first computer, through college, into the general open-source community, the kernel community, Outreachy, and now the graphics community. Everyone in the audience, she said, can do the things mentioned in the talk. The important thing is that they stop being a bystander and start to contribute.

Comments (12 posted)

Don't Panic about "going dark"

The rising use of encrypted communication channels, coupled with more system-wide encryption on devices like phones, has been increasingly fingered by law enforcement and other government agencies as an impediment to doing their jobs. This is the so-called "going dark" problem that posits that the ability to thwart terrorism and other crimes is slowly being reduced because these organizations can't see inside the encrypted data—even if they have obtained the legal authority to do so. A recent report [PDF] from a panel of security experts frames the debate a bit differently, as its title ("Don't Panic") might indicate.

The report comes from a "a diverse group of security and policy experts from academia, civil society, and the U.S. intelligence community" under the auspices of the Berkman Center for Internet & Society at Harvard University. The group was convened by Matt Olsen, Bruce Schneier, and Jonathan Zittrain. The latter two are reasonably well-known in our communities; Olsen is former director of the US National Counterterrorism Center (NCTC) and former general counsel to the US National Security Agency (NSA). The report and its conclusions were endorsed by the private sector participants (including Olsen), but the government officials "are precluded from signing on because of their employment"; they were simply thanked for participating in the discussions over the last year.

The "going dark" argument has been used to bolster the idea of encryption backdoors that can "only" be used by properly authorized law enforcement or national security agencies. The idea is as appealing as it is impossible, but debunking it is not really the thrust of the report. Instead, it looks at the reality of the computing landscape and concludes, rather ironically, that various factors will increase, not decrease, the ability to do surveillance.

The "findings" section (pages five and six of the PDF) is kind of eye-opening. For one thing, end-to-end encryption is "unlikely to be adopted ubiquitously by companies, because the majority of businesses that provide communications services rely on access to user data for revenue streams and product functionality", it states. In addition, the "Internet of Things" (IoT) will provide many more avenues for surveillance through sensors, audio, video, and the like.

Beyond that, metadata (e.g. email headers, phone and SMS call records, or location information) is typically not encrypted and is unlikely to be encrypted anytime soon. "This information provides an enormous amount of surveillance data that was unavailable before these systems became widespread." The report points to fragmentation in the software ecosystem as another reason not to panic about going dark. In fact, the report questions the metaphor itself:

From a security and privacy standpoint, the findings are worrisome, as the report acknowledges. The hope that more and better-integrated encryption will lead to better privacy seems to be dashed by the realities of the market. Companies will still want to track users and their data so they can use (or abuse) that information—or sell it to others. New devices will roll out with insufficient security and privacy safeguards that will spill our secrets left and right. While the report may provide some solace for the agencies that are concerned about going dark, it can only be viewed with some sadness by privacy and security advocates.

The moderately lengthy report provides some background on the debate, including its roots in the "crypto wars" of the 1990s (and earlier). It also gives more detail on the bullet points in the findings section. It builds a fairly strong case that companies and fragmentation in the market will lead to less encryption or, at least, less encryption where the users hold the only keys.

The IoT will likely bring a whole new range of surveillance options. There are several examples given of existing devices (automobile assistance systems with in-car microphones, smart TVs, wireless cameras, even the "OK Google" feature in the Chrome browser) that have the potential to be used for surveillance. Court orders could be used to force those companies to arrange for law enforcement to use these products for surveillance. While the report doesn't directly address it, there is the risk that organizations or individuals could exploit security vulnerabilities in the devices to do the same—with no court order required.

There are also three "individual statements from signatories" attached as Appendix A (page 19), which offer some additional perspectives. Susan Landau focused on the "business case" for encryption:

Schneier pointed out that there are multiple uses for encryption, from protecting credit card numbers to helping dissidents avoid arrest to journalists communicating with sources, all of which are worth protecting—and protecting well.

He also reprises another common theme in his writing:

In his statement, Zittrain reiterates the avenues that are being opened up by new technology:

As can be seen, the report is a bit bleak, at least for privacy advocates, but it does paint a realistic picture of where we are today—and where we are likely to be in the near future. There are few, if any, who are arguing that there are no circumstances that should allow government access to private data. But there is a balance to be struck and, at least rhetorically, politicians generally seem to want to magically legislate around the realities of encryption, instead of recognizing the limits of their power. As this report shows, the sky is not falling: law enforcement can get most of what it needs without endangering the real, important uses of encryption. Hopefully the politicians are listening.

Comments (4 posted)

Security quotes of the week

— The Guardian

— Ross Anderson

— Bruce Schneier

Comments (none posted)

NSA Hacker Chief Explains How to Keep Him Out of Your System (Wired)

Wired reports on a talk at the USENIX Enigma conference by Rob Joyce of the US National Security Agency (NSA). Joyce is the head of the NSA's Tailored Access Operations, which is tasked with breaking into the systems of adversaries and sometimes allies. He spoke about ways to thwart the NSA and other nation-state-level attackers. "'We put the time in …to know [that network] better than the people who designed it and the people who are securing it,' he said. 'You know the technologies you intended to use in that network. We know the technologies that are actually in use in that network. Subtle difference. You'd be surprised about the things that are running on a network vs. the things that you think are supposed to be there.'"

Comments (16 posted)

Fifteen years of SELinux

This Red Hat blog post celebrates the fifteenth anniversary of the first SELinux release. "With the question of open source security long behind us, we are now focused on providing an even more flexible security model through SELinux. With the rise of composite, distributed applications that can span hundreds of physical and virtual machines as well as disparate cloud instances and Linux container deployments, one-off usage of SELinux is not enough. Instead, we are focused on providing “defense in depth” for modern computing scenarios, effectively building and deploying SELinux policies at each level of the datacenter."

Comments (9 posted)

gosa: code injection

Package(s):	gosa	CVE #(s):	CVE-2015-8771
Created:	February 1, 2016	Updated:	July 26, 2016
Description:	From the Debian LTS advisory: GOsa upstream reported a code injection vulnerability in the Samba plugin code of GOsa. During Samba password changes it has been possible to inject malicious Perl code.
Alerts:	Debian-LTS DLA-562-1 gosa 2016-07-26 Debian-LTS DLA-408-1 gosa 2016-01-31

Comments (none posted)

java: information leak

Package(s):	java-1.6.0-ibm	CVE #(s):	CVE-2015-5041
Created:	February 2, 2016	Updated:	February 3, 2016
Description:	From the Red Hat bugzilla: A flaw in the IBM J9 JVM allows code to invoke non-public interface methods under certain circumstances. Untrusted code could potentially exploit this. This could lead to sensitive data being exposed to an attacker, or the attacker being able to inject bad data.
Alerts:	Red Hat RHSA-2016:0098-01 java-1.8.0-ibm 2016-02-02 Red Hat RHSA-2016:0099-01 java-1.7.1-ibm 2016-02-02 Red Hat RHSA-2016:0100-01 java-1.7.0-ibm 2016-02-02 Red Hat RHSA-2016:0101-01 java-1.6.0-ibm 2016-02-02 SUSE SUSE-SU-2016:0776-1 java-1_6_0-ibm 2016-03-15 SUSE SUSE-SU-2016:0770-1 java-1_6_0-ibm 2016-03-15 SUSE SUSE-SU-2016:0636-1 java-1_7_0-ibm 2016-03-02 SUSE SUSE-SU-2016:0431-1 java-1_6_0-ibm 2016-02-11 SUSE SUSE-SU-2016:0433-1 java-1_7_0-ibm 2016-02-11 SUSE SUSE-SU-2016:0428-1 java-1_6_0-ibm 2016-02-11 SUSE SUSE-SU-2016:0399-1 java-1_7_1-ibm 2016-02-10 SUSE SUSE-SU-2016:0401-1 java-1_7_1-ibm 2016-02-10 SUSE SUSE-SU-2016:0390-1 java-1_8_0-ibm 2016-02-09

Comments (none posted)

kernel: information leak

Package(s):	kernel	CVE #(s):	CVE-2015-4004
Created:	February 1, 2016	Updated:	February 3, 2016
Description:	From the CVE entry: The OZWPAN driver in the Linux kernel through 4.0.5 relies on an untrusted length field during packet parsing, which allows remote attackers to obtain sensitive information from kernel memory or cause a denial of service (out-of-bounds read and system crash) via a crafted packet.
Alerts:	openSUSE openSUSE-SU-2016:0301-1 kernel 2016-02-01 Ubuntu USN-3004-1 linux-raspi2 2016-06-09 Ubuntu USN-3002-1 linux-lts-wily 2016-06-09 Ubuntu USN-3001-1 linux-lts-vivid 2016-06-09 Ubuntu USN-3000-1 linux-lts-utopic 2016-06-09 Ubuntu USN-2998-1 linux-lts-trusty 2016-06-09 Ubuntu USN-3003-1 kernel 2016-06-09 Ubuntu USN-2989-1 kernel 2016-05-31

Comments (none posted)

kernel: NULL pointer dereference

Package(s):	kernel	CVE #(s):	CVE-2015-8787
Created:	February 1, 2016	Updated:	February 3, 2016
Description:	From the Red Hat bugzilla: Kernel NULL pointer dereference vulnerability was found in netfilter/nf_nat_redirect.c in nf_nat_redirect_ipv4 function introduced by commit 8b13eddfdf04cbfa561725cfc42d6868fe896f56 ("netfilter: refactor NAT redirect IPv4 to use it from nf_tables").
Alerts:	openSUSE openSUSE-SU-2016:2290-1 kernel 2016-09-12 Oracle ELSA-2016-3596 kernel 4.1.12 2016-08-26 Oracle ELSA-2016-3596 kernel 4.1.12 2016-08-26 Fedora FEDORA-2016-5d43766e33 kernel 2016-02-01 Fedora FEDORA-2016-2f25d12c51 kernel 2016-02-01 openSUSE openSUSE-SU-2016:1008-1 kernel 2016-04-12 Ubuntu USN-2890-3 linux-raspi2 2016-02-01 Ubuntu USN-2890-2 linux-lts-wily 2016-02-01 Ubuntu USN-2889-2 linux-lts-vivid 2016-02-01 Ubuntu USN-2889-1 kernel 2016-02-01 Ubuntu USN-2890-1 kernel 2016-02-01

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2015-8785
Created:	February 2, 2016	Updated:	February 3, 2016
Description:	From the Ubuntu advisory: It was discovered that the Linux kernel's Filesystem in Userspace (FUSE) implementation did not handle initial zero length segments properly. A local attacker could use this to cause a denial of service (unkillable task).
Alerts:	openSUSE openSUSE-SU-2016:2649-1 kernel 2016-10-26 Oracle ELSA-2016-3596 kernel 4.1.12 2016-08-26 Oracle ELSA-2016-3596 kernel 4.1.12 2016-08-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 SUSE SUSE-SU-2016:1203-1 kernel 2016-05-03 SUSE SUSE-SU-2016:1102-1 kernel 2016-04-19 openSUSE openSUSE-SU-2016:1008-1 kernel 2016-04-12 SUSE SUSE-SU-2016:0911-1 kernel 2016-03-30 SUSE SUSE-SU-2016:0785-1 kernel 2016-03-16 Debian DSA-3503-1 kernel 2016-03-03 Ubuntu USN-2910-2 linux-lts-vivid 2016-02-27 Ubuntu USN-2909-2 linux-lts-utopic 2016-02-27 Ubuntu USN-2908-5 linux-lts-wily 2016-02-27 Ubuntu USN-2908-4 kernel 2016-02-26 SUSE SUSE-SU-2016:0585-1 kernel 2016-02-25 Ubuntu USN-2908-3 linux-raspi2 2016-02-22 Ubuntu USN-2908-2 linux-lts-wily 2016-02-22 Ubuntu USN-2910-1 linux-lts-vivid 2016-02-22 Ubuntu USN-2909-1 linux-lts-utopic 2016-02-22 Ubuntu USN-2907-2 linux-lts-trusty 2016-02-22 Ubuntu USN-2907-1 kernel 2016-02-22 Ubuntu USN-2908-1 kernel 2016-02-22 Debian-LTS DLA-412-1 linux-2.6 2016-02-06 Ubuntu USN-2886-2 linux-ti-omap4 2016-02-01 Ubuntu USN-2886-1 kernel 2016-02-01

Comments (none posted)

kernel: memory leak

Package(s):	kernel	CVE #(s):	CVE-2016-0774
Created:	February 3, 2016	Updated:	April 12, 2016
Description:	From the Red Hat advisory: It was found that the fix for CVE-2015-1805 incorrectly kept buffer offset and buffer length in sync on a failed atomic read, potentially resulting in a pipe buffer state corruption. A local, unprivileged user could use this flaw to crash the system or leak kernel memory to user space.
Alerts:	Ubuntu USN-2967-2 linux-ti-omap4 2016-05-09 Ubuntu USN-2968-2 linux-lts-trusty 2016-05-09 Ubuntu USN-2967-1 kernel 2016-05-09 Ubuntu USN-2968-1 kernel 2016-05-09 Red Hat RHSA-2016:0617-01 kernel 2016-04-12 Oracle ELSA-2016-3528 kernel 3.8.13 2016-03-24 Oracle ELSA-2016-3528 kernel 3.8.13 2016-03-24 CentOS CESA-2016:0494 kernel 2016-03-23 Scientific Linux SLSA-2016:0494-1 kernel 2016-03-23 Oracle ELSA-2016-0494 kernel 2016-03-22 Red Hat RHSA-2016:0494-01 kernel 2016-03-22 SUSE SUSE-SU-2016:0785-1 kernel 2016-03-16 Debian DSA-3503-1 kernel 2016-03-03 Debian-LTS DLA-439-1 linux-2.6 2016-02-29 Red Hat RHSA-2016:0103-01 kernel 2016-02-02

Comments (none posted)

krb5: information leak

Package(s):	krb5	CVE #(s):
Created:	January 29, 2016	Updated:	February 3, 2016
Description:	From the Fedora advisory: krb5kdc.log file is world-readable by default.
Alerts:	Fedora FEDORA-2016-35cee11780 krb5 2016-01-28

Comments (none posted)

krb5: three vulnerabilities

Package(s):	krb5	CVE #(s):	CVE-2015-8629 CVE-2015-8630 CVE-2015-8631
Created:	February 1, 2016	Updated:	April 4, 2016
Description:	From the Mageia advisory: In all versions of MIT krb5, an authenticated attacker can cause kadmind to read beyond the end of allocated memory by sending a string without a terminating zero byte. Information leakage may be possible for an attacker with permission to modify the database (CVE-2015-8629). In MIT krb5 1.12 and later, an authenticated attacker with permission to modify a principal entry can cause kadmind to dereference a null pointer by supplying a null policy value but including KADM5_POLICY in the mask (CVE-2015-8630). In all versions of MIT krb5, an authenticated attacker can cause kadmind to leak memory by supplying a null principal name in a request which uses one. Repeating these requests will eventually cause kadmind to exhaust all available memory (CVE-2015-8631).
Alerts:	Fedora FEDORA-2016-d9d394d999 krb5 2016-01-31 Scientific Linux SLSA-2016:0532-1 krb5 2016-04-04 CentOS CESA-2016:0532 krb5 2016-03-31 Oracle ELSA-2016-0532 krb5 2016-03-31 Red Hat RHSA-2016:0532-01 krb5 2016-04-01 CentOS CESA-2016:0493 krb5 2016-03-23 Scientific Linux SLSA-2016:0493-1 krb5 2016-03-23 Oracle ELSA-2016-0493 krb5 2016-03-22 Red Hat RHSA-2016:0493-01 krb5 2016-03-22 Debian-LTS DLA-423-1 krb5 2016-02-22 Fedora FEDORA-2016-35492207cb krb5 2016-02-15 openSUSE openSUSE-SU-2016:0406-1 krb5 2016-02-10 Mageia MGASA-2016-0052 krb5 2016-02-05 Debian DSA-3466-1 krb5 2016-02-04

Comments (none posted)

nettle: improper cryptographic calculations

Package(s):	nettle lib32-nettle	CVE #(s):	CVE-2015-8803 CVE-2015-8804 CVE-2015-8805
Created:	February 3, 2016	Updated:	June 2, 2016
Description:	From the Arch Linux advisory: It has been discovered that multiple carry propagation bugs are producing wrong results in calculations. They affect the NIST P-256 and P-384 curves. The P-256 bug is in the C code and affects multiple architectures. The P-384 bug is in the assembly code and only affects 64 bit x86. The computation compiles a certain curve point with 1, which should not change the coordinates, however it does. The impact is currently unclear, but miscalculations in cryptographic functions are classified as security issues.
Alerts:	Oracle ELSA-2016-2582 nettle 2016-11-10 Red Hat RHSA-2016:2582-02 nettle 2016-11-03 Fedora FEDORA-2016-d94300845b compat-nettle27 2016-06-02 Scientific Linux SLSA-2016:2582-2 nettle 2016-12-14 Fedora FEDORA-2016-8ee88aee21 nettle 2016-02-21 openSUSE openSUSE-SU-2016:0486-1 libnettle 2016-02-17 openSUSE openSUSE-SU-2016:0477-1 libnettle 2016-02-16 openSUSE openSUSE-SU-2016:0475-1 libnettle 2016-02-16 Ubuntu USN-2897-1 nettle 2016-02-15 Fedora FEDORA-2016-aa00f0631d mingw-nettle 2016-02-15 Fedora FEDORA-2016-aa00f0631d mingw-gnutls 2016-02-15 Mageia MGASA-2016-0061 nettle 2016-02-09 Fedora FEDORA-2016-89968f88d2 nettle 2016-02-04 Arch Linux ASA-201602-5 nettle 2016-02-03 Arch Linux ASA-201602-6 lib32-nettle 2016-02-03

Comments (none posted)

nginx: two denial of service flaws

Package(s):	nginx	CVE #(s):	CVE-2016-0746 CVE-2016-0747
Created:	January 28, 2016	Updated:	February 3, 2016
Description:	From the Arch Linux advisory: CVE-2016-0746 (denial of service): Use-after-free condition might occur during CNAME response processing if the "resolver" directive was used, allowing an attacker who is able to trigger name resolution to cause segmentation fault in a worker process, or might have potential other impact. CVE-2016-0747 (denial of service): CNAME resolution was insufficiently limited if the "resolver" directive was used, allowing an attacker who is able to trigger arbitrary name resolution to cause excessive resource consumption in worker processes.
Alerts:	Red Hat RHSA-2016:1425-01 rh-nginx18-nginx 2016-07-14 Fedora FEDORA-2016-fd3428577d nginx 2016-01-30 Arch Linux ASA-201601-31 nginx 2016-01-27 Gentoo 201606-06 nginx 2016-06-17 Mageia MGASA-2016-0065 nginx 2016-02-17 Debian DSA-3473-1 nginx 2016-02-11 Ubuntu USN-2892-1 nginx 2016-02-09 openSUSE openSUSE-SU-2016:0371-1 nginx 2016-02-07 Fedora FEDORA-2016-bf03932bb3 nginx 2016-02-05

Comments (none posted)

ntp: multiple vulnerabilities

Package(s):	ntp	CVE #(s):	CVE-2015-7974 CVE-2015-7977 CVE-2015-7978 CVE-2015-7979 CVE-2015-8158
Created:	January 29, 2016	Updated:	November 11, 2016
Description:	From the Mageia advisory: CVE-2015-7974: In ntpd before 4.2.8p6, when used with symmetric key encryption, the client would accept packets encrypted with keys for any configured server, allowing a server to impersonate other servers to clients, thus performing a man-in-the-middle attack. A server can be attacked by a client in a similar manner. CVE-2015-7977: A NULL pointer dereference flaw was found in the way ntpd processed 'ntpdc reslist' commands that queried restriction lists with a large amount of entries. A remote attacker could use this flaw to crash the ntpd process. CVE-2015-7978: A stack-based buffer overflow was found in the way ntpd processed 'ntpdc reslist' commands that queried restriction lists with a large amount of entries. A remote attacker could use this flaw to crash the ntpd process. CVE-2015-7979: It was found that when NTP is configured in broadcast mode, an off-path attacker could broadcast packets with bad authentication (wrong key, mismatched key, incorrect MAC, etc) to all clients. The clients, upon receiving the malformed packets, would break the association with the broadcast server. This could cause the time on affected clients to become out of sync over a longer period of time. CVE-2015-8158: A flaw was found in the way the ntpq client certain processed incoming packets in a loop in the getresponse() function. A remote attacker could potentially use this flaw to crash an ntpq client instance.
Alerts:	Oracle ELSA-2016-2583 ntp 2016-11-10 Red Hat RHSA-2016:2583-02 ntp 2016-11-03 Ubuntu USN-3096-1 ntp 2016-10-05 SUSE SUSE-SU-2016:2094-1 yast2-ntp-client 2016-08-17 Red Hat RHSA-2016:1552-01 ntp 2016-08-03 SUSE SUSE-SU-2016:1912-1 ntp 2016-07-29 Debian-LTS DLA-559-1 ntp 2016-07-25 Debian DSA-3629-1 ntp 2016-07-25 Gentoo 201607-15 ntp 2016-07-20 Fedora FEDORA-2016-8bb1932088 ntp 2016-01-30 Mageia MGASA-2016-0039 ntp 2016-01-29 Scientific Linux SLSA-2016:1141-1 ntp 2016-06-16 SUSE SUSE-SU-2016:1568-1 ntp 2016-06-14 Scientific Linux SLSA-2016:0780-1 ntp 2016-06-08 SUSE SUSE-SU-2016:1471-1 ntp 2016-06-01 Oracle ELSA-2016-1141 ntp 2016-05-31 Oracle ELSA-2016-1141 ntp 2016-05-31 CentOS CESA-2016:1141 ntp 2016-05-31 CentOS CESA-2016:1141 ntp 2016-05-31 Red Hat RHSA-2016:1141-01 ntp 2016-05-31 openSUSE openSUSE-SU-2016:1423-1 ntp 2016-05-27 openSUSE openSUSE-SU-2016:1329-1 ntp 2016-05-18 SUSE SUSE-SU-2016:1311-1 ntp 2016-05-17 Oracle ELSA-2016-0780 ntp 2016-05-13 SUSE SUSE-SU-2016:1291-1 ntp 2016-05-12 openSUSE openSUSE-SU-2016:1292-1 ntp 2016-05-12 SUSE SUSE-SU-2016:1278-1 ntp 2016-05-11 Red Hat RHSA-2016:0780-01 ntp 2016-05-10 SUSE SUSE-SU-2016:1247-1 ntp 2016-05-06 SUSE SUSE-SU-2016:1177-1 ntp 2016-04-28 SUSE SUSE-SU-2016:1175-1 ntp 2016-04-28 Scientific Linux SLSA-2016:2583-2 ntp 2016-12-14 Slackware SSA:2016-054-04 ntp 2016-02-23 Fedora FEDORA-2016-34bc10a2c8 ntp 2016-02-21

Comments (none posted)

openssl: multiple vulnerabilities

Package(s):	openssl	CVE #(s):	CVE-2015-3197 CVE-2016-0701
Created:	January 29, 2016	Updated:	March 1, 2016
Description:	From the Arch Linux advisory: CVE-2015-3197: A flaw was found in the way malicious SSL/TLS clients could negotiate SSLv2 ciphers that have been disabled on the server. This could result in weak SSLv2 ciphers being used for SSL/TLS connections, making them vulnerable to man-in-the-middle attacks. CVE-2016-0701: It was found that OpenSSL used weak Diffie-Hellman parameters based on unsafe primes, which were generated and stored in X9.42-style parameter files. An attacker who could force the peer to perform multiple handshakes using the same private DH component could use this flaw to conduct man-in-the-middle attacks on the SSL/TLS connection.
Alerts:	Gentoo 201601-05 openssl 2016-01-30 Fedora FEDORA-2016-527018d2ff openssl 2016-01-30 Ubuntu USN-2883-1 openssl 2016-01-28 Arch Linux ASA-201601-33 lib32-openssl 2016-01-29 Arch Linux ASA-201601-32 openssl 2016-01-29 Fedora FEDORA-2016-e1234b65a2 mingw-openssl 2016-05-21 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 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 Oracle ELSA-2016-0372 openssl098e 2016-03-09 Oracle ELSA-2016-0372 openssl098e 2016-03-08 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 openSUSE openSUSE-SU-2016:0640-1 libopenssl0_9_8 2016-03-03 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: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 Debian-LTS DLA-421-1 openssl 2016-02-20 openSUSE openSUSE-SU-2016:0442-1 openssl 2016-02-12 Mageia MGASA-2016-0056 openssl 2016-02-09 openSUSE openSUSE-SU-2016:0362-1 openssl 2016-02-07 Slackware SSA:2016-034-03 openssl 2016-02-03

Comments (none posted)

openstack-heat: denial of service

Package(s):	openstack-heat	CVE #(s):	CVE-2015-5295
Created:	February 3, 2016	Updated:	March 14, 2016
Description:	From the CVE entry: The template-validate command in OpenStack Orchestration API (Heat) before 2015.1.3 (kilo) and 5.0.x before 5.0.1 (liberty) allows remote authenticated users to cause a denial of service (memory consumption) or determine the existence of local files via the resource type in a template, as demonstrated by file:///dev/zero.
Alerts:	Red Hat RHSA-2016:0440-01 openstack-heat 2016-03-14 Red Hat RHSA-2016:0441-01 openstack-heat 2016-03-14 Red Hat RHSA-2016:0442-01 openstack-heat 2016-03-14 Red Hat RHSA-2016:0266-01 openstack-heat 2016-02-18 Fedora FEDORA-2016-fe5b9da308 openstack-heat 2016-02-02

Comments (none posted)

openstack-swift: denial of service

Package(s):	openstack-swift	CVE #(s):	CVE-2016-0738
Created:	February 3, 2016	Updated:	February 8, 2016
Description:	From the CVE entry: OpenStack Object Storage (Swift) before 2.3.1 (Kilo), 2.4.x, and 2.5.x before 2.5.1 (Liberty) do not properly close server connections, which allows remote attackers to cause a denial of service (proxy-server resource consumption) via a series of interrupted requests to a Large Object URL.
Alerts:	Red Hat RHSA-2016:0155-01 openstack-swift 2016-02-09 Red Hat RHSA-2016:0128-01 openstack-swift 2016-02-08 Red Hat RHSA-2016:0127-01 openstack-swift 2016-02-08 Red Hat RHSA-2016:0126-01 openstack-swift 2016-02-08 Fedora FEDORA-2016-2256c80a94 openstack-swift 2016-02-02

Comments (none posted)

owncloud: multiple vulnerabilities

Package(s):	owncloud	CVE #(s):	CVE-2016-1498 CVE-2016-1499 CVE-2016-1500 CVE-2015-1499
Created:	January 29, 2016	Updated:	February 3, 2016
Description:	From the Mageia advisory: A Cross-site scripting (XSS) vulnerability in the OCS discovery provider in ownCloud Server before 8.0.10 allows remote attackers to inject arbitrary web script or HTML via the URL resulting in a reflected Cross-Site-Scripting (CVE-2016-1498). ownCloud Server before 8.0.10 allows remote authenticated users to obtain sensitive information from a directory listing and possibly cause a denial of service (CPU consumption) via the force parameter to index.php/apps/files/ajax/scan.php (CVE-2015-1499). ownCloud Server before 8.0.10, when the "file_versions" application is enabled, does not properly check the return value of getOwner, which allows remote authenticated users to read the files with names starting with ".v" and belonging to a sharing user by leveraging an incoming share (CVE-2016-1500).
Alerts:	Mageia MGASA-2016-0040 owncloud 2016-01-29

Comments (none posted)

phpmyadmin: two vulnerabilities

Package(s):	phpmyadmin	CVE #(s):	CVE-2016-2039 CVE-2016-2041
Created:	February 1, 2016	Updated:	February 3, 2016
Description:	From the Several flaws were discovered in the CSRF authentication code of phpMyAdmin. CVE-2016-2039: The XSRF/CSRF token is generated with a weak algorithm using functions that do not return cryptographically secure values. CVE-2016-2041: The comparison of the XSRF/CSRF token parameter with the value saved in the session is vulnerable to timing attacks. Moreover, the comparison could be bypassed if the XSRF/CSRF token matches a particular pattern.
Alerts:	Debian DSA-3627-1 phpmyadmin 2016-07-24 Fedora FEDORA-2016-e1fe01e96e phpMyAdmin 2016-02-01 Debian-LTS DLA-406-1 phpmyadmin 2016-01-30 Debian-LTS DLA-481-2 phpmyadmin 2016-05-30 Debian-LTS DLA-481-1 phpmyadmin 2016-05-18 openSUSE openSUSE-SU-2016:0378-1 phpmyadmin 2016-02-08 openSUSE openSUSE-SU-2016:0357-1 phpMyAdmin 2016-02-07 Mageia MGASA-2016-0051 phpmyadmin/phpseclib 2016-02-05 Fedora FEDORA-2016-e55278763e phpMyAdmin 2016-02-03

Comments (none posted)

phpmyadmin: multiple vulnerabilities

Package(s):	phpmyadmin	CVE #(s):	CVE-2016-2038 CVE-2016-2040 CVE-2016-1927 CVE-2016-2042 CVE-2016-2043 CVE-2016-2044 CVE-2016-2045
Created:	February 1, 2016	Updated:	February 3, 2016
Description:	From the Red Hat bugzilla: CVE-2016-2038: By calling some scripts that are part of phpMyAdmin in an unexpected way, it is possible to trigger phpMyAdmin to display a PHP error message which contains the full path of the directory where phpMyAdmin is installed. CVE-2016-2040: * With a crafted table name it is possible to trigger an XSS attack in the database search page. * With a crafted SET value or a crafted search query, it is possible to trigger an XSS attacks in the zoom search page. * With a crafted hostname header, it is possible to trigger an XSS attacks in the home page. CVE-2016-1927: Password suggestion functionality uses Math.random() which does not provide cryptographically secure random numbers. CVE-2016-2042: By calling some scripts that are part of phpMyAdmin in an unexpected way, it is possible to trigger phpMyAdmin to display a PHP error message which contains the full path of the directory where phpMyAdmin is installed. CVE-2016-2043: With a crafted table name it is possible to trigger an XSS attack in the database normalization page. CVE-2016-2044: By calling a particular script that is part of phpMyAdmin in an unexpected way, it is possible to trigger phpMyAdmin to display a PHP error message which contains the full path of the directory where phpMyAdmin is installed. CVE-2016-2045: With a crafted SQL query, it is possible to trigger an XSS attack in the SQL editor.
Alerts:	Debian DSA-3627-1 phpmyadmin 2016-07-24 Fedora FEDORA-2016-e1fe01e96e phpMyAdmin 2016-02-01 Debian-LTS DLA-481-2 phpmyadmin 2016-05-30 Debian-LTS DLA-481-1 phpmyadmin 2016-05-18 openSUSE openSUSE-SU-2016:0378-1 phpmyadmin 2016-02-08 openSUSE openSUSE-SU-2016:0357-1 phpMyAdmin 2016-02-07 Mageia MGASA-2016-0051 phpmyadmin/phpseclib 2016-02-05 Fedora FEDORA-2016-e55278763e phpMyAdmin 2016-02-03

Comments (none posted)

prosody: insecure handling of dialback keys

Package(s):	prosody	CVE #(s):	CVE-2016-0756
Created:	February 1, 2016	Updated:	February 8, 2016
Description:	From the Debian advisory: It was discovered that insecure handling of dialback keys may allow a malicious XMPP server to impersonate another server.
Alerts:	Debian-LTS DLA-407-1 prosody 2016-01-30 Debian DSA-3463-1 prosody 2016-01-31 Fedora FEDORA-2016-5a5c85c5a8 prosody 2016-02-05 Fedora FEDORA-2016-e2c5111eda prosody 2016-02-03

Comments (none posted)

python-django: permission bypass

Package(s):	python-django	CVE #(s):	CVE-2016-2048
Created:	February 2, 2016	Updated:	February 3, 2016
Description:	From the Arch Linux advisory: If a ModelAdmin uses save_as=True (not the default), the admin provides an option when editing objects to "Save as new". A regression in Django 1.9 prevented that form submission from raising a "Permission Denied" error for users without the "add" permission. A remote attacker with django User account and change permissions but not "add" might be able to create objects for ModelAdmin with save=True.
Alerts:	Arch Linux ASA-201602-2 python2-django 2016-02-02 Arch Linux ASA-201602-1 python-django 2016-02-02

Comments (none posted)

qemu: multiple vulnerabilities

Package(s):	qemu, qemu-kvm	CVE #(s):	CVE-2016-1981 CVE-2016-2197 CVE-2016-2198
Created:	February 3, 2016	Updated:	November 11, 2016
Description:	From the Ubuntu advisory: It was discovered that QEMU incorrectly handled the e1000 device. An attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service. (CVE-2016-1981) Zuozhi Fzz discovered that QEMU incorrectly handled IDE AHCI emulation. An attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service. This issue only affected Ubuntu 15.10. (CVE-2016-2197) Zuozhi Fzz discovered that QEMU incorrectly handled USB EHCI emulation. An attacker inside the guest could use this issue to cause QEMU to crash, resulting in a denial of service. This issue only affected Ubuntu 14.04 LTS and Ubuntu 15.10. (CVE-2016-2198)
Alerts:	Oracle ELSA-2016-2585 qemu-kvm 2016-11-10 Red Hat RHSA-2016:2585-02 qemu-kvm 2016-11-03 openSUSE openSUSE-SU-2016:2494-1 xen 2016-10-11 SUSE SUSE-SU-2016:1785-1 kvm 2016-07-11 openSUSE openSUSE-SU-2016:1750-1 qemu 2016-07-06 SUSE SUSE-SU-2016:1745-1 xen 2016-07-06 SUSE SUSE-SU-2016:1703-1 qemu 2016-06-29 SUSE SUSE-SU-2016:1698-1 kvm 2016-06-28 SUSE SUSE-SU-2016:1560-1 qemu 2016-06-13 Fedora FEDORA-2016-a3298e39f7 qemu 2016-05-20 Mageia MGASA-2016-0176 qemu 2016-05-18 SUSE SUSE-SU-2016:1318-1 xen 2016-05-17 Fedora FEDORA-2016-f2b1f07256 qemu 2016-05-15 SUSE SUSE-SU-2016:1154-1 xen 2016-04-26 Scientific Linux SLSA-2016:2585-2 qemu-kvm 2016-12-14 openSUSE openSUSE-SU-2016:0995-1 xen 2016-04-08 SUSE SUSE-SU-2016:0955-1 xen 2016-04-05 Gentoo 201604-01 qemu 2016-04-02 openSUSE openSUSE-SU-2016:0914-1 xen 2016-03-30 SUSE SUSE-SU-2016:0873-1 xen 2016-03-24 Fedora FEDORA-2016-38b20aa50f xen 2016-03-19 Fedora FEDORA-2016-f4504e9445 xen 2016-03-20 Fedora FEDORA-2016-be042f7e6f qemu 2016-02-25 Fedora FEDORA-2016-b49aaf2c56 qemu 2016-02-21 Debian DSA-3471-1 qemu 2016-02-08 Ubuntu USN-2891-1 qemu, qemu-kvm 2016-02-03

Comments (none posted)

rails: multiple vulnerabilities

Package(s):	rails	CVE #(s):	CVE-2015-7576 CVE-2015-7577 CVE-2015-7581 CVE-2016-0751 CVE-2016-0752 CVE-2016-0753
Created:	February 1, 2016	Updated:	October 3, 2016
Description:	From the Debian advisory: Multiple security issues have been discovered in the Rails on Rails web application development framework, which may result in denial of service, cross-site scripting, information disclosure or bypass of input validation.
Alerts:	Debian-LTS DLA-642-1 ruby-activerecord-3.2 2016-09-30 Debian-LTS DLA-641-1 ruby-activesupport-3.2 2016-09-30 Debian-LTS DLA-603-1 ruby-activesupport-3.2 2016-08-27 Debian-LTS DLA-604-1 ruby-actionpack-3.2 2016-08-28 Debian DSA-3464-1 rails 2016-01-31 Debian-LTS DLA-498-1 ruby-activemodel-3.2 2016-05-31 Debian-LTS DLA-496-1 ruby-activerecord-3.2 2016-05-30 SUSE SUSE-SU-2016:1146-1 portus 2016-04-25 Red Hat RHSA-2016:0455-01 ruby193 2016-03-15 Red Hat RHSA-2016:0454-01 ror40 2016-03-15 Debian DSA-3509-1 rails 2016-03-09 Fedora FEDORA-2016-cb30088b06 rubygem-activesupport 2016-02-28 Fedora FEDORA-2016-3ede04cd79 rubygem-activesupport 2016-02-28 Fedora FEDORA-2016-73fe05d878 rubygem-activerecord 2016-02-28 Fedora FEDORA-2016-cc465a34df rubygem-activerecord 2016-02-28 Fedora FEDORA-2016-94e71ee673 rubygem-activemodel 2016-02-28 Fedora FEDORA-2016-eb4d6e8aab rubygem-activemodel 2016-02-28 Fedora FEDORA-2016-fa0dec2360 rubygem-actionview 2016-02-28 Fedora FEDORA-2016-97002ad37b rubygem-actionview 2016-02-28 Fedora FEDORA-2016-94e71ee673 rubygem-actionpack 2016-02-28 Fedora FEDORA-2016-f486068393 rubygem-actionpack 2016-02-28 Red Hat RHSA-2016:0296-01 rh-ror41 2016-02-24 openSUSE openSUSE-SU-2016:0372-1 rubygem-actionpack-4_2 2016-02-07 openSUSE openSUSE-SU-2016:0363-1 rubygem-actionpack-3_2 rubygem-activesupport-3_2 2016-02-07

Comments (none posted)

tiff: multiple vulnerabilities

Package(s):	tiff	CVE #(s):	CVE-2015-8781 CVE-2015-8782 CVE-2015-8783 CVE-2015-8784
Created:	February 1, 2016	Updated:	February 11, 2016
Description:	From the Debian LTS advisory: Several security flaws have been found and solved in libtiff, a library that provides support for handling Tag Image File Format (TIFF). These flaws concern out of bounds reads and writes in the LogL16Decode, LogLuvDecode24, LogLuvDecode32, LogLuvDecodeTile, LogL16Encode, LogLuvEncode24, LogLuvEncode32 and NeXTDecode functions.
Alerts:	openSUSE openSUSE-SU-2016:2375-1 tiff 2016-09-25 openSUSE openSUSE-SU-2016:2321-1 tiff 2016-09-16 Scientific Linux SLSA-2016:1546-1 libtiff 2016-08-03 Scientific Linux SLSA-2016:1547-1 libtiff 2016-08-02 Oracle ELSA-2016-1546 libtiff 2016-08-02 CentOS CESA-2016:1547 libtiff 2016-08-02 CentOS CESA-2016:1546 libtiff 2016-08-02 Red Hat RHSA-2016:1547-01 libtiff 2016-08-02 Red Hat RHSA-2016:1546-01 libtiff 2016-08-02 Debian-LTS DLA-405-1 tiff 2016-01-30 Gentoo 201701-16 tiff 2017-01-09 Ubuntu USN-2939-1 tiff 2016-03-23 openSUSE openSUSE-SU-2016:0414-1 tiff 2016-02-11 openSUSE openSUSE-SU-2016:0405-1 tiff 2016-02-10 Debian DSA-3467-1 tiff 2016-02-06

Comments (none posted)

webkitgtk4: multiple vulnerabilities

Package(s):	webkitgtk4	CVE #(s):	CVE-2015-1122 CVE-2015-1152 CVE-2015-1155 CVE-2015-3660 CVE-2015-3730 CVE-2015-3738 CVE-2015-3740 CVE-2015-3742 CVE-2015-3744 CVE-2015-3746 CVE-2015-3750 CVE-2015-3751 CVE-2015-3754 CVE-2015-3755 CVE-2015-5804 CVE-2015-5805 CVE-2015-5807 CVE-2015-5810 CVE-2015-5813 CVE-2015-5814 CVE-2015-5815 CVE-2015-5817 CVE-2015-5818 CVE-2015-5825 CVE-2015-5827 CVE-2015-5828 CVE-2015-5929 CVE-2015-5930 CVE-2015-5931 CVE-2015-7002 CVE-2015-7013 CVE-2015-7014 CVE-2015-7048 CVE-2015-7095 CVE-2015-7097 CVE-2015-7099 CVE-2015-7100 CVE-2015-7102 CVE-2015-7103 CVE-2015-7104
Created:	February 1, 2016	Updated:	December 13, 2016
Description:	Multiple vulnerabilities were discovered on WebKitGTK+. See the WebKitGTK+ Security Advisory for details.
Alerts:	Fedora FEDORA-2016-d132dbb529 webkitgtk4 2016-02-01 Gentoo 201612-41 webkit-gtk 2016-12-13 openSUSE openSUSE-SU-2016:0915-1 webkitgtk 2016-03-30 Fedora FEDORA-2016-9ec1850fff webkitgtk 2016-03-29 Mageia MGASA-2016-0116 webkit2 2016-03-25 Mageia MGASA-2016-0120 webkit 2016-03-25 Fedora FEDORA-2016-5d6d75dbea webkitgtk 2016-03-22 Ubuntu USN-2937-1 webkitgtk 2016-03-21 Fedora FEDORA-2016-1a7f7ffb58 webkitgtk3 2016-03-21 openSUSE openSUSE-SU-2016:0761-1 webkit2gtk3 2016-03-15

Comments (none posted)

xen: multiple vulnerabilities

Package(s):	xen	CVE #(s):	CVE-2016-1570 CVE-2016-1571
Created:	January 29, 2016	Updated:	February 3, 2016
Description:	From the CVE entries: CVE-2016-1570: The PV superpage functionality in arch/x86/mm.c in Xen 3.4.0, 3.4.1, and 4.1.x through 4.6.x allows local PV guests to obtain sensitive information, cause a denial of service, gain privileges, or have unspecified other impact via a crafted page identifier (MFN) to the (1) MMUEXT_MARK_SUPER or (2) MMUEXT_UNMARK_SUPER sub-op in the HYPERVISOR_mmuext_op hypercall or (3) unknown vectors related to page table updates.. CVE-2016-1571: The paging_invlpg function in include/asm-x86/paging.h in Xen 3.3.x through 4.6.x, when using shadow mode paging or nested virtualization is enabled, allows local HVM guest users to cause a denial of service (host crash) via a non-canonical guest address in an INVVPID instruction, which triggers a hypervisor bug check.
Alerts:	SUSE SUSE-SU-2016:1745-1 xen 2016-07-06 Fedora FEDORA-2016-e1784417af xen 2016-02-01 Fedora FEDORA-2016-2c15b72b01 xen 2016-01-28 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 openSUSE openSUSE-SU-2016:0914-1 xen 2016-03-30 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

Comments (none posted)

Kernel release status

The current development kernel is 4.5-rc2, released on January 31. Linus says things aren't going so slowly anymore: "As late as Friday, I was planning on talking about how nice it is to see this new trend of tiny rc2 releases, because there really hadn't been very many pull requests at all. But it turns out the pull requests were just heavily skewed to the end of the week, and 4.5-rc2 isn't particularly small after all. It pretty much doubled over the weekend." Still, he seems to think that things are working well enough.

Stable updates: 3.14.60 and 3.10.96 were released on January 29, followed by 4.4.1, 4.3.5, and 4.1.17 on January 31.

Comments (none posted)

Quotes of the week

— Linus Torvalds

— Paul McKenney

Comments (2 posted)

The return of the BFQ I/O scheduler

Once upon a time, block I/O schedulers, which are charged with optimizing the stream of I/O requests to storage devices, were an area of intensive development. The characteristics of rotating drives meant that I/O performance would vary greatly depending on the order in which requests were serviced. Hardware changes (and the move to solid-state storage devices in particular) have taken away much of the motivation for work in this area; on modern drives, the best thing the I/O scheduler can do is often to just stay out of the way. Still, some interest in improving I/O schedulers remains, as can be seen in the return of the budget fair queuing (BFQ) scheduler.

BFQ, developed by Paolo Valente and Arianna Avanzini, was last covered here in June 2014. It is derived from the CFQ I/O scheduler found in current kernels; CFQ is the default for most systems, though some users replace it with one of the simpler schedulers when they have fast drives. BFQ has diverged a long way from its CFQ roots, though.

See the 2014 article for details on how BFQ works; what follows is a much-abbreviated summary. For any given block device, BFQ creates a request queue for each process in the system. Each queue is assigned a budget, being the amount of I/O traffic it is allowed to dispatch to the drive in any given scheduling cycle; the budget is determined by the scheduler itself based on I/O priority and observations of the process's I/O behavior. The dispatching code, given the mellifluous name "B-WF²Q+", services each queue in turn; an amount of I/O up to the associated budget will be dispatched during that turn. By setting the budgets properly, BFQ tries to ensure that all processes get a fair amount of the available I/O bandwidth within fairly tight latency limits.

The core idea is simple, but the real world is rather more complex; as a result, BFQ, like CFQ before it, has accrued a number of heuristics aimed at improving performance in specific areas. Queues for cooperating processes working in the same area of the disk are merged to enable more request consolidation. If a process doing read requests empties its queue before exhausting its budget, the device will be idled briefly to give that process a chance to create another request. Processes identified as "soft realtime" (those with moderate bandwidth requirements and an observed regular on/off request cycle) will get higher priority, as will processes that are just starting up. And so on.

By all appearances, BFQ has not changed a great deal since the June 2014 posting. The described heuristics are mostly the same. Undoubtedly bugs have been fixed and performance improved based on experience using the scheduler in the real world. Such experience does exist; the scheduler has been shipped with a few second-tier distributions and, evidently, has been used in some handsets. Paolo has previously posted from the University of Modena and Reggio Emilia, but the current patches come instead from a Linaro address, suggesting that there is some commercial interest in this work.

The BFQ scheduler was well received in 2014, but the proposed method of getting it into the kernel was not. At that time, BFQ was added as a new I/O scheduler alongside the others in the kernel, but the kernel community had little appetite for yet another scheduler, much less one that resembles the in-kernel CFQ scheduler so closely. Since BFQ is, by most appearances, an improvement on CFQ, Paolo was advised to generate a series of patches evolving CFQ in the desired direction. That was easier said than done, even given that BFQ derives from CFQ; the two schedulers had diverged considerably while BFQ was being developed. As a result of this requirement, BFQ essentially disappeared from the kernel mailing lists for more than a year.

Its return shows how the BFQ developers intend to try to satisfy the request that was made of them. The new patch set consists of 22 changesets, divided into three main phases:

1. The CFQ scheduler is regressed back to the state it was in when BFQ originally split off from it. The first eight patches simply strip features (mostly heuristics) out of CFQ, simplifying it considerably. At the end of this phase, CFQ remains and (presumably) still works, but lacks most of the features it has acquired in the last few years.

2. The core CFQ engine is replaced wholesale with the core BFQ engine; that patch removes 1,700 lines of code and adds nearly 4,300 lines. The scheduler still calls itself CFQ (a name that may never change for compatibility reasons); at this point it represents BFQ in a relatively early stage of development. The next patch adds back full hierarchical scheduling and control-group support.

3. The remaining 11 patches add new heuristics to BFQ, addressing various performance and fairness issues that have come up over time.

As of this writing, the new patch set has not yet received any comments, so it remains to be seen whether the development community will accept this approach or not. As a general rule, kernel developers like to see code evolved in relatively small steps; a massive replacement of code in a single patch is hard to review and has a relatively high chance of introducing regressions and performance problems. The CFQ scheduler is heavily used in production; destabilizing it for a couple of releases is not really a viable option. So it's entirely possible that this submission will be no more successful than the previous ones.

On the other hand, there may be no better way to get BFQ into the kernel at this point. If enthusiasm for BFQ were low, that might simply doom it to an out-of-tree existence. But BFQ seems demonstrably better than the CFQ scheduler, and its heuristics are better understood, so there is a real motivation to get it into the kernel. One can imagine that it might take some time to build a sufficiently high level of confidence in the quality of the code, so BFQ should not be expected in, say, the 4.6 development cycle. But, given that time, the development community might yet see a way to get this code merged and made available to the user community as a whole.

Comments (10 posted)

Improving EXPORT_SYMBOL()

The kernel's EXPORT_SYMBOL() directive is used to make kernel symbols (functions and data structures) available to loadable modules; only the symbols that have been explicitly exported can by used by modules. This directive is a simple macro that has, since the beginning, had a couple of annoying limitations, but nobody has ever gotten around to fixing them until now. Al Viro's patch set is a good opportunity to look at symbol exports and how they work.

The actual implementation of EXPORT_SYMBOL() can be found in include/linux/export.h. Whenever this macro is invoked, it declares a kernel_symbol structure for the exported symbol:

    struct kernel_symbol
    {
	unsigned long value;
	const char *name;
    };

As one might expect, the name field is set to the name of the symbol, while value becomes its address. When the code is compiled, though, this structure is not placed with the rest of the surrounding object code; instead, it goes into a special ELF section called __ksymtab (or __ksymtab_gpl for GPL-only symbols). The kernel binary contains these sections; any module that exports symbols of its own can also have them. When the kernel boots (or a module that exports symbols is loaded), that section is read and the symbol table is populated from the structures found there. The symbol table can then be used to satisfy references from modules to exported symbols.

In theory, the symbol-export mechanism limits the API available to loadable modules. There was once hope that this API could be kept to a relatively small and well-defined set. A quick grep in the kernel repository reveals, though, that there are currently over 27,000 exported symbols — not exactly a small set. When you have that many symbols, simply maintaining them all becomes a bit of a challenge.

One rule of thumb meant to help with the maintenance of exported symbols is that the actual EXPORT_SYMBOL() directive should appear next to the function or data structure that it exports. That allows the function and its export declaration to be modified together. This rule is not always observed, though. Sometimes it's just a matter of old code that predates the adoption of this rule but, more often, it is actually the result of a couple of limitations in the export mechanism:

• The macros found in <linux/export.h> are written in C and use GCC-specific extensions; they do not work in assembly-language code. So the export declarations for any functions written in assembly must appear in a separate, C-language file.

• Code that is built into a separate library prior to being linked into the kernel image has a potential surprise of its own. If nothing that is built into the main kernel image uses the exported object, the linker will leave it out of the build. Later, when a module is loaded needing that symbol, the load will fail because that symbol is not actually present. One way to work around this problem is to put the export declaration in code that's known to be built in — away from the object actually being exported.

Addressing these limitations is the goal of Al's patch set. Fixing the first one is relatively easy; it is mostly just a matter of writing a version of <linux/export.h> that uses the necessary assembler directives to create the kernel_symbol structures in the proper section. There are some details related to alignment requirements on some architectures, but they do not appear to have been that hard to get around. Once Al's patches are applied, assembly code can include <asm/export.h> and use EXPORT_SYMBOL() in the usual way.

The solution to the second problem is a bit of scripting trickery. As part of the build process, objdump is run on any library objects to obtain a list of exported symbols. A dummy object file (lib-ksyms.o) is then created with an explicit reference to each exported symbol; that object file is linked directly into the kernel. That will cause the linker to pull in all of the exported functions as well, ensuring that they will be available later on when a module is loaded. That eliminates an annoying trap that can spring on unsuspecting users years in the future when they happen on a configuration that fails to pull in objects they will need.

The bulk of the patch set is a set of cleanups enabled by the above changes; in particular, a lot of EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() declarations are moved into assembly code next to the objects they are exporting. In the process, Al found a number of dusty corners where unused functions could be removed; as he put it: "I'm fairly sure that more junk like that is out there; that's one of the reasons why exports really ought to be near the definitions."

Not all of those cleanups need to be merged anytime soon, though; they can happen anytime after the enabling patches go into the mainline. So that part of the patch set will likely be left in the hands of the specific architecture maintainers (assembly-language code, by its nature, is found in the architecture-specific parts of the kernel tree). The core changes are straightforward and uncontroversial; there is unlikely to be much keeping them out of the mainline. So, in the near future, one longstanding build-system annoyance should be history.

Comments (2 posted)

Cluster support for MD/RAID 1

A high-availability (HA) cluster needs high-availability storage. There are two broad approaches to achieving this requirement. One is for some (or all) of the nodes to have local storage and for each write request to be sent on the network to at least two of those nodes. This is the approach taken by DRBD and Ceph, among others. It is not the approach we will be exploring today.

The second approach is to have suitably redundant storage quite separate from the cluster nodes. It is not unusual for an HA cluster to have a storage-area-network (SAN), using Fibre Channel or iSCSI, that connects all nodes equally to a storage server. This server might have many devices configured internally as RAID 6 or RAID 10 or similar and may even have redundant power and networking. Despite this, it can still be a single point of failure and would not fit, for example, a disaster-management plan that required each of two separate sites to be able to function without the other.

An obvious approach to managing HA storage in this sort of scenario is to use host-based mirroring across two storage servers, possibly at different locations. As the mirroring is host-based, there is no RAID 1 controller that could be a single point of failure. However, there is some complexity in allowing the different nodes to work with the various storage servers without inconveniencing each other. Clustered MD/RAID 1 is being developed by engineers at SUSE, in particular by Goldwyn Rodrigues and Guoqing Jiang, as a solution for managing this complexity and providing seamless storage in a cluster using multiple mirrored devices attached to all nodes.

The other main entrant in this space is “CLVM”, the clustered version of LVM2. CLVM can be used to ensure that when a number of devices are attached to multiple nodes in the cluster, any logical volume created or activated on one node is available on all other nodes. When a mirrored volume is activated, that volume can be accessed on all nodes, which provides the functionality being discussed here. A problem, though, is that performance is not as high as some would like. For reasons that will be explained once we get into the technical details, the synchronization overhead imposed by CLVM on RAID 1 can be prohibitive. Clustered MD/RAID 1 takes a different approach that early testing suggests has significantly reduced overhead.

The big picture: active-active with a cluster filesystem

The goal here is to have a cluster where all nodes can write to the same filesystem at the same time. Naturally, this requires a filesystem that understands the difficulties of working in a cluster and there are several such filesystems in existence — such as OCFS2 or GFS2. These filesystems are designed to work with shared storage where each node can potentially write directly to any block. They use a cluster-wide locking service such as DLM (the Distributed Lock Manager) to coordinate between nodes. The locks and the allocation of storage space are generally designed to avoid unnecessary contention, so if two nodes are creating and writing files in different directories, that should largely be able to continue without any locking traffic. Each node claims, for example, a large amount of unused space in a single cluster request, and then allocates it locally to whatever file it chooses.

With a cluster filesystem in control, the underlying RAID 1 needs no extra coordination across the cluster for I/O. Writes simply go to both devices and reads are directed to either. The one possible issue that needs to be considered is the possibility of two nodes writing to the same block at the same time. If this happened, then the two devices could contain different data, so future reads might sometimes get one value and sometimes the other. This is a worse result than with a single storage device, where the result of future reads would still be undefined, but would at least be stable. MD could use locking to protect against this possibility, but it would introduce substantial overhead of exactly the sort that the cluster filesystem has been designed to avoid. Neither CLVM or clustered MD perform this locking. Instead, they simply assume that such concurrent writes never happen.

With this assumption in place, MD does not need any cluster-wide communication as long as all the hardware is working correctly. Of course, it is when a failure happens that RAID becomes interesting and this is definitely the case in a cluster. The significant issue is what happens when a node fails or is unexpectedly disconnected from one or both storage devices. If the node had been writing to storage at the time something failed, the write could have succeeded on one device and not on the other, resulting in inconsistent content. This is not good.

When a node fails, the cluster-management mechanisms will notify the filesystem and it will have its own protocols, such as log replay, for dealing with inconsistencies left behind. But it will assume that each block on the storage has just one value, so that reads from different nodes won't report different contents. To protect this assumption, the RAID 1 layer must ensure that any inconsistency between the two halves of the mirror is never visible.

MD/RAID 1 must already deal with this possibility on a single-node system; it does so by “resyncing” the devices after a crash and by only reading from a single device until the resync finishes. This resync can take a long time, so a bitmap of possibly-out-of-sync regions is stored. Bits are set before a write commences, and are cleared when there have been no writes for a while. Just resyncing the part of the array listed in this bitmap is much faster than resyncing the whole array, so the small cost of updating the bitmap is justified by the significantly faster recovery.

The dm-raid1 module used with CLVM has a similar technique, though the terminology is different. Dm-raid1 maintains a “dirty region log” that serves the same function as the bitmap in MD/RAID 1. While they serve the same function, these two are managed quite differently in a clustered configuration, and this is probably the biggest difference between the CLVM/RAID 1 and clustered MD/RAID 1.

When CLVM is used, the “dirty region log” is managed by the “dm-log-userspace” module which handles all internal requests to mark or clear a region, or to test if a region is dirty, by sending a message to a user-space daemon. This daemon will replicate the information around the cluster using an appropriate protocol and may or may not store it on disk.

Clustered MD/RAID 1 continues to use a bitmap stored on both (or “all”) the devices in the array, but has a separate bitmap for each cluster node. Thus setting or clearing a bit (the equivalent of marking or clearing a region) proceeds identically to the single-node case — a simple write to all disks is sufficient.

Thus, to mark a region as “dirty”, CLVM must send a message to user space that must then be passed to all nodes in the cluster and acknowledgments must return to the originating node, and then to the kernel module. The same task in clustered MD/RAID 1 involves writing to a block of each storage device and waiting for confirmation. This difference is the main reason for expecting a speed improvement.

Walk-through of a node failure

Probably the best way to understand how failure is managed is to walk through the various steps involved. This walk-through begins with the cluster in a stable but busy state where all nodes have been writing to the filesystem that is replicated on two attached storage devices. Both of these devices have a set of bitmaps, one per node, and several bits in each bitmap are set to reflect the fact that there have been recent writes to corresponding regions and some of those writes may not yet have completed.

The walk-through starts with the failure of one node. The details of what goes wrong are not important, but somehow the cluster-management software determines that the node is no longer part of the cluster. Possibly, this will involve proactively disabling the node (STONITH) so that it cannot possibly write anything else at all to either device.

The first that MD knows of this is that it is told that node recovery is happening (the DLM recover_prep() callback is called). At this point, MD doesn't know any details but it knows something is amiss. It disables read-balancing so it only reads from the “first” device in the array (all nodes have the same understanding of “first”). This ensures that once the filesystem is told the extra details and possibly starts reading blocks that the failed node was writing, it will never risk seeing inconsistent data.

Second, MD is told which node has failed. It responds by taking note that the bitmap might be involved in a resync (so read-balancing should still be avoided) and by trying to claim the content of the bitmap owned by that node. The first node to get a lock on the appropriate DLM resource will copy that bitmap into its own bitmap, clear the original, and advise other nodes that it has taken over. Once this advice is sent and received, the blanket disabling of read-balancing can be relaxed.

At this point, service is largely back to normal. The filesystem will possibly still be doing some recovery but it can be sure it will always see consistent data. The out-of-sync regions still need to be resolved, though, so the node that copied the bitmap information will start a resync process after first claiming an exclusive lock on the “resync” resource, to ensure only one node is resyncing at a time.

Cluster resync

Resync involves reading from one device in the array (the “first”) and writing to all the others. If this is done while another node is performing a filesystem write to the same region, new corruption could occur. To avoid this, the resyncing node chooses a range of blocks and advises all other nodes that it is performing a resync. Other nodes will block new writes from commencing in this range and wait for pending writes to complete. When they acknowledge that they have stopped writing to the range, the region is resynced and the process moves forward. This is similar to the way resync happens with a single node; writes are suspended briefly while the resync makes progress. In a cluster, the higher communication overheads will likely result in larger regions being suspended and slightly longer delays for any writes that happen in the affected range.

As the resync progresses the other nodes are told about it a range at a time; those nodes can start read-balancing on the area that is known to be in-sync.

So far there have been two mentions of one node sending a message to the others: once when a node reports that it has taken over a particular bitmap, and once when that node advises others that it is resyncing a given range. DLM does not provide a general message-passing mechanism, but it provides two useful tools. One is a small (e.g. 64 byte) "Lock Value Block" (LVB) that can be attached to a resource for all nodes to see. The other is a callback that can be triggered on a node that has locked a resource and that is blocking some other node from locking the same resource. Clustered MD uses these on a set of three resources to provide a general broadcast facility and uses it in several different situations.

Failed node re-integration

After the resync process has finished, the remaining nodes are back to normal, can read-balance across all devices, and are resilient against single device failure again. There is just one more step in the walk-through: the step where the failed node comes back online.

When a node comes online in a cluster, DLM assigns it an index number. This number is used as an index into the list of bitmaps in the RAID 1, so it immediately know where it needs to store its intent to write. Before it does that, it needs to make sure that it is up-to-date with any resync that is currently happening in the cluster. This ensures it doesn't read-balance where it shouldn't or write over an ongoing resync.

The LVBs play a role here too, being used to store the current state of any ongoing resync. The new node can read these to ensure it knows the current state, and then can listen for broadcast of RESYNCING messages to follow the progress through the resync.

Once all these LVBs have been inspected, the new node will be able to follow any ongoing resync, knows which regions are safe to read-balance over, and can continue as a fully-fledged member of the cluster. This node's own bitmap will almost certainly be empty as some other node will have found it and copied out all the bits. If, by some chance, it did find bits set in one or more bitmaps (as could happen when the first node joins), it will start a resync of its own.

Handling device failure

In some ways, handling device failure in the cluster is similar to handling device failure in a single node: the faulty device is recorded in the array metadata as “Faulty” and service continues on the remaining device(s). It is a little different in that all nodes need to acknowledge the failure, but since we have a message broadcast mechanism for that, it is quite straightforward.

One important question introduced by the presence of the cluster is: “Is it the device that is faulty, or the node?”. If a node has lost contact with a device, then it could just be that a cable has been disconnected. There are two credible responses to this situation. One is to tell all nodes to stop using the device, because this node cannot perform updates there anymore. The other is to decide that losing one node is better than losing redundancy in the array, so this node should leave the cluster and stop functioning.

This is a policy decision that MD is not in a position to make, yet it must make some decision. If the array still has redundancy (i.e. there are 2 or more mirrored devices), the best course is to tell all nodes that the device is faulty. This is the easiest way to provide continued service. If some cluster-wide monitoring software can determine that only one node is having problems, and that the device is really fine, it could disable the faulty node and reactivate the missing device.

While the array is degraded, bits in the bitmap of out-of-sync ranges are never cleared. This means that when a recently removed device is re-introduced to the array, it can be fully re-integrated by just updating all of the regions listed in the bitmap rather than recovering the entire device. This means that reactivating that missing device will normally happen fairly quickly.

So if MD ejects a device due to an I/O error and the cluster-policy software decides this was the wrong choice, it can restore a fully redundant array with relatively little effort. Most of this would be controlled through udev scripts and such transient errors will usually be taken care of automatically.

If, on the other hand, the array is already degraded and MD detects a failure in the last remaining device, the options are different. In the single-node case, MD just passes the error up to the filesystem and lets it deal with it. In a cluster this is probably not ideal. The best solution in a cluster is probably to eject the node that has the problem, in the hope that other nodes can keep working. The best MD can do is to block the I/O request that caused the error and freeze the node. This leaves policy up to some other code. Cluster-health-management software can then either kill the node completely or instruct it to report the error to the filesystem.

Adding a new spare device

The one remaining task that is a little more interesting in a cluster than in a single node is integrating a new spare into the array. Related tasks, such as marking a device as failed or marking a specific spare as active, all involve changes to the set of devices that all nodes already know about. These changes can be achieved by updating the metadata and then asking all nodes to re-read and assess the new metadata — though in some cases clustered MD supports a more direct approach.

Adding a new device cannot be done with a simple “do this to that device”–style command because there is no a-priori guarantee that all nodes even know about the new device. MD uses a two-stage approach that involves support from user space and is open to the possibility of failure.

When mdadm is used to add a spare to a clustered array, MD will extract the (randomly assigned) device UUID from the MD superblock and broadcast a message to all nodes in the cluster asking them to add this device too. As they each get the message they trigger a “uevent” that will cause udev to run mdadm asking it to find that device. mdadm either adds the device to the array, or tells MD that the device cannot be found. MD then acknowledges the “add new disk” broadcast message.

The broadcast protocol that MD uses does not allow other nodes to send any negative acknowledgment. They just release a shared lock once they have handled the request so no success/failure can be passed back. This requires an extra piece of infrastructure.

When a node handles that “add new disk” message, it signifies success or failure either by releasing any lock that it might have on the resource called “no-new-dev”, or by taking a shared lock — respectively. When the originating node gets an acknowledgment for its broadcast it tries to get an exclusive lock on that resource. If this succeeds, then all other nodes must have successfully added the device. If it fails, then at least one node hasn't found the device.

After the “add” process completes — whether successfully or not — the on-disk metadata is updated and a message is broadcast to all nodes so they will re-read it. If the device-add failed because some node couldn't find the device, the new device will not be mentioned in the metadata, so those nodes that did successfully add it will know to remove it again.

Current and future status

The code currently in Linux 4.5-rcX implements nearly all of this, with a few remaining details to be finalized for 4.6. There are bound to be bugs but ongoing testing should resolve those soon enough.

A fairly obvious question once this is working reliably is: what about other RAID levels? The non-redundant levels of RAID 0 and Linear are already handled perfectly adequately by CLVM, so there is no value in adding support for those to MD. RAID 10 would not be much more complex than RAID 1, so if there was a genuine need and someone willing to pursue such an implementation, it would probably progress quite easily.

The striped/parity levels (RAID 4, RAID 5, and RAID 6) are more complex. As was mentioned at the start, the RAID 1 implementation depends on the fact that the filesystem won't write to the same block from two different nodes at the same time. For RAID-5–style levels the guarantee required would be that two different nodes don't write to the same stripe at the same time. As stripes are a lot bigger than blocks, that is much less likely.

Without this sort of guarantee from the filesystem, the only approach that might be workable would be for some node to be designated the primary node and for all others to send non-trivial requests over the network to that node. Trivial requests including reads from a working device and full-stripe writes could still be handled locally; that may provide improved performance over sending all I/O requests over the network.

While some interest has been shown in cluster-support for RAID 5 there are as yet no concrete plans to implement anything. For now, RAID 1 is all we have in our sights.

Comments (none posted)

The private, anonymous desktop of Tails 2.0

Version 2.0 of The Amnesic Incognito Live System (Tails) was released on January 26. Tails is a live distribution configured to provide robust anonymity and privacy safeguards for the user. This latest update includes important package updates as well as bringing usability improvements.

Tails 1.0 was released in April 2014, at which point we took a look. 1.0 was based on Debian 6 "squeeze;" the 1.1 update a few months later was re-based from Debian 7 "wheezy." 2.0 updates the base system to Debian 8 "jessie" and brings with it a substantial update to many applications and operating system components. That list includes support for systemd as the init system, GNOME 3.14 (updated from 3.4), LibreOffice 4.3 (updated from 3.5), Git 2.1.4 (updated from 1.7.10), and much more.

The systemd support has also allowed Tails to provide better security; many services are now isolated into namespaces by using systemd-nspawn. The project has also written custom scripts to wipe the contents of memory at shutdown time. For most users, though, the bigger issue may be that there are always security vulnerabilities found and patched between releases. The 2.0 release notes link to the known vulnerabilities in the previous release, a list that includes security holes in OpenSSH, the kernel, bind, and the Mozilla applications.

Users of older Tails releases will also want to note that the project performed a GPG key transition in conjunction with the 1.3.1 release in March 2015. Thus, to verify the signature on the downloadable ISO image, one will need to grab the updated key.

For new users, the project has developed an interactive installation assistant on its web site. The assistant walks the user through a series of questions to help them find the correct download and to help them get it written to the appropriate installation media.

I tested the new release on a laptop and in a virtual machine. Tails is fairly lightweight, so it starts up noticeably quicker than many full-blown desktop distributions. The only real hangup is that, while Tails does support the creation of an encrypted, persistent storage volume on USB media, that option is only available from within the Tails Installer program—it cannot be done on a USB stick that the Tails ISO was copied onto with dd.

The hurdle is not large, but the Tails documentation attempts to explain the situation by telling the user to use two separate USB drives, and some users may find the explanation more perplexing than helpful. Whether or not including a persistent volume is a good idea is up for debate; the project provides a warning page to educate potential users about the issues involved.

Once it is installed onto a bootable medium (e.g., USB or DVD), though, getting started with Tails is easy enough. At the session login screen, Tails offers options (seen to the left) to enable a root password, to start up with a spoofed MAC address, to set various network options (including disabling networking altogether), and to connect to Tor through a bridge node rather than through a standard entry node. All the options are transient, applied only during the current session.

Tor and Tor Browser are, naturally, key features of using Tails. The Tor Browser included is version 5.5, which is based on Firefox 38.6.0 ESR. One of the few known issues with Tails 2.0 is that an oversight caused the release to ship with misconfigured fingerprint resistance. Specifically, the browser is vulnerable to font fingerprinting. However, since all Tails 2.0 systems include the exact same set of installed fonts, the impact of this configuration issue is thought to be limited.

This is first Tails release to include GNOME Shell as the desktop environment, although Shell is run in "Classic" mode (with a menubar at the top of the screen). The release also replaces Claws Mail (which was the email application in previous releases) with Icedove, the Debian rebranding of Thunderbird. There is a standard, if basic, set of desktop and multimedia applications included. In addition, the package set includes a selection of security applications and helper utilities, such as Paperkey (to safely export OpenPGP secret keys for printing) and Keyringer (to encrypt and distribute information with Git).

Some of the other utilities included are familiar to users of many desktop distributions, but Tails takes pains to point out that they have security implications. For example, Tails includes a virtual keyboard, and notes that it can be used to enter passwords and other sensitive information to protect against hardware keyloggers.

There are a few custom applications to be found, including the already mentioned Tails Installer, a dedicated bug-reporting program called WhisperBack, and the Metadata Anonymisation Toolkit (MAT) to anonymize the metadata fields used in many common file formats.

Users will also find several usability improvements in the new release. For instance, a desktop notification pops up to alert the user when the Tor client has successfully established a connection to the Tor network. High-DPI displays are also better supported, and support for DVD drives and printers is improved.

Hardware support is a given on most desktop Linux distributions, but it can be tricky for Tails. For instance, since applications are sandboxed with AppArmor, it is not possible to upload files created in another application to a web site using Tor Browser (at least, not without jumping through some hoops to make accidents far less likely). But isolation has its limits: not being able to access the DVD drive on a computer (as in previous releases) was a fairly serious limitation for the Videos application. Tails 2.0 does an admirable job of striking that balance: users can now watch their DVDs and print documents, but not worry that a malicious web site will read the contents of their hard drive.

Tails is a focused distribution, of course: it protects the user against prying eyes and adversaries attempting to track their movements. The level of protection it provides is far above the standard "online security" expectation—but, at times, that protection is exactly what is warranted. The 2.0 release provides a solid update to the secure underpinnings of the 1.x series, and the refreshed desktop and application packages serve to create a more comfortable user experience at the same time.

Comments (3 posted)

Distribution quote of the week

-- Jerry James

Comments (6 posted)

KDE neon announced

The KDE neon project — which arguably could be seen as a replacement for the Kubuntu distribution — has been announced at FOSDEM. "More than ever people expect a stable desktop with cutting-edge features, all in a package which is easy to use and ready to make their own. KDE Neon is the intersection of these needs using a stable Ubuntu long-term release as its core, packaging the hottest software fresh from the KDE Community ovens. Compute knowing you have a solid foundation and enjoy the features you experience in the world's most customisable desktop."

Comments (37 posted)

openSUSE board election 2016 results

The openSUSE board election results are in. Tomáš Chvátal, Bryan Lunduke, and Gertjan Lettink will replace out-going members Andrew Wafaa, Bruno Friedman, and Robert Schweikert.

Full Story (comments: none)

openSUSE 13.1 has reached end of SUSE support

The SUSE sponsored support of openSUSE 13.1 has officially ended. The Evergreen community team will continue to maintain 13.1 until next November.

Full Story (comments: none)

Vacant Ubuntu Developer Membership Board seats: Call for nominations

Iain Lane and Stéphane Graber have stepped down, and Brian Murray, Micah Gersten, and Dimitri John Ledkov will reach the end of their terms in March, leaving five open seats on the Ubuntu Developer Membership Board. If six or more valid nominations are received voting will begin February 15.

Full Story (comments: none)

Ubuntu Online Summit

The next Ubuntu Online Summit will be held May 3-5. More information will be available at a later time.

Full Story (comments: none)

Distribution newsletters

• Devuan News Issue LX (January 31)
• DistroWatch Weekly, Issue 646 (February 1)
• Linux Mint Monthly News (January)
• Ubuntu Kernel Team newsletter (February 2)
• Ubuntu Weekly Newsletter, Issue 452 (January 31)

Comments (none posted)

Catanzaro: On WebKit security updates

Michael Catanzaro describes the sad state of WebKit security on Linux distributions and the challenges of security support for such a complex package in general. "We regularly receive bug reports from users with very old versions of WebKit, who trust their distributors to handle security for them and might not even realize they are running ancient, unsafe versions of WebKit. I strongly recommend using a distribution that releases WebKitGTK+ updates shortly after they’re released upstream. That is currently only Arch and Fedora. (You can also safely use WebKitGTK+ in Debian testing — except during its long freeze periods — and Debian unstable, and maybe also in openSUSE Tumbleweed. Just be aware that the stable releases of these distributions are currently not receiving our security updates.)" Lots of information here, worth a read for anybody interested in the topic.

Comments (19 posted)

Could Linux Mint Replace Ubuntu? (Datamation)

Matt Hartley compares Linux Mint and Ubuntu. "The tool that really stood out to me was mintBackup. It felt the same as Ubuntu's included Deja Dup app, but it went a step further – mintBackup can backup applications. Now I assume it's merely putting a friendly face onto "dpkg get selections." Still, in terms of managing software for friends and family, this would be a tremendous time saver. Restoring my own apps is stupid easy. Figuring out what the heck your "Uncle Bob" used for his music, videos, etc, isn't as simple. Hence, mintBackup blows Ubuntu out of the water in this regard."

Comments (none posted)

Rethinking python-ideas

The communication style of a project can often have an effect—for good or ill—on its ability to attract new developers. The established channels, which are often email-based, may work reasonably well for the existing developers, but frustrate new people. Finding the right balance can be difficult, which is something the Python community is currently discussing.

The specific channel under discussion is the python-ideas mailing list, which is meant for more speculative discussions of potential Python features. On that list, Michael Selik wondered if some forum other than a mailing list would help new people figure out which opinions were more valuable than others: "One defect of a mailing list is the difficulty of viewing a weighted average of opinions". He likened the situation to the US Senate, where each state has the same representation even though they may have vastly different populations.

Selik suggested that perhaps Stack Overflow might be a better tool for forums like python-ideas. That short post was a springboard for considering the tradeoffs of different communication mechanisms, with an eye toward alternatives for some Python development discussions. Nick Coghlan described the feature discussion process, which can take place in a variety of forums, including the bug tracker, mailing lists, and the Python Enhancement Proposal (PEP) process. How the right forum is determined is more of an art than a science, he said; the core developers help guide that. The mailing lists definitely play a role:

That's not to say that there might not be better ways to host those discussions, Coghlan said in response to a "vote" for StackExchange (which is the parent of Stack Overflow). The limiting factor is typically the ability of the Python Software Foundation (PSF) to add and manage new infrastructure.

Selik summarized some of the problems he sees with a list like python-ideas. In particular, it is hard for a new participant to recognize who are the decision makers, whose opinion is not particularly well-regarded, what the real consensus is, and so on. These are difficult to discern from a mailing list, but might be easier to pick up on using a discussion forum with a reputation system or voting.

There is some attraction to a forum like Stack Exchange, which Guido van Rossum summed up in a message supporting an experiment to augment python-ideas:

Van Rossum noted that there is at least one downside: StackExchange is not particularly usable for those with an email-centric workflow. Some questions were raised about the fit for StackExchange's "question and answer" format and the kinds of discussions that go on in python-ideas. Brett Cannon suggested some other possibilities:

It turns out that, for those who were posting in the thread, the voting is not a particularly popular feature from StackExchange. What Van Rossum is looking for is the standard URL that gets created for a discussion that can be referenced later; he also thinks the format will help new participants:

The conversation soon turned toward Discourse and, to a lesser extent, HyperKitty (which is part of the Mailman 3 suite). Those seem to have many of the features of interest without completely leaving email users behind. But some were unhappy that there was any thought of moving to some other communication mechanism. Cannon said that it is important to do so from time to time:

He noted that the tools used by longtime Python developers (NNTP, newsgroups, even IRC) may be completely unknown by those university students. But the community needs to "evaluate whether our ways of communicating are too antiquated for new participants in open source and whether they are no longer the most effective (because old does not mean bad, but it does not mean better either), while balancing it with not having constant churn or inadvertently making things worse". It is a balancing act, but the way forward is to try remove the emotional component from the discussion, he said:

That technique could—perhaps should—be applied more widely in open-source project discussions. However, one of the main friction points between email and web-based discussion forums soon reared its head. Marc-Andre Lemburg noted that he had needed to reformat a reply because the original was in HTML, rather than plain text. To Cannon, though, that was "an example of the OSS community trying to swim against the stream where the rest of the world has moved on and it is slowly making it harder to get new people to participate in OSS".

Lemburg sees things a bit differently, noting that archivers and text-only email readers have to do an imperfect conversion of HTML, which can lose formatting information. He also pointed out: "Email is not going to go away, but I certainly have seen a lot of other communication tools come and go - and I bet there's something to learn in that :-)".

As part of that same exchange, Cannon and Lemburg also discussed the Discourse/HyperKitty question. Cannon suggested that someone that wants to stay on the email side look into Discourse to see where it falls short; he would also like to hear something about what HyperKitty offers. Lemburg said that he hasn't "really seen a compelling argument for switching away from mailing lists completely yet". But that can only come from "an evaluation to properly show what we would gain or lose from a switch to something like Discourse or HyperKitty", Cannon said.

As Donald Stufft pointed out, though, there is a risk in only looking at what new contributors might want. He does think that the "mailing list interface is kind of crummy and relies on people hand tailoring a bunch of filters to make it in any way reasonable", but is concerned that Discourse or HyperKitty may just be "differently bad". Furthermore:

There is also a risk of "community fracture" when changing the discussion mechanism, as Barry Warsaw described:

For a core developer, there are already multiple forums to follow to keep up with the development; adding another just makes that problem worse. "How many different channels do I have to engage with to keep track of what's happening in core Python?", Warsaw asked. He is in favor of experimentation, but feels that the project should proceed somewhat cautiously.

The split into various forums is going on now and will continue, but major decisions still need to go through python-dev, Van Rossum said. But python-ideas can be "too noisy", which has led some core developers to stop following it. Some other, less noisy discussion mechanism (or one that allows some topics to be muted more easily) might help.

Discourse appears to come the closest to having the features that would fit the bill—and Van Rossum clearly liked Discourse—though its email integration is not quite there yet for the email-only users. HyperKitty has some of those features on its radar, but has not had the time to implement them. There looks to be some momentum toward an experiment with Discourse, but that will require someone to manage the effort, perhaps to request some funding or assistance from the PSF, and so on. We shall see if that materializes.

There are some free-software projects that still communicate the same way projects have been doing so for decades: plain-text email, perhaps augmented by IRC. Some have branched out and added bug-tracker discussions and web-based forums of various sorts. Finding the right mix to keep existing contributors happy, while attracting new ones, is a delicate matter. We will likely see it play out in other communities as well. There is no "one size fits all" solution here, but seeing what works and doesn't—and why—will be beneficial to others. That is certainly one of the advantages of the free-software ecosystem.

Comments (5 posted)

Quotes of the week

— Pamela Fox

— Greg Ewing

Comments (none posted)

coala 0.4 released

Version 0.4 of the coala static code analyzer has been released. The main changes are the ability to check the commit message of HEAD commits and improvements to the automatic application of scan results.

Comments (none posted)

Toybox 0.7 released

Toybox version 0.7 is now available. Changes include the addition of iotop, top, pgrep, and pkill commands, plus several new switches for existing commands. Work has also begun on vi and dhcp6 commands, although their implementations are still regarded as experimental for now. Users will also be happy to note that the mailing-list archive has now been restored, and that the online documentation has been given a refresh.

Comments (none posted)

Development newsletters from the past week

• What's cooking in git.git (February 2)
• LLVM Weekly (February 1)
• OCaml Weekly News (February 2)
• Perl Weekly (February 1)
• PostgreSQL Weekly News (January 31)
• Python Weekly (January 28)
• Ruby Weekly (January 28)
• This Week in Rust (February 1)
• Tahoe-LAFS Weekly News (January 27)
• Wikimedia Tech News (February 1)

Comments (none posted)

WebExtensions in Firefox 46

At the Mozilla Blog, Andy McKay provides an update on the progress of WebExtension support in Firefox. Several new APIs have been added to the set supported in Firefox, and there is a new mechanism to enable second-level pop-up views. Just as importantly, WebExtensions can now be uploaded to addons.mozilla.org and be signed. "While WebExtensions will remain in an alpha state in Firefox 46, we’ve made lots of progress, with 40 bugs closed since the last update. As of this update, we are still on track for a milestone release in Firefox 48 when it hits Developer Edition."

Comments (none posted)

FSFE Newsletter - February 2016

This edition of the Free Software Foundation Europe newsletter covers FSFE turns 15, Document Freedom Day is given into the hands of the Digital Freedom Foundation, European Parliament votes for more Free Software in the public sector, and several other topics.

Full Story (comments: none)

Free Software Supporter - Issue 94, February 2016

The Free Software Foundation's monthly newsletter looks at the winter fundraiser goal being exceeded, Edward Snowden kicking off LibrePlanet 2016, free software stories, new tools for teaching and learning Email Self-Defense, hardware certified in 2015, Outreachy, and much more.

Full Story (comments: none)

12th Netfilter Workshop

The Netfilter Workshop will take place June 27-July 1 in Amsterdam, Netherlands. "Attendance is free but you require an invitation to participate. You may consider attending if you are involved in any aspect of the Netfilter development, including projects relying on the Netfilter infrastructure such as the Linux Virtual Server (LVS) project. We have a very limited number of invitations this year." The call for participation closes April 15.

Full Story (comments: none)

CFP Deadlines: February 4, 2016 to April 4, 2016

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

Deadline	Event Dates	Event	Location
February 5	April 4 April 6	Embedded Linux Conference	San Diego, CA, USA
February 5	April 4 April 6	OpenIoT Summit	San Diego, CA, USA
February 6	February 12 February 14	Linux Vacation / Eastern Europe Winter Edition 2016	Minsk, Belarus
February 8	April 7 April 8	SRECon16	Santa Clara, CA, USA
February 10	April 23 April 24	LinuxFest Northwest	Bellingham, WA, USA
February 12	May 9 May 13	ApacheCon North America	Vancouver, Canada
February 15	March 11 March 13	Zimowisko Linuksowe TLUG	Puck, Poland
February 23	April 9 April 10	OSS Weekend	Bratislava, Slovakia
February 28	April 6	PostgreSQL and PostGIS, Session #8	Lyon, France
February 28	May 10 May 12	Samba eXPerience 2016	Berlin, Germany
February 28	April 18 April 19	Linux Storage, Filesystem & Memory Management Summit	Raleigh, NC, USA
February 28	June 21 June 22	Deutsche OpenStack Tage	Köln, Deutschland
February 28	June 24 June 25	Hong Kong Open Source Conference 2016	Hong Kong, Hong Kong
March 1	April 23	DevCrowd 2016	Szczecin, Poland
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

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

Events: February 4, 2016 to April 4, 2016

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

Date(s)	Event	Location
February 1 February 5	linux.conf.au	Geelong, Australia
February 5 February 7	DevConf.cz 2016	Brno, Czech Republic
February 10	The Block Chain Conference	San Francisco, CA, USA
February 10 February 12	netdev 1.1	Seville, Spain
February 12 February 14	Linux Vacation / Eastern Europe Winter Edition 2016	Minsk, Belarus
February 24 February 25	AGL Member's Meeting	Tokyo, Japan
February 27	Open Source Days	Copenhagen, Denmark
March 1	Icinga Camp Berlin	Berlin, Germany
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	Zimowisko Linuksowe TLUG	Puck, Poland
March 11 March 13	PyCon SK 2016	Bratislava, Slovakia
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	Chemnitzer Linux Tage 2016	Chemnitz, Germany
March 19 March 20	LibrePlanet	Boston, MA, USA
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

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