LWN.net Weekly Edition for December 24, 2015
The grumpy editor's 2015 retrospective
Welcome to the final LWN.net weekly edition for 2015. As is always the case, it has been a busy year for the free-software community. It has also been a busy year for LWN; among other things, we posted 476 feature articles (57 from outside authors) and reported from no less than 31 conferences. Most readers noticed — and many complained about — the site's new look; that work remains unfinished as we still intend to address some of the issues that have been raised. Happily, few of you noticed the retirement of our eight-year-old production server for something newer, faster, and cloudier. All told, it has been a successful year but we're ready for a brief rest.First, though, there is an important ritual to work through: the review and mocking of your editor's predictions from last January. As usual, some of them came off better than others.
Yes, we heard a lot about the Internet of things, as expected, including many of the unpleasant behaviors that connected things might be expected to show. The (fortunately) short-lived decision by Philips to refuse to interoperate with competing "smart" light bulbs is a case in point; the ongoing revelations of emissions-test cheating in Volkswagen automobiles is a rather more sobering one. The prediction didn't talk about antifeatures, though; instead it focused on size and resource usage. The size constraints that come with connected devices did show themselves and had an influence on kernel development, but we have not, yet, seen the emergence of a credible competitor for Linux on extremely small systems.
Did the OpenStack hype fade as predicted? Hard to say; one still hears a lot about it. Cloud computing as a whole is clearly still on the rise, with many projects and companies trying to own pieces of it.
Your editor declares full accuracy for his prediction that the systemd wars would wind down. For the most part, that particular fight is done and most people are getting on with their lives. Projects like Devuan continue to host mailing lists that serve as hotbeds of snide commentary on systemd and the parentage of its creators, but they have failed, so far, to produce an interesting systemd-free alternative. Meanwhile, the prediction that there would continue to be disagreements about the design of the Linux system in general was so obvious that it better have come true.
Your editor predicted more Heartbleed-level security incidents. In truth, the year may not have been as bad as 2014 with regard to high-profile vulnerabilities, but, even so, names like GHOST, Moose, Logjam, and Stagefright became familiar over the course of the year. The flow of vulnerabilities continues and seems unlikely to slow anytime soon. The related prediction of a slow growth in investment in security seems to have been borne out; we are starting to see efforts like the Core Infrastructure Initiative funding work on some of our higher-profile problems, and some companies are beginning to contribute developers to the task of making our code more secure. But it is just a beginning and, according to some viewpoints anyway, a thoroughly inadequate one.
One might be forgiven for saying that, contrary to prediction, not much happened on the year-2038 front. But, behind the scenes, quite a bit of work is happening (1, 2) to fix year-2038-related problems in various parts of the system and define how the user-space transition is going to work. The other long-horizon projects mentioned did indeed gain some traction; Btrfs is coming into wider use, some distributions are starting to seriously consider a Wayland transition, etc. Some of these projects can take a long time to reach fruition, but they get there eventually.
Your editor predicted that we would see more distributions that are specialized for specific applications. The existing distributions of this type (think of OpenWrt, the network-attached storage distributions, and even distributions like Android or Ubuntu Touch) mostly seem to be going strong, but they do not have a lot of new competition.
Finally, as predicted, civility remains an issue in our community. There has even been some vocal disagreement over the standards of discussion here at LWN. On the wider stage, Linus Torvalds duly produced one of his famous tantrums, reinforcing the kernel community's exaggerated reputation for unfriendliness. On the other side, there has been some pushback from certain quarters against those campaigning for greater civility and inclusiveness in our community. We are far from a consensus on what standards should apply to our interactions with each other.
Then, there are the things your editor should have predicted, but didn't. It's harder to come up with a definitive list of those, of course, but a few things stand out.
2014 saw a new class of security vulnerability; they now come with catchy names, logos, and "security companies" in their trail trying to make money from them. In such an environment, it is natural that we will see a series of overhyped vulnerabilities pushed by people who want to own the next Shellshock. The GHOST vulnerability is an example, as are the headlines circulating as this article is written saying that "any Linux system can be compromised by hitting the backspace key." There are some severe vulnerabilities out there, but people calling a problem severe do not necessarily make it so.
Your editor didn't predict that kdbus would be merged — an outcome that seemed fairly clear given the developers who were behind it. It's just as well, since such a prediction would have been wrong. The decision to back off and rethink the design was a bit of a surprise to some, but it seems like the right one. There should be place for a proper messaging system in the kernel, but it needs to be the right one.
Another unpredicted event was the filing of the VMware GPL-infringement suit. That particular one might have been hard to foresee but, given the increasing level of frustration over GPL violations, it was inevitable that something would be filed one of these years.
A few years back, your editor predicted that the OpenOffice project, newly shifted over to the Apache Software Foundation, would fade away. That was accounted as an incorrect prediction at the end of the year, but it now seems that the real failure was just in the timing. In 2015 it became clear that OpenOffice has nearly lost the ability to move forward, or to even put out releases fixing security issues. The project did finally get a small release out late in the year; it's not at all clear when the next one might happen.
The decision to rebase the openSUSE distribution onto a SUSE Linux Enterprise came as a surprise to your editor. One can argue that something like that should have been evident, given the resources required to keep openSUSE going. But, in the end, openSUSE Leap is an interesting new idea for how a community-oriented distribution can evolve in symbiosis with a supported "enterprise" distribution.
The end of the Ada Initiative was also unforeseen though, again, one might argue that the signs had been there for a while. It seems that there should still be a place in our community for a group trying to increase inclusivity and the diversity of our developer base, but evidently it needs to be a different group.
To close: 2015 was, for the Linux and free software community, a fairly normal year. We have had our ups and downs, but, as a whole, progress toward world domination appears to be mostly on track. Here at LWN, we are proud to have been a small part of it. As we head into the year-end festivities, we wish the best for all of our readers. Thank you for supporting us through our 18th (!) year of operation.
Warsow 2.0: An arena-style first-person shooter game
Running around with lots of guns in cramped quarters has served as a sufficient backdrop for many video games. That's also the premise of "Warsow", an almost entirely open-source first-person shooter (FPS). Where Warsow differs from its competitors is its focus on constant mobility and jumping, leading to a frenetic game where fast reflexes and sharp instincts prevail. Warsow's recent 2.0 release, which comes with a number of improvements, including a tutorial, major graphical enhancements, and changes to weapon power for game balance purposes, makes for a good time to look at how the game has progressed to date.
Warsow's origins lie in "Chasseur de bots" (Hunter of bots), a story (written in French) about the battles of a video game player in a chaotic FPS. The original Chasseur de bots website is no longer available, and only an excerpt from the original story can be found online. Fabrice Demurger, who wrote the Chasseur story, began working on Warsow with the help of a few fellow developers in 2004, lifting the cyberpunk setting and frantic action from the story. Playable characters include punks with dyed hair and pigmen (humanoids with pig heads). Many of the game maps are futuristic, imagining a high-tech industrial world. That technology is embodied in the game's weapons, which include fanciful concepts like laser guns as well as creative takes on familiar armaments like shotguns and grenade launchers.
![[Lasergun]](https://static.lwn.net/images/2015/warsow-weapon-sm.png)
A public 0.1 alpha was released in 2006. In the years to come, Demurger's activity within the project waned, but some of the early developers have stayed on. The project achieved some remarkable successes, including recognition among major online video game leagues as a competitive electronic sport and reviews on television shows. It continues to have a small but dedicated base of players; its timeless gameplay (shoot people before they shoot you) hasn't dulled with age.
Those looking for a single-player story-driven campaign akin to the Half-Life series of FPSes will need to search elsewhere. Warsow is entirely about fast-paced arena fighting, largely in one-on-one duels or in team deathmatches. Players familiar with the famous, multiplayer-oriented Quake series will be right at home.
Success in Warsow doesn't boil down solely to one's aim, but also to how one moves. There are multiple jumping tricks a player needs to take advantage of to win. Some boost speed (such as through strafe-jumping, which is jumping while running sideways), while others allow quick repositioning in a fight (such as via wall-jumping). This need to constantly be mobile can be rather daunting to new players. Fortunately, the 2.0 version comes with an optional tutorial that teaches how best to hop around these arenas.
After downloading the game and running it, the player is prompted to register an account on warsow.gg. This is needed to save statistics (such as accuracy with weapons) and match results. While this is a nice feature, clicking on the prompt takes the player out of the game and into a web browser to fill in account details. Then they have to open their email to click on a confirmation link. It would be a smoother initial experience if a player could register for an account without having to leave the game environment at all.
![[Server selection]](https://static.lwn.net/images/2015/warsow-servers-sm.png)
The small number of players online at any given time harms the overall experience of what is otherwise an impressive, polished game. Most of the time, there's only a handful of active servers to join, some of them with less-than-forgiving latency (I encountered one with 140+ millisecond ping, which some hardcore players would consider to be unacceptable). There is also no guarantee that the players will stay for another round after one is finished, leaving the player searching for another server. The small population hurts the dueling modes the most, where players go head-to-head, one-versus-one. Joining one such server, I spent eight minutes spectating the match being played to wait for the next round. Then everyone left and I had no one to play with.
Waiting is only one pain point of a small server. An unavoidable problem when the number of players is small is imbalanced matchmaking, where experienced players find themselves matched against people new to the game. After I joined another server and waited another seven minutes (leaving me with an effective overall queue of 15 minutes), I got matched against someone who mopped the floor with me. Right after that, I completely stomped my next opponent. Both of these matches occurred on the same ranked server; successes and/or failures on such servers are added to the statistics on one's public-facing profile (see an example here) that detail how accomplished one is.
![[Fight]](https://static.lwn.net/images/2015/warsow-fight-sm.png)
Nonetheless, the game is still lots of fun. It's intense: there are nine weapons to choose from, including a short-range Riotgun (i.e. shotgun), a medium-range Plasmagun for spreading fire over an area, and the overall reliable long-range Rocket Launcher (which can also boost one's jumps if correctly timed). In some modes, all of the weapons are available when one spawns (i.e. begins the game or is resurrected following death). In others, one begins with a weak Gunblade (which serves the purpose of both pistol and knife in one device) and must collect ammunition and weapons around the map. These weapons can be instantly switched at the press of a button. Success in combat against opponents of similar skill is gratifying; one gets a sense of accomplishment from hopping around nimbly to dodge enemy fire and instinctively swapping to the right weapon at the right time to secure a kill.
Until the 2.0 version, Warsow had an awkward licensing
regime. While the game
engine's codebase was (and is) available under GPLv2-or-later, a
proprietary "Warsow Content License", effectively allowing only
redistribution, applied to all the media assets. Furthermore, outside
contributors had to accept a poorly-written "Contribution License
Agreement". It specified that any submitted "game rules" (not adequately
defined in the license) became the property of "Chasseur de bots" (a
now-defunct association that held the assets). The copyright to any
contributed media assets were also assigned, but the contributor retained
the right to "display the work as part of a personal
portfolio
". Recently, the active development team contacted the old
Chasseur de bots members as well as most of the past contributors (some
were unable to be reached) to ask for a relicense. With their agreement,
all the art assets, with the exception of some sound effects (mostly that
of weapons firing and the grunts of the player's character) and some map
textures, are now available under the copyleft Creative Commons
Attribution-ShareAlike 4.0 International License. The development team
is looking to replace any assets that are not licensed CC BY-SA to make the
game fully open-source.
2.0 comes with much more than a licensing update. There have been major
gameplay balance changes, including an increase in damage to a number of
weapons as well as adding more consistency in recoil and "splash radius"
(i.e. the area-of-effect in which a launched grenade or rocket will cause
damage). Linux versions now use Simple
DirectMedia Layer 2 for video. HTTPS has been mandated for
matchmaking, which is a welcome change for security-conscious players. 2.0
also takes better advantage of multi-threading to address a number of
previous issues, including latency in gameplay, some unpleasant race
conditions, and slow load times. The renderer is much better, boasting a
"30% to 50% overall performance improvement
". Changes to the
graphics, including weapon effects, bullet models, and textures for
playable characters, make the game feel more modern. The game is also
available in nine additional languages. The full list of changes can be found here.
There is lots of room for new contributors looking to help out. Both the client and the server (which share the same repository) are freely-licensed and written in C, C++, and AngelScript, which is a popular object-oriented scripting language for video game development. The Warsow developers provide an SDK [.tar.gz], which comes with the full source code of the game, documentation, and tools (including build scripts). The "sourcecode_quickstart" file sums up the fundamentals of the source code's structure, with a helpful opening section:
This means, that there is 1 major loop handling all application logic. This called a 'state machine' design, which can be confusing when you [are] used to straight-forward procedural or object-oriented programming.
This may sound pretty abstract, but this is due to the fact that Warsow is a client AND a server with exactly the same sourcecode. This means that in the big lines, the same steps are taken for both the client and the server. Of course, once digging deeper into the code, things will start looking very different, since the server is the one who actually makes all decisions, sends state-changes and events to the client (or clients), who then alter their local state and implement it (as in: build the scene and render it)."
The developer team has stated that level designers, computer programmers (particularly those with a good grasp for game engines), 3D artists, translators, and a community manager would be great additions. Some of the goals going forward for Warsow 3.0 are a release of a version for the Steam video game marketplace as well as updating the game's visuals. There is no mailing list but discussions on the official forums are fairly active. One can also contribute by submitting pull requests at the project's GitHub repositories. It's unclear when 3.0 will arrive, but given that the previous major release arrived a year and a half ago, a mid-year 2017 release seems like a reasonable guess.
For those interested in playing, or contributing to, a modern first-person shooter, Warsow might just be the right choice.
Panopticlick 2
The Electronic Frontier Foundation (EFF) has rolled out a major update to its online browser-fingerprinting tool Panopticlick. The tool's site lets visitors perform a scan to assess how uniquely identifiable their web browser is among all web traffic—although, in the past, the EFF has also used the same code to research the fingerprinting of web browsers en masse. The new update, dubbed Panopticlick 2.0, adds new tests to gauge a browser's ad-blocking, tracker-blocking, and "Do Not Track" performance, and it has been designed to function better on mobile web browsers.
Uniqueness again
The first version of Panopticlick was unveiled in 2010. At that time, the EFF reported that approximately 84% of individual users' browsers could be uniquely identified without any use of login credentials, cookies, or other stateful mechanisms. Rather, Panopticlick assembled a "fingerprint" of each browser using only passive configuration information: the details revealed in the User-Agent string, the list of plugins and fonts installed, various localization settings, window and session properties accessible through CSS queries, and so forth.
Panopticlick's 2015 update adds some new fingerprinting tests, such as the HTML <canvas> fingerprinting technique first publicized in 2014 and a check for touchscreen support. In the HTML <canvas> test (and its WebGL cousin), the Panopticlick code renders a hidden image (using the HTML or WebGL <canvas> element), then hashes the result. The variations in the display, graphics stack, and text-rendering settings of the client machine combine to make each such image slightly different. The touch-support test captures whether touch events are supported, plus whether the onTouchStart JavaScript event is supported and the number of touch points reported by the hardware.
When combined, all of the fingerprinting tests amount to a profile of the user's browser. The Panopticlick test site lets users see how many of the other browsers that have visited the site reported the same information on each test, plus how many "bits" of uniqueness accumulate from each test. The later number is the binary logarithm of the former, so interpreting it meaningfully can take some thought. At the moment, there have been about 6.2 million visitors, so any test that gives a unique result is reported as equating to (rounded) 22.57 bits. As more site visitors run the test battery, those numbers will fluctuate.
For instance, my "Browser Plugin Details" list—which enumerates all of the codec- and version-compatibility information reported for each installed plugin—hit the maximum of 22.57 bits, even though all of my browser plugins come directly from my distribution repository. But I am inconsistent about updating them; if all were refreshed to the latest release, the uniqueness of the "Browser Plugin Details" would doubtless go down. In contrast, I work on font projects, so my list of installed fonts (which also hit the maximum of 22.57) includes fonts that I built locally. Thus, it is essentially guaranteed to be unique, a factor that is out of the browser developers' hands. On the other hand, the local font list can and does change from one day to the next, which limits its effectiveness in tracking the browser across sessions. Whether or not the browser ought to report either of these configurations to remote servers is an open question.
Privacy dipstick
The bigger change in Panopticlick 2.0 is the addition of tests that measure key privacy features of the user's browser. These tests do not factor into the unique browser-fingerprint computation at all, but they are clearly of value to users interested in privacy and anonymity. The tests employ HTTP requests that match the filters from first- and third-party ad-blocking and tracker-blocking tools. The EFF runs a set of test servers on domains to ensure that Panopticlick can test the full variety of ad and tracker options. One of these test domains is set up to advertise the EFF's privacy-friendly Do Not Track header policy, in order to test whether or not the browser un-blocks that domain in response to the policy.
The Panopticlick site notes that it takes steps to ensure that its phony tracker domains (e.g., eviltracker.net) are included in the blacklists used by popular URL-based blocking extensions like Disconnect, and that the phony trackers conform to patterns caught by the heuristic algorithm used by the EFF's own Privacy Badger extension. The results reported to the user are a brief table of "yes" and "no" results.
The fingerprinting score is likely to be of more interest to users well-versed in online privacy. Finally, the site provides a list of suggested countermeasures. Unfortunately, the list is rather brief—it amounts to "use Tor Browser, disable JavaScript, and don't use a 'rare' browser if you can avoid it." A more detailed examination of the issues—for example, look at how to disable JavaScript localStorage or set a nondescript User-Agent string—would be a worthwhile and welcome addition.
The future
If the 2010 release of the initial Panopticlick is any guide, the community should expect the EFF to conduct its own research into the state of browser fingerprinting and produce some hard numbers. A few months after the 2010 announcement of Panopticlick, EFF Senior Technologist Peter Eckersley published a paper [PDF] summarizing the data seen by Panopticlick and characterizing its privacy implications. Even if a new study is a long time in coming from the EFF, though, interested parties can take matters into their own hands. Unlike with the 2010 release, the Panopticlick source code is available on GitHub. It will be interesting to see what others do with the code.
Sadly, in the long run, Panopticlick may only be useful to end users as a canary in the coal mine—that is, to raise awareness that disabling ads and tracking beacons is not enough to guard against a party determined to identify and profile users online, and not as a weapon to find and disable privacy-leaking features in a browser. That is because most of the data points used to assemble a Panopticlick-style browser fingerprint cannot fully be suppressed. Every setting or preference that can be communicated between the client and a web server contributes incrementally to the formula.
One can always argue about where to draw the line, suggesting that
too many new web APIs are being implemented, each of which increases
the chance of a browser being fingerprinted. But the public wants
functionality from its mobile and desktop browsers, and that trend is
not likely to stop. Google's Chrome/Chromium team has evidently made
up its mind that combating browser fingerprinting is a lost cause; the
project's FAQ notes
that "defeating such fingerprinting is likely not practical
without fundamental changes to how the Web works.
" Roughly 33
bits are required to uniquely identify a browser from the global
population, the FAQ states, and disabling APIs is not be enough to
reduce each browser's fingerprint to below that threshold.
Interest in the topic appears to be somewhat higher at Mozilla; a tracking bug was filed after the 2010 Panopticlick release and a wiki page created to discuss reducing the "fingerprintability" of Firefox (although the information there is no longer up to date). More recently, issues have been raised to deal with specific information leaks, including the <canvas> attack, the WebSpeech API, the installed-font list, and the plugin list. A number of the proposed solutions come from the Tor Browser.
Certainly any egregious information leaks from the browser should be patched, but there is a lot less consensus on how much fingerprint resistance users have a right to expect from a browser running in its default mode. After all, when privacy and anonymity are paramount, the tools do exist for users to enable private browsing, disable JavaScript, or switch over to Tor. Perhaps that is enough, and it needs to be left up to the user to know in which situations access to the latest and greatest web features stops being important and privacy concerns take center stage.
For the time being, the updated Panopticlick can at least enable users to get a clearer picture of the uniqueness of their browser and the impact of various privacy settings on its fingerprint. And educating the user is ultimately the best course of action.
Security
Cracking Linux with the backspace key?
Anybody who has been paying attention to the net over the last week or so will certainly have noticed an abundance of articles with titles like "How to hack any Linux machine just using backspace". All this press does indeed highlight an important vulnerability, but it may not be the one that they think they are talking about.
The source of these reports is a
mildly
hype-ridden disclosure of a vulnerability in the GRUB2 bootloader by
Hector Marco and Ismael Ripoll. It seems that hitting the backspace
character at the GRUB2 username prompt enough times will trigger an integer
underflow, allowing a bypass of GRUB2's authentication stage. According to
the authors, this vulnerability, exploitable for denial-of-service,
information-disclosure, and code-execution attacks, "results in an
incalculable number of
affected devices.
" It is indeed a serious vulnerability in some
settings and it needs to be fixed. Unfortunately, some of the most
severely affected systems may also be the hardest to patch. But language
like the above leads reporters to write that any Linux system can be broken
into using the backspace key, which stretches the truth somewhat.
It is worth looking at what is required to actually exploit this vulnerability. The conditions are:
- An attacker must have physical access to the system's console to be
able to type the famous backspaces. In general, once an attacker can
actually put hands onto a target system, the game is already lost.
That is no excuse for a trivially exploited vulnerability in the
bootloader's authentication code, but it does add a bit of
perspective. Note that you may have physical access to the
Linux-based entertainment system in your airplane seat, but you almost
certainly lack access to the console.
- The attacker must be able to reach the bootloader's authentication
prompt. That generally means being able to force a running Linux
system to reboot so that the bootloader actually runs. If the system
is configured to allow unprivileged users to cause a reboot, then
complaints of "denial of service" are already moot; service can be
denied at any time. Of course, that can also be done by pulling the
plug since, as has already been noted, the attacker has physical
access to the system.
- The system must be running the GRUB2 bootloader. If it's an x86
system, chances are that it is indeed GRUB2 that is installed there.
Other architectures tend to use other bootloaders, though. Many of
the embedded systems that might be most at risk from this type of
vulnerability will thus not be running the vulnerable software.
- The bootloader must actually be configured for password-based access.
While lacking hard data, your editor would guess that a small minority
of systems booting with GRUB2 have passwords set on them. In most
cases, simply rebooting allows full access to the bootloader and its
capabilities — no exploit required.
- The system must be running an exploitable version of GRUB2. This part is relatively easy — the vulnerability has been present since version 1.98, released in late 2009.
Given the above, it seems unlikely that this vulnerability has exposed "any Linux system" to attack. Instead, it has exposed a small number of systems that are configured with bootloader security, but that also allow physical access to a console keyboard. For some of those systems, this vulnerability constitutes a true emergency. For most of us, though, there is no particular need to go into red alert.
There is a different vulnerability that has been exposed here, though, that is somewhat more severe. Anybody who reads the mainstream technical press now "knows" that any Linux system can be broken into by pressing a single key a few times. Linux security has been exposed as a laughable joke; how can anybody take such a system seriously?
In other words, all it takes is a couple of researchers who are able to turn up a bug, create a logo and a cute name ("Back to 28" in this case) for it, and post it as a "zero-day vulnerability" to create a storm of mocking bad publicity for Linux. Relative to, say, the Juniper firewall backdoor, disclosed at about the same time, the GRUB2 issue is minor indeed. But "28 backspaces" makes for good headlines, so it may well be that more people know about the GRUB2 vulnerability than the "unauthorized code" in security-critical Juniper products. It's bad enough when, as happens all too often, we are justly lambasted for security problems affecting large numbers of users; to be taken to task for this one is just kind of sad.
Arguably, we have just seen an exploit of a vulnerability in our public-relations system: any attacker with a "zero-day" bug and some minimal marketing skills can cause untold damage to the image of Linux as a whole. Companies deal with such issues by firing up their own PR machines, but Linux does not really have any such thing. So we are stuck trying to patch up our reputation after the fact, hoping that at least some members of the press will eventually figure out that, in fact, you really can't hack into any Linux system by hitting the backspace key.
Brief items
Security quotes of the week
They don't always get it right—the sad history of copyright law in the United States is an example of how they can get it badly wrong again and again—but at least they had a chance before the technologies become widely adopted.
That's just not true anymore. A new technology can go from zero to a hundred million users in a year or less. That's just too fast for the political or legal process. By the time they're asked to make rules, these technologies are well-entrenched in society.
Green: On the Juniper backdoor
Here's an interesting article from cryptographer Matthew Green on how the Juniper backdoor is the least interesting part of this whole episode. "Thus Dual EC is safe only if you assume no tiny bug in the code could accidentally leak out 30 bytes or so of raw Dual EC output. If it did, this would make all subsequent seeding calls predictable, and thus render all numbers generated by the system predictable. In general, this would spell doom for the confidentiality of VPN connections. And unbelievably, amazingly, who coulda thunk it, it appears that such a bug does exist in many versions of ScreenOS, dating to both before and after the 'unauthorized code' noted by Juniper."
New vulnerabilities
blueman: privilege escalation
| Package(s): | blueman | CVE #(s): | CVE-2015-8612 | ||||||||||||||||
| Created: | December 21, 2015 | Updated: | January 26, 2016 | ||||||||||||||||
| Description: | From the Debian advisory:
It was discovered that the Mechanism plugin of Blueman, a graphical Bluetooth manager, allows local privilege escalation. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
cacti: SQL injection
| Package(s): | cacti | CVE #(s): | CVE-2015-8369 | ||||||||||||||||||||||||||||||||||||||||
| Created: | December 17, 2015 | Updated: | January 4, 2016 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Several SQL injection vulnerabilities have been discovered in Cacti, an RRDTool frontend written in PHP. Specially crafted input can be used by an attacker in the rra_id value of the graph.php script to execute arbitrary SQL commands on the database. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
chromium: code execution
| Package(s): | chromium-browser | CVE #(s): | CVE-2015-6792 | ||||||||||||||||||||||||
| Created: | December 18, 2015 | Updated: | December 23, 2015 | ||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
Two flaws were found in the processing of malformed web content. A web page containing malicious content could cause Chromium to crash, execute arbitrary code, or disclose sensitive information when visited by the victim. (CVE-2015-6792) | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
claws-mail: code execution
| Package(s): | claws-mail | CVE #(s): | CVE-2015-8614 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 23, 2015 | Updated: | February 17, 2016 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Arch Linux advisory:
A remotely triggerable buffer overflow has been found in the code of claws-mail handling character conversion, in functions conv_jistoeuc(), conv_euctojis() and conv_sjistoeuc(), in codeconv.c. There was no bounds checking on buffers passed to these functions, some stack-based but other potentially heap-based. This issue has been located in the wild and might currently be exploited. A remote attacker might be able to execute arbitrary code on the affected host by sending a crafted e-mail to a claws-mail user. | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
director: two vulnerabilities
| Package(s): | RHELOSP7 director | CVE #(s): | CVE-2015-5303 CVE-2015-5329 | ||||
| Created: | December 22, 2015 | Updated: | December 23, 2015 | ||||
| Description: | From the Red Hat advisory:
It was discovered that the director's NeutronMetadataProxySharedSecret parameter remained specified at the default value of 'unset'. This value is used by OpenStack Networking to sign instance headers; if unchanged, an attacker knowing the shared secret could use this flaw to spoof OpenStack Networking metadata requests. (CVE-2015-5303) A flaw was found in the director (openstack-tripleo-heat-templates) where the RabbitMQ credentials defaulted to guest/guest and supplied values in the configuration were not used. As a result, all deployed overclouds used the same credentials (guest/guest). A remote, non-authenticated attacker could use this flaw to access RabbitMQ services in the deployed cloud. (CVE-2015-5329) | ||||||
| Alerts: |
| ||||||
ipython: code execution
| Package(s): | ipython | CVE #(s): | CVE-2015-7337 | ||||
| Created: | December 18, 2015 | Updated: | December 23, 2015 | ||||
| Description: | From the Gentoo advisory:
A remote attacker could entice a user to open a specially crafted text file using IPython, possibly resulting in execution of arbitrary JavaScript with the privileges of the process. | ||||||
| Alerts: |
| ||||||
kernel: information disclosure
| Package(s): | kernel | CVE #(s): | CVE-2015-7885 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 17, 2015 | Updated: | December 23, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Ubuntu advisory:
It was discovered that the driver for Digi Neo and ClassicBoard devices did not properly initialize data structures. A local attacker could use this to obtain sensitive information from the kernel. (CVE-2015-7885) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: information disclosure
| Package(s): | kernel | CVE #(s): | CVE-2015-7884 | ||||||||||||||||||||||||||||||||
| Created: | December 17, 2015 | Updated: | December 23, 2015 | ||||||||||||||||||||||||||||||||
| Description: | From the Ubuntu advisory:
It was discovered that the virtual video osd test driver in the Linux kernel did not properly initialize data structures. A local attacker could use this to obtain sensitive information from the kernel. (CVE-2015-7884) | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
kernel: denial of service
| Package(s): | kernel | CVE #(s): | CVE-2015-8543 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 18, 2015 | Updated: | December 23, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
CVE-2015-8543: It was discovered that a local user permitted to create raw sockets could cause a denial-of-service by specifying an invalid protocol number for the socket. The attacker must have the CAP_NET_RAW capability in their user namespace. This has been fixed for the stable distribution (jessie) only. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: denial of service
| Package(s): | kernel | CVE #(s): | CVE-2015-8215 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 18, 2015 | Updated: | December 23, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the SUSE advisory:
CVE-2015-8215: net/ipv6/addrconf.c in the IPv6 stack in the Linux kernel did not validate attempted changes to the MTU value, which allowed context-dependent attackers to cause a denial of service (packet loss) via a value that is (1) smaller than the minimum compliant value or (2) larger than the MTU of an interface, as demonstrated by a Router Advertisement (RA) message that is not validated by a daemon, a different vulnerability than CVE-2015-0272. (bsc#955354) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: multiple vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2015-8550 CVE-2015-8551 CVE-2015-8552 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 21, 2015 | Updated: | December 23, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Ubuntu advisory:
Felix Wilhelm discovered a race condition in the Xen paravirtualized drivers which can cause double fetch vulnerabilities. An attacker in the paravirtualized guest could exploit this flaw to cause a denial of service (crash the host) or potentially execute arbitrary code on the host. (CVE-2015-8550) Konrad Rzeszutek Wilk discovered the Xen PCI backend driver does not perform sanity checks on the device's state. An attacker could exploit this flaw to cause a denial of service (NULL dereference) on the host. (CVE-2015-8551) Konrad Rzeszutek Wilk discovered the Xen PCI backend driver does not perform sanity checks on the device's state. An attacker could exploit this flaw to cause a denial of service by flooding the logging system with WARN() messages causing the initial domain to exhaust disk space. (CVE-2015-8552) Jann Horn discovered a ptrace issue with user namespaces in the Linux kernel. The namespace owner could potentially exploit this flaw by ptracing a root owned process entering the user namespace to elevate its privileges and potentially gain access outside of the namespace. (http://bugs.launchpad.net/bugs/1527374) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: denial of service
| Package(s): | kernel | CVE #(s): | CVE-2015-7550 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 22, 2015 | Updated: | February 23, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
A race between revoking a user-type key and reading from it was found, causing the kernel to crash. This race can be triggered by unprivileged user. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: denial of service
| Package(s): | kernel | CVE #(s): | CVE-2015-7509 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 22, 2015 | Updated: | December 23, 2015 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the SUSE advisory:
Mounting ext4 filesystems in no-journal mode could have lead to a system crash. | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
libldb: remote memory disclosure
| Package(s): | libldb | CVE #(s): | CVE-2015-5330 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 18, 2015 | Updated: | December 23, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla entry:
It was reported that when adding an LDB DN to the database, that if a \00 (null byte) is used, remote memory can be read due to a combination of talloc_strdup() and a length assignment. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
libpng: read underflow
| Package(s): | libpng | CVE #(s): | CVE-2015-8540 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 18, 2015 | Updated: | October 31, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the libpng bug report:
there is a underflow read in png_check_keyword in pngwutil.c in libpng-1.2.54. if the data of "key" is only ' ' (0x20), it will read a byte before the buffer in line 1288, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
openstack-nova: insecure VM instances
| Package(s): | openstack-nova | CVE #(s): | CVE-2015-7713 | ||||||||||||||||
| Created: | December 22, 2015 | Updated: | December 23, 2015 | ||||||||||||||||
| Description: | From the Red Hat advisory:
A vulnerability was discovered in the way OpenStack Compute (nova) networking handled security group updates; changes were not applied to already running VM instances. A remote attacker could use this flaw to access running VM instances. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
python2-pyamf: denial of service
| Package(s): | python2-pyamf | CVE #(s): | CVE-2015-8549 | ||||
| Created: | December 18, 2015 | Updated: | December 23, 2015 | ||||
| Description: | From the Arch Linux advisory:
PyAMF suffers from insufficient AMF input payload sanitization which results in the XML parser not preventing the processing of XML external entities (XXE). A specially crafted AMF payload, containing malicious references to XML external entities, can be used to trigger denial of service (DoS) conditions or arbitrarily return the contents of files that are accessible with the running application privileges. A remote attacker is able to craft special XML files that, when processed, are injecting external entities resulting in denial of service of disclosure of arbitrary file contents. | ||||||
| Alerts: |
| ||||||
quassel: denial of service
| Package(s): | quassel | CVE #(s): | CVE-2015-8547 | ||||||||||||||||
| Created: | December 17, 2015 | Updated: | January 6, 2016 | ||||||||||||||||
| Description: | From the Mageia advisory:
The Quassel core could be crashed by a client using the op command, causing a denial of service (CVE-2015-8547). | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
ruby: code execution
| Package(s): | ruby | CVE #(s): | CVE-2015-7551 | ||||||||||||||||
| Created: | December 17, 2015 | Updated: | January 12, 2016 | ||||||||||||||||
| Description: | There is an unsafe tainted string vulnerability in Fiddle and DL. This
issue was originally reported and fixed with CVE-2009-5147 in DL, but
reappeared after DL was reimplemented using Fiddle and libffi.
A remote attacker is able to open a library via Fiddle with tainted library name if passed from an untrusted input. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
rubygem-passenger: environment variable injection
| Package(s): | rubygem-passenger | CVE #(s): | CVE-2015-7519 | ||||||||
| Created: | December 22, 2015 | Updated: | January 19, 2016 | ||||||||
| Description: | From the SUSE advisory:
rubygem-passenger was not filtering the environment like apache is doing, allowing injection of environment variables. | ||||||||||
| Alerts: |
| ||||||||||
samba: multiple vulnerabilities
| Package(s): | samba | CVE #(s): | CVE-2015-5299 CVE-2015-7540 CVE-2015-3223 CVE-2015-5252 CVE-2015-5296 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 18, 2015 | Updated: | January 4, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla entries:
CVE-2015-5299: Samba: Missing access control check in shadow copy code CVE-2015-7540: samba: DoS to AD-DC due to insufficient checking of asn1 memory allocation CVE-2015-3223: samba: Remote DoS in Samba (AD) LDAP server CVE-2015-5252: samba: Insufficient symlink verification in smbd CVE-2015-5296: samba: Samba client requesting encryption vulnerable to downgrade attack. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
sosreport: two vulnerabilities
| Package(s): | sosreport | CVE #(s): | CVE-2014-3925 CVE-2015-7529 | ||||||||||||||||||||||||||||||||||||||||
| Created: | December 18, 2015 | Updated: | February 17, 2016 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the Ubuntu advisory:
Dolev Farhi discovered an information disclosure issue in SoS. If the /etc/fstab file contained passwords, the passwords were included in the SoS report. This issue only affected Ubuntu 14.04 LTS. (CVE-2014-3925) Mateusz Guzik discovered that SoS incorrectly handled temporary files. A local attacker could possibly use this issue to overwrite arbitrary files or gain access to temporary file contents containing sensitive system information. (CVE-2015-7529) | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
subversion: code execution
| Package(s): | subversion | CVE #(s): | CVE-2015-5343 | ||||||||||||||||||||||||||||
| Created: | December 17, 2015 | Updated: | April 6, 2016 | ||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Ivan Zhakov discovered an integer overflow in mod_dav_svn, which allows an attacker with write access to the server to execute arbitrary code or cause a denial of service. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
subversion: code execution
| Package(s): | subversion | CVE #(s): | CVE-2015-5259 | ||||||||||||
| Created: | December 23, 2015 | Updated: | December 23, 2015 | ||||||||||||
| Description: | From the Red Hat bugzilla:
Subversion servers and clients are vulnerable to a remotely triggerable heap-based buffer overflow and out-of-bounds read caused by an integer overflow in the svn:// protocol parser. This allows remote attackers to cause a denial of service or possibly execute arbitrary code under the context of the targeted process. | ||||||||||||||
| Alerts: |
| ||||||||||||||
tryton-server: access check bypass
| Package(s): | tryton-server | CVE #(s): | CVE-2015-0861 | ||||
| Created: | December 17, 2015 | Updated: | December 23, 2015 | ||||
| Description: | From the Debian advisory:
Cédric Krier discovered a vulnerability in the server-side of Tryton, an application framework written in Python. An aunthenticated malicious user can write arbitrary values in record fields due missed checks of access permissions when multiple records are written. | ||||||
| Alerts: |
| ||||||
xen: multiple vulnerabilities
| Package(s): | xen | CVE #(s): | CVE-2015-8338 CVE-2015-8339 CVE-2015-8340 CVE-2015-8341 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 17, 2015 | Updated: | December 23, 2015 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Fedora advisory:
Bug #1285350 - xen: Virtual Performance Measurement Unit feature is unsupported https://bugzilla.redhat.com/show_bug.cgi?id=1285350 Bug #1284933 - CVE-2015-8341 xen: libxl leak of PV kernel can cause OOM condition https://bugzilla.redhat.com/show_bug.cgi?id=1284933 Bug #1284919 - CVE-2015-8339 CVE-2015-8340 xen: XENMEM_exchange error handling may cause DoS to host https://bugzilla.redhat.com/show_bug.cgi?id=1284919 Bug #1284911 - CVE-2015-8338 xen: Long running memory operations on ARM cause DoS https://bugzilla.redhat.com/show_bug.cgi?id=1284911 | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
xen: two vulnerabilities
| Package(s): | xen | CVE #(s): | CVE-2015-8554 CVE-2015-8555 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 23, 2015 | Updated: | December 23, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
1289129: "qemu-xen-traditional" (aka qemu-dm) tracks state for each MSI-X table entry of a passed through device. This is used/updated on (intercepted) accesses to the page(s) containing the MSI-X table. There may be space on the final page not covered by any MSI-X table entry, but memory for state tracking is allocated only for existing table entries. Therefore bounds checks are required to avoid accessing/corrupting unrelated heap memory. Such a check is present for the read path, but was missing for the write path. A malicious administrator of a guest which has access to a passed through PCI device which is MSI-X capable can exploit this vulnerability to take over the qemu process, elevating its privilege to that of the qemu process. In a system not using a device model stub domain (or other techniques for deprivileging qemu), the malicious guest administrator can thus elevate their privilege to that of the host. (CVE-2015-8554) 1289130: When XSAVE/XRSTOR are not in use by Xen to manage guest extended register state, the initial values in the FPU stack and XMM registers seen by the guest upon first use are those left there by the previous user of those registers. A malicious domain may be able to leverage this to obtain sensitive information such as cryptographic keys from another domain. (CVE-2015-8555) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
xsupplicant: insecure temporary files
| Package(s): | xsupplicant | CVE #(s): | |||||||||
| Created: | December 21, 2015 | Updated: | December 23, 2015 | ||||||||
| Description: | From the Red Hat bugzilla:
It was found that xsupplicant uses hardcoded fixed temporary file for sockets, storing into /tmp/xsupplicant.sock.$INTERFACE. | ||||||||||
| Alerts: |
| ||||||||||
Page editor: Jake Edge
Kernel development
Brief items
Kernel release status
The current development kernel is 4.4-rc6, released on December 20. Linus said: "Things remain fairly normal. Last week rc5 was very small indeed, this week we have a slightly bigger rc6. The main difference is that rc6 had a network pull in it."
Stable updates: none have been released in the last week.
Quote of the week
Kernel development news
An (unsigned) long story about page allocation
The kernel project is famously willing to change any internal interface as needed for the long-term maintainability of the code. Effects on out-of-tree modules or other external code are not generally deemed to be reasons to keep an interface stable. But what happens if you want to change one of the oldest interfaces found within the kernel — one with many hundreds of call sites? It turns out that, in 2015, the appetite for interface churn may not be what it once was.If one looks at mm/memory.c in the Linux 0.01 release, one finds that a page of memory is allocated with:
unsigned long get_free_page(void);
From the memory-management point of view, the system's RAM can be seen as a linear array of pages, so it can make a certain amount of sense to think of addresses as integer types — indexes into the array, essentially. Integers can also be used for arbitrary arithmetic; pointers in C can be used that way too, but one quickly gets into "undefined behavior" territory where an overly enthusiastic compiler may feel entitled to create all kinds of mayhem. So unsigned long was established as the return type from get_free_page() and, in general, as the way that one refers to an address that may appear in any place in memory.
Fast-forward to the 4.4-rc6 release and dig through a rather larger body of code, and one finds that pages are allocated with:
unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order);
unsigned long __get_free_page(gfp_t gfp_mask);
The latter is a macro calling the former with an order of zero. Note that, more than 24 years after the 0.01 release, unsigned long is still used as the return type from __get_free_pages(). There are other variants (alloc_pages(), for example) that return struct page pointers, but much of low-level, page-oriented memory management in Linux is still done with unsigned long values.
The only problem is that, often, the kernel must deal with a page of memory as memory, modifying its contents. That requires a pointer. So even back in 0.01, one can find code like:
p = (struct task_struct *) get_free_page();
The unsigned long return value is immediately cast into the
pointer value that is actually needed.
Al Viro did a survey of __get_free_pages() users in current
kernels and concluded that "well
above 90%
" of the callers were using the return value as a pointer.
That turns out to be a lot of casts, suggesting that the type of the
return value for this function is not correct. So, he suggested, it might
make sense to change it:
Some of those bugs, he pointed out, he found simply by looking at the code with this kind of transformation in mind. Ten days later, he showed up with a patch set making the change and asked for a verdict from Linus.
One might find various faults with Linus's
response, but a lack of clarity will not be among them. He left no
doubt that there was no place in the mainline for this particular patch
set. The diffstat in Al's patch (568 files changed, 1956 insertions, 2202
deletions) was clearly frightening — enough, in its own right, to rule
out the change. A patch this wide-ranging would create conflicts
throughout the tree and make life difficult for those backporting patches.
This interface, it seems, is too old and too entrenched for this kind of
flag-day change; as Linus put it: "No way in hell do we suddenly
change the semantics of an interface that has been around from basically
day #1.
"
Still, as he clarified afterward, Linus isn't arguing for leaving everything exactly as it is. He accepted that most callers likely want a pointer value. But the way forward isn't to thrash up an interface like __get_free_pages(); instead, there are two approaches that, he said, could be taken.
The first of these would be to create a new, pointer-oriented interface that exists in parallel with __get_free_pages(). Then call sites could be converted at leisure over the course of what would probably be years.
The alternative, Linus said, is that code needing pointers could just allocate memory with kmalloc() instead. Once upon a time, that would not necessarily have been a good idea, since kmalloc() (implemented by the slab allocators) adds overhead to the page allocator and might have expanded the size of the returned memory beyond one page. Indeed, there was a period where an allocation of exactly one page would have consumed two physically contiguous pages when the slab housekeeping information was added. But those days are long in the past. In current kernels, kmalloc() is fast and requires little memory beyond that which is actually allocated. Indeed, Linus pointed out, kmalloc() may actually be faster than __get_free_pages() due to its use of per-CPU object caches.
So kmalloc() is probably the best option for many of the
call sites currently using __get_free_pages(). The places where
it is still inappropriate will be those needing multiple-page allocations
and those needing allocations that are not only page-sized but
page-aligned. In those cases, Linus said, the unsigned long
return type might not be a bad thing, since "it's clearly not just a
random pointer allocation if the bit pattern of the pointer
matters.
"
After this discussion took place, Al did a pass over the __get_free_pages() call sites in the filesystem code and concluded that almost all of them truly would would be better off using kmalloc(). So the end result of this work may be a slow shift in that direction and, perhaps, the creation of a new document telling kernel developers which memory allocator they should be using in which setting.
Two PaX features move toward the mainline
As the Kernel self-protection project (KSPP) ramps up in the month and a half since its formation, several features from the PaX project are starting their journey toward the mainline. The reception on the kernel-hardening mailing list that is being used to coordinate KSPP work has been positive, but the real test for these features will come when they are proposed for the mainline. Two specific patch sets have been posted recently, for PAX_REFCOUNT and PAX_MEMORY_SANITIZE, that we will look at here.
PAX_REFCOUNT
The idea behind the PAX_REFCOUNT patch set, posted by David Windsor, is to detect and handle overflows in reference-count variables. The kernel uses reference counts to track objects that have been allocated, incrementing or decrementing the count as references to them come and go; the kernel frees those objects when the count reaches zero. But if there is a path in the kernel where the count doesn't get decremented when an object reference gets dropped, an attacker could use that path to overflow and wrap the reference counter, effectively setting it to zero when there are actually still valid references to it. The object will be freed, but will still be used by those with references, leading to a use-after-free vulnerability.
This is not the first attempt to add this kind of overflow protection to the kernel. But when Windsor posted about a related idea for kref, which is a kernel abstraction for reference counts, back in 2012, the idea ran aground on how it handled the overflows. Like the original PaX patches, Windsor's patch would call BUG_ON() for reference counts that reached INT_MAX, instead of incrementing them. That would crash the kernel if the count ever reaches INT_MAX, which Greg Kroah-Hartman objected to:
And people wonder why I no longer have any hair...
But as Windsor and others pointed out, there is no sensible recovery that can be done if a reference count is about to wrap. An alternative might be to simply not change the counter (and put a warning into the kernel log) once it reaches INT_MAX, but that would lead to a memory leak. Overall, at least at the time, Kroah-Hartman was clearly skeptical of the whole idea—or even that a kref wrap could be exploited. However, Kees Cook did describe the way an exploit might work:
user1: alloc(), inc
user2: inc
user2: fail to dec
*repeat user2's actions until wrap*
user3: inc
user3: dec, free()
user1: operate on freed memory zomg
In the recent posting of PAX_REFCOUNT, Windsor has essentially broken up the PaX project's patches and applied them to the 4.2.6 stable kernel, though he is working on rebasing on linux-next. He noted a post on the grsecurity forums where the feature is well documented. The implementation changes the kernel's operations on atomic_t types so that overflows cannot occur; increments beyond INT_MAX are disallowed. In addition, processes that would have caused an overflow are sent a SIGKILL so that they can do no further damage. Windsor suggested that the signal might be too severe to start with:
The patches also create an atomic_unchecked_t type that acts just like today's atomic_t; it does no checking for overflow. In fact, the bulk of the patches are to various subsystems that use atomic variables but don't use them as reference counts; they are switched to use the new unchecked type. If the patches get merged, new users of atomic variables will need to determine if they are being used as reference counts or not to choose the proper atomic type.
So far, the comments on the patches have been light, but one suspects the code churn needed to switch all of those atomic types will bring some complaints when the patches get posted more widely. One could imagine creating a new type for those variables that need the checking, but that would require constant vigilance to ensure that any reference counts added to the kernel actually used the new type. That problem still exists with the posted patches, however, since new atomic_unchecked_t variables will need to be scrutinized to see that they aren't being used as reference counts.
PAX_MEMORY_SANITIZE
One way to mitigate the effect of use-after-free vulnerability or to stop various information leaks is to "sanitize" memory that is being freed by writing zeroes or some other constant value to it. That is the idea behind the PAX_MEMORY_SANITIZE feature. Laura Abbott posted a partial port of the feature to kernel-hardening on December 21.
In particular, Abbott's patches add the sanitization to the slab
allocators (slab, slob, and slub), but not for the buddy allocator as the
full PAX_MEMORY_SANITIZE feature does. That
means "that allocations which go directly to the buddy allocator
(i.e. large
allocations) aren't sanitized
". The actual
sanitization is done
using a fixed value (0xff for all architectures except x86-64, which uses
0xfe) that is written over the entire object before it is freed.
Abbott plans to look into adding
sanitization to the buddy allocator sometime in the new year.
Another change that Abbott made to the PaX version of the feature was to
add an option to handle the
sanitization in the slow path of the allocator.
Christoph Lameter complained that the feature was similar to the
slab-poisoning feature, so it should use that mechanism instead. Abbott agreed that the features were similar, but said
that poisoning is a debug feature and this work is targeting kernel
hardening so "it seemed more appropriate to keep debug features and
non-debug
features separate hence the separate option and configuration
".
The cost of sanitization is performance, of course. Abbott said she measured impacts of 3-20% depending on the benchmark. But the impact of compiling the feature into the kernel, but turning it off at runtime (using the sanitize_slab=off boot option), is negligible.
Lameter also suggested using the GFP_ZERO flag to make allocations
be zeroed before being returned. If there were a mode that set that flag
for all allocations it would provide "implied sanitization
".
But doing it that way would move the performance impact from the free path
to the allocation side, which is typically more performance sensitive, as
Dave Hansen pointed out. It also means
that unallocated memory would still store the potentially sensitive
contents of the previous object
until it is allocated again.
Instead of writing the fixed sanitization value across the object, writing zeroes would potentially allow the allocation path to skip the zeroing step, Hansen suggested. That might reduce some of the performance impact, though doing the zeroing at allocation time does leave the object's memory cache-hot, as Lameter noted. But zeroing has another downside that Abbott mentioned:
Overall, both patches were fairly well-received, but the hardening list is likely made up of those who are predisposed to look favorably on these kinds of changes. Based on discussions at last year's Kernel Summit, mainline developers should in theory be more receptive to patches that seek to mitigate whole classes of security bugs. If these PaX features can get merged eventually, there are some even more intrusive ones that could also attempt to run the gauntlet of the linux-kernel mailing list. Just where the line is—or even if there is one—is still unclear, but patches like these may help define it.
Some 4.4 development statistics
The 4.4-rc6 kernel prepatch was released on December 20, right on schedule. The 4.4 development series as a whole appears to be on schedule, with the most probable release date for 4.4 final being January 3, after one more prepatch. Linus has suggested that he might delay the release for one week. Any such delay, though, would be to allow developers to recover from the holidays before starting a new merge window rather than anything needed to stabilize 4.4.So, naturally, it is about time to look at this cycle's development activity. As of this writing, there have been 12,854 non-merge changesets pulled into the mainline this time around. It has thus been a busy cycle, though it would be surprising if we reached the number of changes seen in 4.2 (13,694), or the all-time record (13,722) set for 3.15.
The number of developers involved thus far is 1,548 — a large number, but slightly short of the 1,600 seen in 4.3. We may yet reach the 1,569 seen in the 4.2 cycle, though. Of those 1,548 contributors, 246 made their first kernel contribution in this development cycle — the lowest number since 3.13. The most active developers this time around were:
Most active 4.4 developers
By changesets H Hartley Sweeten 288 2.2% Mateusz Kulikowski 218 1.7% Chaehyun Lim 179 1.4% Leo Kim 167 1.3% Eric W. Biederman 163 1.3% Shraddha Barke 147 1.1% Ville Syrjälä 144 1.1% Arnd Bergmann 143 1.1% Eric Dumazet 123 1.0% Tony Cho 108 0.8% Geert Uytterhoeven 105 0.8% Glen Lee 105 0.8% Russell King 104 0.8% Javier Martinez Canillas 101 0.8% Sudip Mukherjee 96 0.7% Christoph Hellwig 91 0.7% Mike Rapoport 91 0.7% Oleg Drokin 89 0.7% Luis de Bethencourt 89 0.7% Andy Shevchenko 82 0.6%
By changed lines Alex Deucher 32203 5.0% Sreekanth Reddy 24009 3.7% Yuval Mintz 20622 3.2% Christoph Hellwig 15656 2.4% huangdaode 14725 2.3% Michael Chan 13137 2.0% Lv Zheng 9887 1.5% Oleg Drokin 8434 1.3% Deepa Dinamani 7797 1.2% Jes Sorensen 7737 1.2% Peter Senna Tschudin 7676 1.2% Sudeep Dutt 6881 1.1% Leo Kim 6664 1.0% Alexander Shishkin 6612 1.0% Arnd Bergmann 5893 0.9% Takashi Sakamoto 5837 0.9% Jiri Pirko 5350 0.8% Adam Thomson 5123 0.8% Eric Anholt 5041 0.8% H Hartley Sweeten 5030 0.8%
After an absence for a few development cycles, H. Hartley Sweeten is back at the top of the per-changeset list for the ongoing work on the Comedi drivers in the staging tree. This code, at just under 100,000 lines, has now seen nearly 8,000 patches — and the work continues. Mateusz Kulikowski worked entirely with the rtl8192e staging driver, while Chaehyun Lim and Leo Kim both fixed up the wilc1000 staging driver. Eric Biederman is engaged in a substantial reworking of how the network stack handles network namespaces, with an emphasis on proper handling of packets that cross namespaces.
On the lines-changed side, Alex Deucher continues to work on the AMD graphics drivers, Sreekanth Reddy removed a bunch of code from the mpt2sas driver (and, as a result, was the developer removing the most code in this cycle), and Yuval Mintz added a couple of Qlogic Ethernet drivers. Christoph Hellwig did a fair amount of cleanup throughout the driver and block subsystems, while huangdaode (the only name that appears in the logs) added support for the Hisilicon network subsystem.
The sum of these developers' effort resulted in the net addition of 242,000 lines of code to the kernel in this development cycle.
Work on 4.4 was supported by 202 employers that we could identify, a slight increase from 4.3. The most active companies working on 4.4 were:
Most active 4.4 employers
By changesets Intel 1660 12.9% (Unknown) 1139 8.9% (None) 684 5.3% Samsung 670 5.2% Red Hat 655 5.1% Atmel 449 3.5% Linaro 448 3.5% (Consultant) 419 3.3% Outreachy 400 3.1% IBM 302 2.3% Vision Engraving Systems 288 2.2% 273 2.1% SUSE 257 2.0% ARM 226 1.8% Texas Instruments 210 1.6% Freescale 208 1.6% Renesas Electronics 190 1.5% AMD 177 1.4% Oracle 173 1.3% Broadcom 169 1.3%
By lines changed Intel 85390 13.3% (None) 37078 5.8% AMD 36306 5.6% Red Hat 34937 5.4% (Unknown) 33739 5.2% (Consultant) 30271 4.7% Avago Technologies 27001 4.2% QLogic 24381 3.8% Broadcom 19318 3.0% Atmel 17856 2.8% Samsung 16508 2.6% Linaro 16154 2.5% HiSilicon Technologies 15260 2.4% Outreachy 12765 2.0% Renesas Electronics 11745 1.8% Mellanox 11590 1.8% Freescale 11392 1.8% ARM 10986 1.7% IBM 10402 1.6% Texas Instruments 10345 1.6%
For many years, Red Hat stood alone at the top of both columns of this list. That situation has been changing for some time; at this point, it is more than fair to say that Red Hat has ceased to be the most active company in the kernel development community. That is not to slight the company's work, of course; Red Hat still funds many of our most active developers, and those developers, in the subsystem-maintainer role, signed off on 16% of the changes merged this time around. But, at this point, Red Hat is one of a number of top-tier companies working to improve the Linux kernel.
Speaking of signoffs, the most active developers and companies when it comes to signing off patches they did not write are:
Most non-author signoffs in 4.4
Developers Greg Kroah-Hartman 2746 21.3% David S. Miller 1048 8.1% Daniel Vetter 447 3.5% Andrew Morton 346 2.7% Mark Brown 343 2.7% Ingo Molnar 241 1.9% Arnaldo Carvalho de Melo 224 1.7% Tony Cho 210 1.6% Jeff Kirsher 209 1.6% Kalle Valo 174 1.3%
Companies Linux Foundation 2763 21.6% Red Hat 2060 16.1% Intel 1649 12.9% Linaro 820 6.4% 602 4.7% (None) 459 3.6% SUSE 392 3.1% Atmel 260 2.0% Samsung 260 2.0% 233 1.8%
The kernel's subsystem maintainers remain concentrated in relatively few companies though, arguably, they are spread out a bit more widely than they once were. While many companies are willing to support kernel development in specific areas, fewer of them see the need to support developers working in the subsystem-maintainer role.
In summary, 4.4, the final kernel development for 2015, looks pretty typical. It was busier than most, but that, too, is typical, given the long-term trend toward larger development cycles. That busyness does not appear set to make this cycle longer than the 63 days that we have come to expect, though. Despite its occasional hiccups, the kernel-development machine continues to run smoothly.
Patches and updates
Kernel trees
Architecture-specific
Core kernel code
Development tools
Device drivers
Device driver infrastructure
Filesystems and block I/O
Memory management
Networking
Security-related
Virtualization and containers
Miscellaneous
Page editor: Jonathan Corbet
Distributions
Iceweasel for Fedora?
Mozilla's plan to require all extensions (also known as add-ons) to be signed by Mozilla before they can be installed in Firefox may lead Linux distributions down the same path that Debian has taken—a name change to avoid the Firefox trademark. The problem is that some distributions currently ship extensions that it will be difficult or impossible to get signed. The requirement can also be seen as a form of control over what users can install in their browser, which some see as running counter to the philosophical underpinnings of free software.
A Fedora Engineering Steering Committee (FESCo) bug report has called
out the issue for Fedora. Kevin Kofler filed the bug, which calls for
blocking any update to Firefox 44 (which will remove the about:config
option for signature checking) in fairly strident terms (e.g. the bug is
entitled "Software
packaged in Fedora should not be allowed to implement DRM schemes that
cannot be disabled
"). He described the problem this way:
There is a mechanism provided by addons.mozilla.org (which is the site for Firefox extensions as well as for signing the packages) to automate the signing of existing extensions, but it would be quite cumbersome for Fedora to use. It would also leave users who want to install extensions they have built or have obtained in other ways out in the cold.
There are already two bug reports filed for Fedora packages (mozilla-adblockplus and mozilla-https-everywhere) that can't be installed in Firefox 43 without changing the value of xpinstall.signatures.required in about:config. When Firefox 44 comes along in late January, even that workaround won't suffice. But this requirement has been coming for some time; we covered the change back in February.
Others commented on the bug, mostly agreeing with Kofler's assessment. FESCo member Stephen Gallagher suggested that the committee communicate with Mozilla:
Kevin Fenzi, who is also a FESCo member, thought that it was important to include the Firefox package maintainer Martin Stransky into the discussion. As might be guessed, Stransky had a somewhat different view than many of the other commenters. He wondered about the value of Fedora packaging extensions. He also noted the Debian's rebranded Firefox (i.e. Iceweasel) is available in Fedora already, which might be an alternative for those who need it.
Several responded with reasons that Fedora wants or needs to package its own extensions, but there is more to it than that. For one thing, users may be willing to trust Fedora as a source for their extensions, but not Mozilla. There may also be distribution-specific changes that need to be made. As Gallagher put it:
[...]
All RPMs distributed by Fedora must be built in the Fedora infrastructure. This is also a trust issue, as it ensures that we are building and shipping a binary that matches the sources (there's no guarantee to our users that the public source matches the binary distributed by A.M.O.). Furthermore, compiled extensions may be built with different flags in order to match the system security policy and these may differ from the upstream build.
Fundamentally it comes down to a question of software freedom, Gallagher
concluded. In fact, Dominik "Rathann" Mierzejewski argued
that updating Fedora to Firefox 43 without disabling the signature
checking by default, as Stransky has done, is a violation of the update
guidelines. He suggested
updating the Firefox 43 package to disable signature checking and to
"NOT update to FF44 in F22 and F23 until this is resolved
".
The consensus in the bug is clearly to remove the signature checking by default one way or another. Gallagher suggested prompting users to decide if they want the checking, but even that requires changes to the Firefox code. And that will be the crux of the matter. Mozilla only allows using the Firefox trademark for modified versions of the browser if it approves of those changes. Concern about that trademark policy (and getting Mozilla's approval for every patch) is what led Debian to switch to Iceweasel. Kofler explicitly suggested that Fedora do the same.
Ultimately it will be up to Mozilla, as it can choose to allow distributions to remove the signature checking (or provide a way to disable it) or not. If it sticks to its guns and "forces" distributions to leave that part of the Firefox code alone, it may well push more Linux users into installing Iceweasel or the like, because that is what their distribution provides. At some point, FESCo will undoubtedly discuss the issue, but it is hard to see how the conflicts between the freedoms inherent in free software and a lockdown regime such as that being pushed by Mozilla (however well-intentioned) can coexist. Something has to give—if it isn't Mozilla, then replacing Firefox in Fedora with Iceweasel may not be far behind.
Brief items
Distribution quote of the week
Are you willing to do the fixing yourself?
If the answer to the first question is yes, and the second is no, then you've just volunteered for the job of either community motivator, or frustrated user. The goal then is to make people care more about going out of their way to fix things than going out of their way to find ways to make you even more frustrated. Which do you think is going to be more emotionally satisfying to those who read this thread?
Release for CentOS AltArch 7 (1511) on x86_64
CentOS has released version 7 (1511) for several alternate architectures, including i686 and Armhfp. Technology previews are also available for PowerPC64 and PowerPC8 LE.FreedomBox 0.7 Released
FreedomBox 0.7 has been released, with new translations, support for OLinuXino A20 MICRO and LIME2, new Plinth applications: OpenVPN, reStore, improved first-boot experience, and, of course, many bugfixes and cleanups.
Distribution News
Debian GNU/Linux
Debian LTS: MySQL 5.5 packages added; end of support for MySQL 5.1
MySQL 5.1, included with Debian 6.0 (squeeze), is no longer supported. MySQL 5.5 packages are available and users are encouraged to upgrade.
Newsletters and articles of interest
Distribution newsletters
- DistroWatch Weekly, Issue 641 (December 21)
- openSUSE Tumbleweed – Review of the week (December 17)
- Ubuntu Weekly Newsletter, Issue 447 (December 20)
Android on the desktop: Not really “good,” but better than you’d think (Ars Technica)
Ars Technica reports that Google has plans to bring Android to desktops and laptops. "We've Frankensteined together a little Android desktop setup using a Nexus 9 and a USB keyboard and mouse to see just how easy—or complicated—it was to use what is still formally a "mobile" operating system in a desktop context today, right now, without complicated changes or reconfigurations. It worked, but Android still has a ways to go before it can be called a real desktop operating system—quite a ways, in some cases. The biggest affordance Android makes for a desktop OS is that it supports a keyboard and mouse. Any Android device can pair with a Bluetooth mouse and keyboard, and if you want to go the wired route, just about any phone can plug in a mouse and keyboard via a USB OTG cable and a USB hub. Some OEMs even build Android devices with a keyboard and mouse, like the Asus Transformer series, which is a convertible laptop that runs Android."
Review: Mint 17.3 may be the best Linux desktop distro yet (Ars Technica)
Ars Technica finds plenty to like in Linux Mint 17.3. "The developers of Linux Mint have shown that they have the vision and are willing to put in the actual work to produce one the best desktop experiences around. The Cinnamon edition is not just the most polished Linux desktop around, it's possibly the most polished desktop period. Hyperbolic? Perhaps a little, but this really is the most thoroughly thought-out desktop I've ever used, Linux or otherwise."
Kirkland: More people use Ubuntu than anyone actually knows
Dustin Kirkland feels that Ubuntu users have been undercounted, and so has put together a census of his own. "Ever watch a movie on Netflix? You were served by Ubuntu. Ever hitch a ride with Uber or Lyft? Your mobile app is talking to Ubuntu servers on the backend. Did you enjoy watching The Hobbit? Hunger Games? Avengers? Avatar? All rendered on Ubuntu at WETA Digital." In the end, he says, there are over one billion Ubuntu users.
Page editor: Rebecca Sobol
Development
Deprecating XUL for WebExtensions
Mozilla first unveiled plans to revamp the development framework offered to extension authors in August, announcing that it would deprecate XUL and XPCOM in favor of an API based on JavaScript. That API, called WebExtensions, is now available to developers in the Firefox Nightly channel. The stable release is scheduled to arrive in mid-2016, and add-ons using the API should also be usable as extensions for the Chrome and Opera browsers.
XUL is the XML-based user-interface markup language used to define windows, menus, interface widgets, and other components in Firefox, Thunderbird, and a few other Mozilla projects. XPCOM is the corresponding component model, providing access to the various libraries that make up the application (networking, security, rendering engine, etc.). Both are well over a decade old and, while it could be argued that they have served their purposes well, they are integral enough to the structure of Firefox that they make it difficult to maintain a clear separation between the browser internals and third-party add-ons.
That has serious security implications, of course, and it also makes browser extensions rather brittle—susceptible to breakage when there are minor changes to the browser code itself. Meanwhile, Google's Chrome/Chromium (and the Opera browser, which also uses Chrome's Blink engine) have both found success attracting extension developers with the JavaScript-based Chrome extension APIs. By mirroring those APIs where possible, Mozilla believes it can attract new extension developers as well as enable many Chrome extensions to work in Firefox with a minimal amount of porting effort.
WebExtensions is Mozilla's name for the new API. It is worth noting that Mozilla terminology uses "API" in the singular, while Chrome's refers to same set of interfaces as APIs, plural. But this is purely semantics, just like how Mozilla refers to extensions, plugins, and themes, collectively, as "add-ons," while Chrome calls everything "extensions." There are more than 60 APIs defined for Chrome's extensions, with more constantly under development. They include everything from hooks to build user-interface elements to security features to the manipulation of page contents. Mozilla has set up a feature-tracking page for its implementation at AreWeWebExtensionsYet.com that lists the completion status for each API and links to open bugs and relevant documentation.
A WebExtension consists of JavaScript files bundled together with a JSON manifest file and any necessary resource files. WebExtensions can run background-process scripts as well as user-visible scripts (such as those that add to the browser interface or modify page content). WebExtensions will be subjected to the same security tests and signing rules imposed on extensions using the existing APIs. They will also retain the .xpi file extension, despite the internal differences with current add-ons. There are a few example extensions available as well.
Currently, the plan is on track for Firefox 45 (which is the series
currently in the Nightly channel and which will become the stable
Firefox release in March 2016) to fully support the contextMenus,
browserAction,
pageAction, and alarms APIs. The browserAction API
allows an extension to place a button or icon on the toolbar;
pageAction allows an extension to place one in the location bar. Like
the name implies, contextMenus lets extensions add items to the
right-click context menu, while alarms lets extensions schedule tasks.
It is a rather small set of features; the plan announcement also noted
that there should be "a bunch of partially supported
APIs
" available as well, including those used to access
bookmarks, cookies, storage, and outgoing HTTP requests.
Ideally, the full set of WebExtensions APIs will be available as an experimental feature with the release of Firefox 47 (slated for release at the end of May 2016), and as a stable feature in Firefox 48 (July 2016). That said, even though the advertised goal of the project is to offer an API that closely mirrors that used by the Blink-based browsers, it appears that there will always be some differences.
The Mozilla wiki lists the interfaces that differ from those in the Chrome APIs. In some cases, the likelihood is that Mozilla will never implement the full Chrome API because it is bound too tightly to Google services. For example, in Chrome, the storage API (which is on the list to be partially supported for Firefox 45) supports not only the W3C localStorage standard, but Chrome's built-in cloud synchronization service and an enterprise "managed storage" policy. The Firefox implementation supports only localStorage.
There are other APIs where Firefox and Chrome will vary due to higher-level behavioral or policy differences. For example, Chrome provides separate cookie stores for each incognito tab, and the cookies API allows extensions to access those cookies as well as cookies from the standard browser store. Firefox's private-browsing mode, which is the nearest equivalent of incognito tabs, does not allow extensions to access the private-mode cookies at all. And there may still be additions to the WebExtensions API to provide access to Firefox-only features; the Mozilla wiki notes that Firefox supports special bookmarks like the "Recently Bookmarked" and "Recently Visited" folders that have no Chrome API equivalent.
In the future, though, Mozilla does seem to be aiming to maintain compatibility between the APIs where possible. No doubt that will be seen as a plus when marketing the API to Chrome or Opera extension developers. Even if some porting effort is required, it will be substantially lower than the costs of learning XUL and XPCOM.
Further out, Mozilla has several major changes lined up for Firefox, including the Servo rendering engine and the Electrolysis multi-process model. The August announcement of WebExtensions noted that reliance on XUL and XPCOM was an impediment to implementing both of those plans. The WebExtensions API implementation is explicitly designed to be Electrolysis-compatible.
Since they are being positioned to supplant XUL-based extensions entirely, WebExtensions will also be supported by Mozilla's Add-ons repository service. The developer documentation for the new API, which is still under construction, notes that currently WebExtensions can only be installed locally in Firefox Developer Edition or in Nightly builds. As the roll-out process continues, though, developers will be able to submit WebExtensions for testing and distribution through the Add-ons site. The announcement post that set out the timeline for WebExtensions' availability estimates that the Add-ons site will be ready for the new format by the time Firefox 44 is released—late January 2016.
If everything comes together as planned, then, extension developers can begin experimenting with the new API immediately, with an eye toward making their work available to early adopters in March. Migrating to an entirely new API can certainly seem like a daunting proposition, even if there is half a year between now and when the new API is scheduled to be declared stable. But much of that risk is mitigated by Mozilla's choice to adhere to the battle-tested interfaces used by Chrome and the other Blink-based browsers.
It is a gamble for Mozilla, one that may raise the ire of longstanding extension developers, but the move is well warranted given the long-term goals of work like Electrolysis and Servo. It is less clear whether adopting the same APIs used by Chrome will foster any cooperation on future extension development between Mozilla and the Chrome team, but at least Mozilla will have a seat at the table for such discussions—if it succeeds in bringing a sizeable number of extension developers along.
Brief items
Quotes of the week
"Sigh, there are going to be two more of these bozos who come tonight I suppose. I probably won't get anything done. This will be worse than end of quarter."
First Plasma Wayland Live Image (KDE.News)
Over at KDE.News, Jonathan Riddell has announced the availability of the first live image [1.2GB ISO] of the KDE Plasma desktop running atop Wayland. "The central component in this is our window manager, KWin, which has moved from drawing borders on the edges of windows to running the full compositor and talking the Wayland protocols which allow applications to draw on screen and be interacted with. Users of the image will notice some obvious glitches, it is certainly not ready for everyday use yet, but the advantages of more secure workspaces, easier feature extendibility and graphics free of tearing and gitches will be appreciated by everybody. Work on this has been ongoing since 2011 and is expected to take years rather than months before a completely transparent switch away from X will be possible. Find more about the project on the KWin Wayland wiki pages."
FreeType 2.6.2 released
FreeType 2.6.2 is now available, introducing several text-rendering changes that may be of interest to developers and users. Among them are a new default for LCD subpixel rendering and changes to hinting behavior. First, setting hinting to "slight" in Fontconfig now triggers the platform's native hinter if possible. "This decision was driven by my personal whim; I wanted native vertical
grid-fitting if the font driver and font supports it, and the
auto-hinter otherwise. I assume that native hints are made more
carefully and take the (auto-hinting) guesswork out of the
process. Instead of introducing per-format configuration in FontConfig
and fighting GTK[3]/GNOME[4] that only support a single global hinting
setting, it was found to make more sense to change the definition of
light hinting in FreeType.
" Second, there is new, experimental support for stem-darkening in the FreeType auto-hinter, which works around the fact that Linux toolkits do not properly render glyphs onto the background using linear blending and gamma correction. The upshot will be that vertical stems now look somewhat darker on Linux, more accurately matching the font rendering on other platforms.
MediaWiki 1.26 released
Version 1.26 of the MediaWiki platform that powers Wikipedia and
many other wiki sites has been released.
Performance improvements were the focus for this cycle, notes the
announcement: "All JavaScript is now delivered to the client
asynchronously, significantly improving the page load time. Due to
performance issues in the old implementation, syntax highlighting
support was completely overhauled using the Python 'Pygments' library,
and added support for several hundred new languages at the same
time.
" In addition, a long-planned overhaul of the
authentication code began in this release with the deprecation of old
authentication-layer functionality.
WebExtensions in Firefox 45
The Mozilla Add-ons blog takes a look at the work going on around the WebExtensions API. "WebExtensions is currently in an alpha state, so while this is a great time to get involved, please keep in mind that things might change if you decide to use it in its current state. Since August, we’ve closed 77 bugs and ramped up the WebExtensions team at Mozilla. With the release of Firefox 45 in March 2016, we’ll have full support for the following APIs: alarms, contextMenus, pageAction and browserAction. Plus a bunch of partially supported APIs: bookmarks, cookies, extension, i18n, notifications, runtime, storage, tabs, webNavigation, webRequest, windows."
ReText 5.3 available
Version 5.3 of the ReText editor for Markdown documents has been released. New in this update is drag-and-drop support for reordering tabs, a document-preview mode, and fully configurable syntax-highlighting colors.
Vagrant 1.8 available
Version 1.8 of the Vagrant development-environment configuration tool has been released. New are support for linked clones (which are created by building a differential disk image from the original, rather than duplicating a full disk image), creating and restoring from snapshots, and provisioning Ansible on guest machines.
Newsletters and articles
Development newsletters from the past week
- LLVM Weekly (December 21)
- OCaml Weekly News (December 22)
- Perl Weekly (December 21)
- PostgreSQL Weekly News (December 20)
- Python Weekly (December 17)
- Ruby Weekly (December 17)
- This Week in Rust (December 21)
- Wikimedia Tech News (December 14)
- Wikimedia Tech News (December 21)
Cannon: Why Python 3 exists
Brett Cannon reminds the world why the Python developers decided to create Python 3 — and acknowledges that the transition could have been done better. "This point of avoiding bugs is a big deal that people forget. The simplification of the language and the removal of the implicitness of what a str object might represent makes code less bug-prone. The Zen of Python points out that 'explicit is better than implicit' for a reason: ambiguity and implicit knowledge that is not easily communicated code is easy to get wrong and leads to bugs. By forcing developers to explicitly separate out their binary data and textual data it leads to better code that has less of a chance to have a certain class of bug."
Questions about Open Source and Design
At her blog, Emily Dunham reports
on her recent conversations with UI and UX developers about why
open-source projects struggle with design. From the replies, she
identifies several pain points, such as: "Non-designers struggle
to give constructive feedback on design. I can say 'that’s ugly' or
'that’s hard to use' more easily than I can say 'here’s how you can
make it better'
" and: "The tests which designers apply to
their work are often almost impossible to automate. For instance, I
gather that a lot of user interaction testing involves watching new
users attempt to complete a task using a given design, and observing
the challenges they encounter.
" No doubt there are few easy
answers, but the conversation is certainly worth pursuing.
Guidelines For Announcing Software Releases
At the Red Hat Community blog, Brian Proffitt has posted a detailed set of best-practice guidelines for release announcements. Among the topics addressed are gathering changelog data for announcements as part of the release process, properly timing announcements to be noticed by the community, and differentiating between the audiences for major, minor, and patch-level updates. Also covered is wording advice: "Avoid hyperbole ("the bestest project ever made!!!" and speculation ("the only project that can do this"). As tempting as it is, release announcements should not [be] opportunities to hype your project.
" And, of course, it touches on that great unsolved problem of computer science: including a few words in the announcement that mention what the software actually does.
Page editor: Nathan Willis
Announcements
Brief items
Linux Foundation announces project to "advance blockchain technology"
The Linux Foundation has announced a new collaborative project to "develop an enterprise grade, open source distributed ledger framework" to allow developers to build "
robust, industry-specific applications, platforms and hardware systems to support business transactions". Twenty companies have joined the effort: Accenture, ANZ Bank, Cisco, CLS, Credits, Deutsche Börse, Digital Asset Holdings, DTCC, Fujitsu Limited, IC3, IBM, Intel, J.P. Morgan, London Stock Exchange Group, Mitsubishi UFJ Financial Group (MUFG), R3, State Street, SWIFT, VMware, and Wells Fargo. "
Many of the founding members are already investing considerable research and development efforts exploring blockchain applications for industry. IBM intends to contribute tens of thousands of lines of its existing codebase and its corresponding intellectual property to this open source community. Digital Asset is contributing the Hyperledger mark, which will be used as the project name, as well as enterprise grade code and developer resources. R3 is contributing a new financial transaction architectural framework designed to specifically meet the requirements of its global bank members and other financial institutions. These technical contributions, among others from a variety of companies, will be reviewed in detail in the weeks ahead by the formation and Technical Steering Committees."
Test Your Online Privacy Protection with EFF’s Panopticlick
The Electronic Frontier Foundation has launched an updated version of its online tracker-testing tool Panopticlick. "When you visit a website, online trackers and the site itself may be able to identify you, and the records of your online activity can then be distributed among a vast network of advertising exchanges, data brokers, and tracking companies. Many people install ad- or tracker-blockers to try to protect themselves, but it can be hard to know how effective they are. Panopticlick will check your browser and your add-ons and assess the privacy protections users have in place. It can also suggest remedies for under-protected browsers. But even if you have strong tracker blocking installed on your computer, you could still be identified by what’s called a “browser fingerprint.” That’s the combination of factors such as your operating system, your browser, and plug-ins. Panopticlick also analyzes the uniqueness of your browser to see if you are still at risk from this kind of data-gathering, even if you have privacy-protective software installed."
FSF: Free software activists come together on proposed U.S. DoE regulations
The U.S. Department of Education posted a Notice of Proposed Rule Making earlier this fall, *Open Licensing Requirement for Direct Grant Programs*, requesting comments from the public. The proposed regulations did have goals to make material open and available to all, but they didn't explicitly require that the license permit redistribution of modified versions. The FSF has urged the DoE to correct that oversight.Jolla: not dead yet
The Jolla company blog announces that the company has closed a new round of funding and will not be shutting down after all. "This investment enables the continuation of Sailfish OS development, the community activities and other company operations. It’s clear that this recent struggle hit us hard and left some battle wounds but most importantly this means that the development and life of Sailfish OS will continue strong. This alone is worth a celebration!"
Calls for Presentations
CFP Deadlines: December 24, 2015 to February 22, 2016
The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.
| Deadline | Event Dates | Event | Location |
|---|---|---|---|
| December 31 | April 26 April 28 |
Open Source Data Center Conference | Berlin, Germany |
| January 3 | May 28 June 5 |
PyCon 2016 | Portland, OR, USA |
| January 8 | March 19 March 20 |
Chemnitzer Linux Tage 2016 | Chemnitz, Germany |
| January 10 | April 15 April 17 |
PyCon Italia Sette | Firenze, Italia |
| January 11 | March 23 | Make Open Source Software 2016 | Bucharest, Romania |
| January 15 | March 14 March 17 |
Open Networking Summit | Santa Clara, CA, USA |
| January 15 | March 10 March 12 |
Studencki Festiwal Informatyczny (Students' Computer Science Festival) | Cracow, Poland |
| January 16 | April 1 | DevOps Italia | Bologna, Italy |
| January 18 | March 18 March 20 |
FOSSASIA 2016 Singapore | Singapore, Singapore |
| January 19 | May 17 May 21 |
PGCon - PostgreSQL Conference for Users and Developers | Ottawa, Canada |
| January 22 | May 2 May 5 |
FOSS4G North America | Raleigh, NC, USA |
| January 22 | January 22 January 23 |
XenProject - Cloud Innovators Forum | Pasadena, CA, USA |
| January 24 | March 14 March 18 |
CeBIT 2016 Open Source Forum | Hannover, Germany |
| January 24 | March 11 March 13 |
PyCon SK 2016 | Bratislava, Slovakia |
| January 29 | April 20 April 21 |
Vault 2016 | Raleigh, NC, USA |
| February 1 | April 25 April 29 |
OpenStack Summit | Austin, TX, USA |
| February 1 | June 22 June 24 |
USENIX Annual Technical Conference | Denver, CO, USA |
| February 1 | April 4 April 8 |
OpenFabrics Alliance Workshop | Monterey, CA, USA |
| February 2 | March 29 March 31 |
Collaboration Summit | Lake Tahoe, CA, USA |
| 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 |
If the CFP deadline for your event does not appear here, please tell us about it.
Upcoming Events
SCALE Update
Southern California Linux Expo (SCALE) will take place January 21-24 in Pasadena, CA. There will be an installfest and two basic system administration classes. There is still room for a few UpSCALE talks, though that will close soon. Also there are rooms available at the special conference rate, and those are going fast.LibrePlanet seeks sponsors
The Free Software Foundation is selecting the program for LibrePlanet 2016, which will take place March 19-20 in Boston, MA. Registration is open and the FSF is seeking sponsors for its travel scholarship fund, to help a fellow free-software enthusiast attend.Planning has begun for LPC 2016
The 2016 edition of the Linux Plumbers Conference has announced that planning for the conference has begun. LPC will be held November 2-4 in Santa Fe, New Mexico in conjunction with the Kernel SummitEvents: December 24, 2015 to February 22, 2016
The following event listing is taken from the LWN.net Calendar.
| Date(s) | Event | Location |
|---|---|---|
| December 27 December 30 |
32. Chaos Communication Congress | Hamburg, Germany |
| January 8 | Fairphone Workshop | Amsterdam, Netherlands |
| January 16 | Bangalore Linux Kernel Meetup | Bangalore, India |
| January 20 January 22 |
O'Reilly Design Conference 2016 | San Francisco, CA, USA |
| January 21 January 22 |
Ubuntu Summit | Pasadena, CA, USA |
| January 21 January 24 |
SCALE 14x - Southern California Linux Expo | Pasadena, CA, USA |
| January 22 January 23 |
XenProject - Cloud Innovators Forum | Pasadena, CA, USA |
| January 25 | Richard Stallman - "A Free Digital Society" | Stockholm, Sweden |
| January 30 January 31 |
Free and Open Source Developers Meeting | Brussels, Belgium |
| February 1 | MINIXCon 2016 | Amsterdam, Netherlands |
| February 1 | Sysadmin Miniconf | Geelong, Australia |
| 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 |
If your event does not appear here, please tell us about it.
Page editor: Rebecca Sobol