Emacs and LLDB

Back in January, we looked at a dispute regarding extracting internal representation data from GCC for use by Emacs. Because of concerns about commercial entities circumventing the GPL, Richard Stallman opposed making the abstract syntax tree (AST) available from GCC, which was a feature that some Emacs developers were hoping to make use of. There are also technical barriers to using GCC's AST, it would seem, but it is the political barrier being erected that stuck in the craw of many. A more recent thread on the emacs-devel mailing list looks a bit like history repeating itself.

Andrew L. Moore obviously recognized the potential pitfalls when he asked about merging a patch adding support for the LLDB debugger (part of the LLVM project) to the code for the Emacs Grand Unified Debugger mode: "I’d be interested to know if and how this might be accepted into the Emacs distribution, RMS’s opinion of LLVM notwithstanding." Emacs maintainer Stefan Monnier was quick to respond positively to the idea. His only concern was to "to clear the copyright status of this code".

On the other hand, Stallman was not in favor of the change. In fact, he saw it as an attack on the GNU project:

As might be guessed, others saw things a little differently. Several likened the situation to that of Windows and Mac OS X support in Emacs, though Stallman rejected that comparison. In addition, no one saw basic LLDB support for Emacs as the attack that Stallman made it out to be. Monnier said Stallman sounded paranoid:

Furthermore, as David Kastrup put it: "If we try to close down every cooperation with non-GNU free software, we are sacrificing our goals for the sake of our temples." Stallman disputed that he was suggesting that course, but there is, at least, a perception problem that Stephen J. Turnbull pointed out:

There are several issues for Emacs (and GNU) that Stallman is currently studying, including getting AST information from GCC and support for LLDB but, to some, those studies are holding development back unnecessarily. Kastrup would like to see some rules that would help reduce the amount of study required:

Stallman, though, seems to be convinced that Apple is attacking GCC through LLVM: "Apple intends LLVM and Clang to make GCC cease to be a signal success and a reason for all sorts of companies to work on a compiler that always gives users freedom". But, as Eric S. Raymond pointed out, Apple's adoption of LLVM is actually a victory, since LLVM is licensed under a free-software license (just not a copyleft license like the GPL):

An interesting side note to the debate emerged when Liang Wang posted about LLVM creator Chris Lattner's offer to try to get LLVM's copyright assigned to the FSF back in 2005. It was part of an effort (that seemingly went nowhere) to integrate LLVM and GCC. Stallman never heard about the message:

Helmut Eller suggested contacting Lattner to see if LLVM might be interested in switching its license but, as Kastrup pointed out, LLVM is already licensed in a GPL-compatible way. If someone wanted to, they could release a GPL fork of LLVM tomorrow. On the other hand, though, LLVM is targeted at being modular so that other tools can use it in novel ways—something that GCC has generally resisted (largely at Stallman's behest). So, Kastrup continued:

So far, at least, there has been no response from Stallman to that. In the meantime, however, Raymond posted a broadside furthering his earlier message entitled "Defending GCC considered futile". It is too late to save GCC, he said, so it is time to move on:

Reaction to Raymond's message was fairly muted on the mailing list, which is a bit surprising, but may partly be due to the fact that it was posted to an Emacs list, rather than one for GCC. In any case, Stallman chose to focus on the narrower issue of whether supporting LLDB is right for Emacs—and to ignore the larger LLVM issue taken up by most others in the threads. But he admitted a total lack of knowledge of LLDB, though he guessed it is a "noncopylefted debugger", based on the name. Others confirmed that guess and went on to describe LLDB at some length.

Stallman is still awaiting information about LLDB to try to make a decision about whether he thinks Emacs should support it or not. As he did in the earlier thread, though, Monnier made it clear that Stallman's opinions on the matter carry no weight with him. He has said he will merge LLDB support once there is code with a proper copyright assignment available.

On multiple issues, Stallman could be seen to be standing in the way of progress in ways that don't serve Emacs, GCC, or the GNU project all that well. While Raymond's assertion that he would not personally miss GCC is, characteristically, over the top (compiling a Linux kernel still requires GCC, for example, even as the LLVMLinux project gets closer to its goal), it may not be all that long before it is true. That's unfortunate in many ways, but perhaps not completely unexpected.

By all accounts, LLVM is an excellent project that provides infrastructure for numerous compilers (including Clang) and other tools (including LLDB). While it doesn't have the license that Stallman, the FSF, and others might wish, it is certainly free software. There is plenty of room for two (or more) compiler suites in the free-software world—we just may be seeing a switch in the dominant player. Trying to stand in the way of that switch may well turn out to be a poor place to stand.

Comments (121 posted)

Matrix: a new specification for federated realtime chat

The free-software community has frequently advocated the development of new decentralized, federated network services—for example, promoting XMPP as an alternative to AOL Instant Messenger, StatusNet as an alternative to Twitter, or Diaspora as an alternative to Facebook. The recently launched Matrix project takes on a different service: IRC-like multi-user chat. If the thought of replacing IRC sounds like a strange goal for a new project, though, Matrix is extensible, and the developers have already added support for one-to-one audio and video calling. Though it is still in development, Matrix is simple enough that one can already get a feel for how it works.

Matrix was launched in mid-2014, with most of the developers coming from the enterprise software firms Amdocs and OpenMarket. The Matrix site hosts the main specification as well as a description of the client-to-server API. There is also a server-to-server API which, so far, has not been published on its own (although it is referred to in the Matrix specification). At GitHub, the project maintains repositories for a reference Matrix server called synapse and for Android and iOS client libraries.

The synapse repository also includes two demo clients: one that runs as a web application, and one command-line client written in Python. The most recent release is version 0.6.1f, from February 10. Interested users can test out the system by connecting to the Matrix demo server through the web client at https://matrix.org/beta/ or through the IRC gateway at irc://irc.freenode.net/matrix.

Matrix basics

The Matrix system allows individual users to join persistent realtime chat rooms (hence the comparison to IRC and its channels). But the messages posted in any particular room are continuously synchronized between every participating Matrix server, thus protecting against the single-point-of-failure problem well known to IRC users. Whenever a new server connects a room—which it would only do when a user attempts to join that room—the other participating servers propagate the room's history to the new server, so that all servers eventually reach a consistent state, and all users have access to the full message history.

Matrix rooms feature management functions similar to those found in IRC, such as inviting, kicking, and banning room members. While the general-purpose Matrix message format is text, the protocol also supports presence (so that users can advertise "here" or "away" status as desired) and public user profiles. It can also be extended to support other message types. As published, it already supports emoticon messages, geolocation references, and file attachments.

Rooms can have user-friendly names, like #help:example.org, that are similar to IRC channel names. But those user-friendly names are actually aliases: under the hood, the real room identifier is a randomly-generated string. All that matters to someone wishing to join the room is that the server running at example.org maintains the current mapping between the alias and the room identifier. Furthermore, the real room identifier could change over time—rooms persist even if the alias becomes unavailable (such as the original server going offline).

The purpose of separating room identifiers and user-friendly aliases is two-fold. First, the domain component of the alias identifies the server that is advertising the alias-to-room mapping; this is intended to provide a globally unique namespace—as long as two users on example.org do not both try to start #help rooms, it does not matter that there may be other, disjoint #help rooms originating somewhere else. Second, users that want to connect to a persistent room need only remember the alias to join—if the original server is restarted, the room identifier might change, but the alias can remain the same.

User identities use a syntax much like room identifiers; the format is @username:example.com. Interestingly enough, the specification also advertises a way for users to publicly link a Matrix user ID to a "third-party identifier" (3PID), such as an email address or phone number. To do this, the Matrix network would support a global, federated network of identity servers that maintains the links between accounts and 3PIDs. The goal would seem to be making it simpler to invite another user to join a chat. Unfortunately, the relevant section of the Matrix specification is still empty (marked with "This section is a work in progress.").

In addition to its more IRC-like facets, Matrix also includes some features geared towards one-to-one communication. Users can send invitation messages to other users, and the basic Matrix protocol supports extensions for WebRTC audio and video. Together, those functions allow Matrix to provide a VoIP-like service. Users can also create a chat room and invite others to it without advertising it via a public alias; that functionality more closely resembles traditional instant messaging.

There are also some interesting features to the Matrix system without a clear analogue to other network services. For example, each user connects by signing in from their client application to the Matrix server where they have an account. But the chat room is a server-to-server construct. Users can log on to their server with more than one client simultaneously (e.g., a desktop machine and a mobile device), and the other servers participating in the room never need to know. The synapse reference server provides this feature. With IRC or IM, each client application connects directly to the central server, and logging in from two locations creates a variety of problems.

Networks and security

One of the more fundamental questions a new project like Matrix must answer is why an entirely new protocol is required to do what the new system does—after all, XMPP, SIP, and IRC are all well-established at this point. The Matrix project's answer consists of several pieces. First, there is the general rationale for decentralized and federated services. No central server is required to connect two users, anyone can run their own server, and users with accounts on different servers can interact easily.

Second, the project has its own list of shortcomings with IRC, XMPP, and the like. Some of these are well-known—like IRC's limitation to text-only messages and the inability of users to simultaneously connect to an IRC channel from more than one device. Others are a little more subjective, such as the claim that XMPP has "no strong identity system".

Third, and perhaps the most difficult to quantify, Matrix is designed to be friendly to web implementations—and, in fact, builds heavily on web underpinnings. Client-server and server-server connections are made with HTTP on top of TLS. All of the messages (client-server and server-server) are in JSON and are exchanged with RESTful requests.

Speaking of TLS, the security model of Matrix is one area in which the project has several surprises in store. For starters, end-to-end encryption is not built in. The traffic on the wire is protected by TLS, but that does not prevent unwanted users from joining what is meant to be a private discussion room. Users who wish to restrict access to a room must rely on Matrix's room-management API: room moderators can kick out users or ban them (by user ID), but little else. Furthermore, although TLS encrypts the messages between servers, the servers themselves have access to the message content. Several spots in the specification and on the Matrix site as a whole make reference to optional end-to-end encryption (where only the users could decrypt the contents of messages), but this appears to be another unfinished component at present.

That said, Matrix does allow for room moderators to "redact" old messages. A m.room.redaction event permanently removes the content of a message, but it leaves the message's event ID and other generic metadata fields in place; that allows other servers in the room to similarly strip out the (presumably offensive) contents without causing problems for the synchronization algorithm.

The final piece of the Matrix puzzle is identity management. Server-to-server Matrix messages are authenticated (in addition to TLS) using public-key signatures in the HTTP Authorization header that accompanies the message. When establishing a new connection, each Matrix server can retrieve the both the TLS certificate and the signing key of its peer server from the well-known location http://foo.com/_matrix/key/v1. Thus, the system places trust in the usual TLS certificate-authority system to verify the identity of a server.

Authenticating the identity of a remote user in a chat room is a different matter. Here again, the Matrix specification is essentially blank, and all that can be gathered about the scheme that the project has in mind are bits and pieces referred to elsewhere. The synapse repository includes a brief description on its landing page, noting that:

The sydent server referenced is another GitHub repository, albeit one that has not been touched in five months. But there is slightly more detail if one is willing to dig. The authenticity of any user account is the purview of the Matrix server where the account resides. An Identity Server can only verify that a given Matrix ID has been asserted to go with a particular email address (or other 3PID), and that the assertion came from the correct Matrix server. In short: the trust eventually falls back to the Matrix server anyway.

But perhaps that is good enough; after all, one of the main purposes of designing a federated network like Matrix is that anyone has the freedom to set up a server and start some conversations. Much like one cannot automatically trust the validity of an unknown email address, other (non-technical) means will be required to determine whether or not a Matrix user is who they claim to be. It will be far more interesting, from a security standpoint, when Matrix's identity-management model is fleshed out to support things like end-to-end encryption and public-key cryptography.

Whether or not Matrix takes off as a realtime chat protocol will be interesting to watch. It is certainly true that IRC, despite all of its limitations, has resisted numerous challenges from up-and-coming communication schemes. But Matrix may have a key factor working in its favor: no reliance on a centralized server to coordinate conversations. In some circles, certainly, that is a long-requested feature.

Comments (46 posted)

Stem 1.3 makes hidden services easier to deploy

The Tor project recently released a new version of Stem, its Python library for monitoring and controlling a Tor connection. The release includes speed improvements and some new utilities, but the key feature is simplified tools for starting and running Tor hidden services.

Stem has been in development since late 2011. It replaced a older library called PyTorCtl that was designed for Tor's "bandwidth authorities"—a set of trusted Tor directory authorities that actively measure the bandwidth of the network in order to spread the load out as evenly as possible. The older library worked, but lacked the flexibility needed to be useful for many other Python projects. The 1.0 release of Stem arrived in March 2013, and there were 1.1 and 1.2 updates subsequently. 1.3 was announced on December 22, 2014.

Stem is available through the Python Package Index (PyPI) and there are packages available for many Linux distributions as well. Python 2.6 or newer is required, and the library works with Python 3.

The changelog for the new release highlights a handful of new additions. There is a considerable speed-up (on the order of 40%) when parsing the status documents sent out by Tor directory authorities and mirrors. Critically, the update also refreshes the list of Tor directory authorities itself—since Tor is expected to be most useful in environments where the network itself cannot be trusted, it may not be possible to reliably retrieve such a list over the Internet.

There are also new methods for querying the current state of the Tor connection. get_effective_rate() returns the maximum rate supported by the connected Tor relay, while connection_time() returns the Unix timestamp when the current connection was opened (if it is still open) or closed (if the current connection is closed). get_accounting_stats() returns a number of statistics (such as the number of bytes written and read) about the current connection in order to enable connection accounting.

Hidden services

But the big addition is a suite of methods for working with hidden services. For the unfamiliar, a Tor hidden service is a server program whose connection to the network is bound to a Tor node, and not to any port on a public IP address. The most common examples are running a web server or SSH server that is only connected to Tor (and, thus, is reachable only through the .onion pseudo-domain). Historically, setting up a hidden service was not an arduous process, but it did require editing several text configuration files and restarting the tor daemon.

The new method available through Stem is simpler. Stem's core module is the Tor Controller, which provides a high-level API for opening, configuring, and monitoring a Tor connection. Stem 1.3 adds four new methods that allow developers to work with hidden services directly through the Controller interface. They are:

• create_hidden_service(), which sets up a hidden service on the running Tor connection
• remove_hidden_service(), which shuts down a hidden service
• get_hidden_service_conf(), which return information about the currently running services
• set_hidden_service_conf(), which creates and sets up multiple services at once, based on a configuration file

Creating a new hidden service requires calling the create_hidden_service() method with at least two parameters: the directory path where the hidden service's files are located (for example, the web server configuration and data) and a virtual port number on which the service will be accessible (that is, the "port" on the Tor connection endpoint, analogous to a normal TCP port). One can optionally add two other parameters: the IP address of the host running the service (which, by default, is assumed to be 127.0.0.1) and the port number of the service (which, by default, is assumed to be the same port number as the virtual port parameter provided). If Tor succeeds in setting up the hidden service, it hands back the .onion address of the new service in return.

A hidden service can be shut down by calling

    remove_hidden_service(ServicePath,ServicePort)

create_hidden_service() returns a dictionary containing the configuration of the newly created service. When get_hidden_service_conf() is called, it will return a dictionary including the state of all active hidden services. Conversely, calling set_hidden_service_conf() with a dictionary will launch all of the services detailed in the dictionary, so it is fairly easy to save and restore the state of a configuration even when managing multiple services.

In earlier Stem releases, the library was usually promoted as a way to automate the connection set-up and tear-down process—much like Tor's now-discontinued GUI tool Vidalia would do. While it is certainly nice to be able to monitor the status of a Tor connection, this new hidden-service functionality may have more wide-reaching impact.

In the past few years, Tor has been a wild success story in many places around the globe, but that success has almost always been on the "read" site of the network pipe—in other words, Tor allowing a user to access the Internet with privacy and anonymity. Hidden services are meant to be the flip side of that coin: allowing users even in hostile environments to publish web sites and provide network services of their own. Stem 1.3's advancements in this area may not make running hidden services trivial, but they do at least provide a means for other software projects to make hidden services more available to Tor users.

Comments (1 posted)

Security quotes of the week

Comments (20 posted)

bind: denial of service

Comments (none posted)

chromium-browser: multiple vulnerabilities

Comments (none posted)

e2fsprogs: code execution

Comments (none posted)

hexchat: SSL spoofing

Comments (1 posted)

java: multiple unspecified vulnerabilities

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

krb5: denial of service

Comments (none posted)

llvm: insecure temporary files

Comments (none posted)

mantis: multiple vulnerabilities

Comments (none posted)

mediawiki: multiple vulnerabilities

Comments (none posted)

moodle: information disclosure

Comments (none posted)

ntp: multiple vulnerabilities

Comments (none posted)

postgresql: multiple vulnerabilities

Comments (none posted)

rsync: code execution

Comments (none posted)

virtualbox: multiple unspecified vulnerabilities

Comments (none posted)

xen: multiple vulnerabilities

Comments (none posted)

zarafa: denial of service

Comments (none posted)

Kernel release status

The merge window for the next development cycle is currently open; see the separate article below for details.

Stable updates: 3.18.6, 3.14.32, and 3.10.68 were released on February 6, followed by 3.18.7, 3.14.33, and 3.10.69 on February 11.

Comments (none posted)

Quotes of the week

Comments (none posted)

The 3.20 merge window opens

• The core of a new live-patching mechanism has been merged. This core is meant to support both kGraft and kpatch, though additional work will be required to get there. Meanwhile, what the kernel has now is enough to support the live application of simple security patches. See this merge commit for some more information or this commit for an example of a simple live patch.

• The kernel can be built to run read-copy-update (RCU) grace-period-handling threads at realtime priorities. Most systems do not need this, but some heavy workloads can benefit from this feature.

• As was threatened last year, the implementation of the remap_file_pages() system call has been removed. In its place is a function that emulates the same functionality using multiple virtual memory areas, so the (few) applications using this call should continue to work.

• The perf tool has seen the usual range of improvements; see the changelog on this merge commit for the list.

• The network stack can now support the application of specific congestion-control algorithms on a per-host basis via the routing table. This patch includes documentation updates showing how the new ip route commands work.

• The network stack's TIPC implementation is now namespace-aware.

• The traffic control subsystem now supports the application of filters written in the eBPF virtual machine language.

• The Open vSwitch subsystem can now generate its own "flow IDs" to identify network streams in user-space command traffic. This change, it is said, can improve performance of some operations by 40%.

• New hardware support includes:
  • Audio: Studio Evolution SE6X sound cards, Intel Cherrytrail and Braswell systems with RT5645 codecs, and NVIDIA Tegra boards with RT5677 codecs.

  • Input: Betop Production Inc. force-feedback devices, Allwinner sun4i tablet keys, TI TPS65218 power buttons, X-Powers AXP20X power buttons, NI Ettus Research USRP E3x0 Buttons, and Allwinner A10 PS/2 controllers.

  • Miscellaneous: Diolan DLN2 USB-SPI adapters, STMicroelectronics SSC-driven SPI controllers, Maxim 77843 regulators, MediaTek MT6397 PMIC regulators, Synopsys DDR memory controllers, Fujitsu Semiconductor F_SDH30 SDHCI controllers, Richtek RT5033 battery fuel gauges, Maxim MAX77693 battery chargers, LTC2941/LTC2943 battery gauges, and TI OMAP OPA362 external analog amplifiers.

  • Networking: Rockchip SoC RK3288 10/100/1000 Ethernet controllers, HISILICON P04 Ethernet controllers, TI Keystone NETCP Ethernet subsystems, Kvaser USBcan II CAN interfaces, and PEAK PCAN-USB/USB Pro CAN-FD interfaces.

  • SCSI: Qualcomm UFS PHYs.

  • Video4Linux: TI AM437x VPFE video capture devices, Philips RC5/RC6 decoders, and Touptek USB cameras.

Changes visible to kernel developers include:

• The sleepable read-copy-update subsystem can be compiled out of the kernel to free up some space on tiny systems where it may not be needed.

• The might_sleep() debugging function will now check for stack overflows if things look wrong. It seems that, often, what looks like an inappropriate call to a sleeping function is actually an artifact caused by a stack overflow.

• The new devfreq_event mechanism provides a way for device power-management governors to get raw data on device performance and utilization.

There are a couple of things worth keeping in mind with regard to the rest of this merge window. One is that, according to linux-next maintainer Stephen Rothwell, this release may be the smallest in some time. The linux-next repository peaked out at just over 8,000 changesets; pre-3.19 linux-next had almost 11,000. So this could end up being a relatively quiet cycle overall.

The other is that there is still a possibility that the resulting kernel might not be called 3.20. Back in 2013, Linus had suggested that the kernel coming after 3.19 might be called 4.0. As with the 3.0 bump, this change would have no particular meaning; it's just that Linus doesn't want to return to "release numbers where I have to take off my socks to count that high again". He has said nothing recently about going to 4.0, but that change could happen anytime in the next few weeks. Stay tuned.

Comments (2 posted)

Inheriting capabilities

Linux capabilities have long been seen as a way to avoid setuid programs, though the reality hasn't really lived up to the hope. While partitioning root privileges into distinct, fine-grained permissions has a lot of conceptual merit, the implementation suffers from a number of shortcomings that make it difficult to, say, use capabilities to allow ping and other utilities to run without being setuid root. Actually using capabilities has always been complex, and there are some fundamental limitations that are sometimes worked around in out-of-tree patches. A recent discussion on the linux-kernel mailing list looks at one of the limitations of the capabilities model, with an eye toward eliminating it.

Under the current model, processes cannot easily pass their capabilities to another program through an execve() call in the same way that other privileges are inherited. Christoph Lameter posted a patch that would allow administrators to specify which capabilities should be inherited by programs started by execve(). The idea is to allow privileged, non-setuid-root programs to spawn other programs with a limited set of privileges—exactly the kind of facility that capabilities are supposed to provide.

We have looked at Linux capabilities multiple times over the years, often in the context of a new attempt to fix some of the deficiencies in the existing Linux capabilities model (which is derived from a defunct POSIX effort). For example, file-based capabilities were added to use the extended attributes (xattrs) on program files to store capability information so that those capabilities were granted to programs when they were executed. Adding that allowed the CAP_SETPCAP capability to return to its original meaning and provided a way for administrators to grant capabilities to individual programs (rather than running processes). There are other problems we have noted; in some sense, this article is a continuation of that trend.

Lameter described his use case in the patch. He runs a network stack in user space that requires privileges for raw network access, but also may run arbitrary binary programs. He would like to restrict what those programs can do, but needs them to have a certain subset of root privileges. That could be done using setuid programs, but he would like to restrict those programs so that they don't get all of root's privileges.

A 2006 LWN article that Lameter referenced in his posting describes the underpinnings of capabilities. In particular, it looks at the different capability sets and how they are combined to determine which capabilities a process has.

This first patch from Lameter provides a way for an administrator to globally specify which capabilities should be inherited across execve(). Capability numbers could be written to a sysfs file, which would cause those capabilities to be inherited by any new program if the caller of execve() possessed them. He has been using a form of the patch in production for the last six years, but would like it (or something that solves the same problem) to go upstream, so that he doesn't need to continue carrying the patch in his kernels.

The usual way to make a binary run with some capability is to put that capability in the "permitted" and "effective" sets of the binary using the file capabilities xattrs. Doing that makes those binaries always have those capabilities, however, which may not be desired—especially for system binaries. Without putting file capabilities on many different binaries throughout the system, there is no way to pass CAP_NET_RAW (or others, such as CAP_NET_ADMIN and CAP_SYS_NICE) down to child processes or new programs started with execve(). Also, given that there is scripting (and LD_PRELOAD) involved in Lameter's use case, it would be necessary to give script interpreters (e.g. Bash, Python) whichever capabilities the scripts need—something that is not likely to lead to a more secure system.

It looks like a fundamental limitation of the Linux capabilities model, but is hardly the first. Capabilities bits have been arbitrarily chosen by kernel feature developers over the years, without much in the way of coordination. That has led to grab-bag capabilities like CAP_SYS_ADMIN that are effectively equivalent to root (though there are others where that is also true). Whatever can be said about the Linux capabilities feature, coherence in its design and implementation are not particularly evident.

But people who want to use the feature keep running up against barriers to doing so. As Serge Hallyn, one of the developers of capabilities, lamented, it is still not possible to make ping use capabilities (rather than setuid) by default. That's because some filesystems don't have support for xattrs; it's also true for some of the tools, such as older versions of tar and current versions of cpio (though work is being done to change that).

But the global nature of the inheritance setting in Lameter's patch set was not popular. Both Hallyn and Andy Lutomirski suggested ways to make it a per-process or per-user-namespace setting. Hallyn suggested adding an "ambient inheritable" set that would be combined with the inheritable set in a way that is somewhat analogous to the capability bounding set. Lutomirski thought that a single bit could be used to say that all files should be considered to have a full set of capabilities in their inherited set, which would basically have the same effect.

But Casey Schaufler objected to the idea that Lameter's use case was reasonable from a security perspective: "You're getting into pretty sketchy territory using that kind of a programming model in a security enforcing environment." Though he also responded to Lameter's claim that there is a "capabilities mess" that needs to be cleaned up:

There was some discussion of ways that capabilities could be improved but, as Lutomirski noted, none of that addressed the problem at hand: "If I hold a capability and I want to pass that capability to an exec'd helper, I shouldn't need the fs's help to do this." There was general agreement, though Hallyn pointed out that using the filesystem to place capabilities on binaries is how POSIX capabilities work.

One interesting side note from the discussion is that Lameter is not the only one to use inheritable capabilities in production: the MeeGo-based N9 phone from Nokia did as well.

After that discussion, Lameter shifted gears, posting an RFC patch to implement Hallyn's suggestion of an ambient capability set. That was met with a couple of objections on some of the specifics. To start with, adding capabilities to the ambient set should not enable capabilities that are not in the permitted set of the process, Lutomirski said. He also suggested that adding capabilities to the ambient set should require more than just having the CAP_SETPCAP capability. Requiring PR_SET_NO_NEW_PRIVS (see this article and Documentation/prctl/no_new_privs.txt for more information), so that execve() could not add any additional privileges, would make him more comfortable. But that "would make the patch pointless" because programs that require more privileges (e.g. setuid root programs) need to be run sometimes, Lameter said.

Given Lameter's use case, requiring PR_SET_NO_NEW_PRIVS would seem to be a non-starter, but he has addressed the other complaints from Lutomirski and Hallyn in his V1 ambient capability set patch. In that version, only capabilities that are permitted can be added to the ambient set. In addition, processes can clear their permitted set and be sure that no new capabilities will be granted to children or programs run via execve() based on the contents of the ambient set. That was one of the main concerns expressed about the RFC patch.

As was noted in the threads, there are a number of barriers in the way of using capabilities on Linux systems. They are complex to reason about, have an API that is difficult to use, and have been inconsistently applied over the years. All of that is unfortunate, but any movement to remove capabilities and start over, as was suggested, is pretty unlikely to gain any traction. For good or ill, capabilities are part of the kernel ABI and are thus likely to be with us "forever". Changes like the ambient set may not reduce the complexity at all, but may help provide a more usable capabilities system going forward.

Comments (10 posted)

The bootstrap process on EFI systems

This article won't cover the basics of booting Linux on BIOS, since that's been covered elsewhere . Instead, it will focus on the particulars of booting on EFI and how the state of the art has changed over time to adapt to the needs of the kernel community and its users.

Legacy EFI boot

Up until Linux 3.3, the only way to boot Linux on EFI hardware was to use an EFI OS loader. This process begins with the EFI firmware boot manager loading a boot loader, such as GRUB. The boot loader is then responsible for loading the Linux kernel and any ramdisk images, taking control of the platform from the firmware, and jumping to the kernel entry point. At a high level, this is all very similar to the way things work on legacy BIOS platforms. In fact, there are very few places where the kernel really knows it was booted from EFI and not BIOS — most of the intricacies of booting on EFI platforms are hidden inside the boot loader.

If you're trying to bring up Linux on a new firmware, keeping the process as similar as possible to that used on existing, working systems is highly desirable. It achieves maximum code reuse both in terms of boot loader source (since most things just need to be recompiled for the firmware's executable file format) and the difficult-to-debug early kernel boot code. When x86 EFI systems first started hitting the consumer market, making the fewest changes possible was the safest strategy. Of course, there are some special steps that an EFI boot loader must perform, and a handful of EFI-specific pieces of information that need to be passed from the boot loader to the kernel.

For a start, EFI firmware has two very distinct phases of execution delimited by the termination of the EFI "Boot Services." Initially, the EFI firmware has control over the platform. This allows the firmware to provide a variety of services, such as memory allocation, timers, and event services, to EFI applications and drivers. These are known as Boot Services. It is the boot loader's responsibility to terminate Boot Services by calling the firmware's ExitBootServices() function and transition to the second phase of boot (the EFI Runtime Services will remain available). Once ExitBootServices() has been called, the firmware relinquishes control of the platform to the OS loader, and ultimately, to the kernel. From that point forward the kernel owns the platform and can install page tables, interrupt handlers, and bring memory allocators online; all the things that usually happen during kernel boot.

Crucially, some properties of the platform and its devices cannot be discovered post-ExitBootServices() because Boot Services functions are required to identify them. The boot loader therefore has the additional responsibility of doing this discovery, stashing the data, and handing it to the kernel inside of a struct boot_params object. The relevant members of this structure for EFI boot are highlighted below,

    struct boot_params {
	struct screen_info screen_info;
        ...
	struct efi_info {
	    __u32 efi_loader_signature;
	    __u32 efi_systab;
	    __u32 efi_memdesc_size;
	    __u32 efi_memdesc_version;
	    __u32 efi_memmap;
	    __u32 efi_memmap_size;
	    __u32 efi_systab_hi;
	    __u32 efi_memmap_hi;
	} efi_info;
	...
	__u8  e820_entries;
	...
	struct setup_header {
	    ...
	    __u64 setup_data;
	    ...
	} hdr;
	...
	struct e820entry e820_map[E820MAX];
	...
    };

The important pieces of data in this structure are:

• The EFI memory map and associated data (found in efi_info.efi_memmap and efi_memmap_hi).

• The EFI System Table pointer (stored in efi_info.efi_systab and efi_systab_hi).

• Graphics (screen_info) and PCI device information (hdr.setup_data).

Despite the fact that struct boot_params already contains an E820 table (e820_map) describing all memory regions, the EFI memory map is also saved and passed to the kernel since it includes EFI-specific region types and other region attributes. The EFI System Table contains data used by the kernel at runtime; for example, it holds a pointer to the Runtime Services dispatch table, which is used by the kernel to do things like create, delete and update EFI variables. The details of any graphics devices present on the platform are stored in boot_params.screen_info; key details being the physical address and size of the frame buffer. And finally, PCI device details are recorded in a singly-linked list at boot_params.hdr.setup_data.

Once the boot loader has gathered all of this data, loaded the kernel and optional ramdisk files, and terminated Boot Services, it prepares to jump to the kernel entry point and resume the common boot process.

With the influx of x86 EFI implementations into the market in 2012, there was a wide variability in their quality, which meant there were a lot of bugs. The most publicized bug was the Samsung bricking issue, which affected some Samsung laptop models and, once encountered, resulted in users being entirely unable to boot their machines. Some bugs were worked around inside the kernel without too much problem, some were handled in the boot loader. But one thing was clear — the situation was not going to improve overnight.

Furthermore, because it was impossible to guess at the kind of bugs that would be seen in the future, a more robust solution was needed — one that would not require kernel and boot loader support to be developed in lockstep. The kernel developers needed a way to make changes quickly as new bugs were discovered. A solution was proposed by H. Peter Anvin, and immediately backed by Linus: the kernel would become the boot loader.

EFI boot stub (CONFIG_EFI_STUB)

Peter's idea was to carry a "boot stub" in the kernel image that would take on the responsibility of terminating Boot Services. In some scenarios, this obviates the need for a Linux boot loader entirely. The major benefit that comes with giving the kernel the responsibility for calling ExitBootServices() is that it gains control of the platform much earlier than is otherwise possible. That means it can apply bug workarounds much sooner in the boot process. Furthermore, distributing workarounds for firmware bugs to end users now only requires a kernel upgrade, instead of a boot loader upgrade, because the boot ABI would remain unchanged.

The EFI boot stub doesn't actually live in the kernel proper. Rather, it is a small piece of code that is prepended to a compressed kernel image, and is executed directly by the boot loader or the firmware Boot Manager. So that EFI firmware understands how to load and execute a kernel with the EFI boot stub, a Portable Executable (PE) image header is inserted into the kernel image at build time. To the firmware, the kernel appears to be a legitimate EFI application, complete with entry point address, section tables and relocation information — the kernel image is said to "masquerade" as an EFI application.

As luck would have it, the only important fields in the PE header that overlap with the bzImage header found at the start of the kernel image are the "MZ" magic string (offset 0x0) and the field that points to the rest of the PE header (offset 0x3c). These fields can be inserted into the existing bzImage header without causing trouble because the bzImage uses those addresses to store code that is only ever executed by unsupported legacy boot loaders to print an error message. The rest of the PE header, pointed at by offset 0x3c, is located at an arbitrary position within the first 512 bytes of the image and contains information such as the EFI boot stub entry point, the architecture the kernel was compiled for, number of sections, size of the image, and other miscellaneous items used in describing a PE application.

The entry point for the EFI boot stub conforms to the ABI defined in the EFI specification:

    EFI_STATUS efi_main(EFI_HANDLE handle, EFI_SYSTEM_TABLE *table);

Once the firmware loads the kernel image and jumps to the EFI boot stub entry point, the boot stub begins performing all the necessary jobs for the OS to take control of the platform, just like the boot loader in the legacy EFI boot.

First, this involves building a struct boot_params object, loading any ramdisks specified on the command line, discovering the platform topology and stashing the information for later processing by the kernel. Secondly, ExitBootServices() is called and the kernel takes control of the platform. Because all these steps are performed inside the boot stub, it entirely replaces the need for a Linux boot loader.

Despite the fact that boot loader functionality needs to be re-implemented in the boot stub, the size of the code is actually fairly small. The boot stub uses the Boot Services provided by the firmware for things like memory allocation, filesystem access and printing to the console; the boot stub does not include any drivers of its own.

This lack of drivers highlights one of the drawbacks of booting using the EFI boot stub. Remember, the boot stub isn't part of the kernel proper, so no matter which drivers you build into your kernel, the boot stub can't use them to load files from Linux filesystems. For most platforms, this ultimately means it is not possible to boot Linux directly from Linux filesystems. Instead, the kernel image and any ramdisk images need to reside on media that the firmware contains built-in drivers for. Essentially, this means the EFI System Partition (ESP) or some other FAT filesystem.

Additionally, because the PE header contains an architecture field, it's not possible to boot a 64-bit kernel image on 32-bit firmware using the EFI boot stub, since the firmware PE image loader will complain that the file has an incompatible architecture. While these restrictions are acceptable in many situations, some users want to take advantage of the EFI boot stub, but not at the expense of sacrificing a polished boot experience.

EFI handover protocol

The EFI handover protocol first appeared in Linux 3.6. It provides a middle ground by combining the best of the legacy and EFI boot stub schemes: being able to boot from Linux filesystems while applying workarounds in the boot stub. This protocol defines a new entry point into the kernel image — one that points after the code to allocate a boot_params structure in the EFI boot stub. The EFI handover protocol cannot be used by EFI firmware because the entry point does not use the EFI application ABI, so a Linux boot loader is required.

Internally, jumping to the EFI handover protocol entry point still handles early device discovery, saving of the EFI memory map data, and termination of the Boot Services. Since entering the handover entry point skips the struct boot_params initialization and loading of ramdisk files, the boot loader is responsible for allocating the object and accessing the filesystem. In the process, a Linux boot loader can provide the features that many users have come to expect: loading from Linux filesystems, graphical boot menus, configuration files, etc.

A Linux boot loader finds the entry point for the handover protocol by looking at the handover_offset field of the boot_params.hdr kernel header:

    struct boot_params {
	...
	struct setup_header {
	    ...
	    __u32	handover_offset;
	} hdr;
    	...
    };

The value of this field is an offset from the beginning of the kernel image, and the runtime entry point address can be calculated by adding boot_params.hdr.handover_offset to the kernel image load address.

The entry point prototype looks like this:

    void handover(EFI HANDLE handle, EFI_SYSTEM_TABLE *table,
    	 	  struct boot_params *bp);

The handover protocol can be thought of as a subset of the EFI boot stub, since code executed by the handover protocol is also executed by the EFI boot stub (but not vice versa).

Summary

Each of the schemes discussed above solves a different problem. If you need the ability to boot from Linux filesystems, using a Linux boot loader such as GRUB with the EFI handover protocol would be the best option since the advantage of using the latest kernel workarounds for firmware bugs is retained. If you just need to load a kernel quickly with no frills, look at booting with the EFI boot stub directly from the firmware.

It's possible to pass the usual kernel parameters directly to the EFI boot stub, but most are silently passed through to the kernel proper. However, the initrd= option is interpreted directly by the EFI boot stub and allows initial ramdisks to be loaded from the ESP and other firmware-supported filesystems.

Support for building the EFI boot stub is enabled by turning on the CONFIG_EFI_STUB option in the kernel config. Gummiboot is an EFI application loader that leverages kernels built with CONFIG_EFI_STUB, and there is no Linux-specific boot code to be found anywhere in the source. It uses the the LoadImage() and StartImage() Boot Services provided by the firmware to load and run kernel images. I also use CONFIG_EFI_STUB kernels containing an embedded ramdisk to boot bare-metal EFI machines.

The EFI handover protocol entry point is exported when the CONFIG_EFI_STUB kernel option is enabled. The versions of GRUB 2 shipping with major distributions (Fedora, Ubuntu, Debian) include support for booting via the EFI handover protocol. Use of this protocol is enabled with the "linuxefi" GRUB command (with corresponding initrdefi commands for initial ramdisk files), which are used in the same way as the legacy linux (and initrd) commands, e.g.

    linuxefi  /boot/efi/EFI/vmlinuz.efi
    initrdefi /boot/efi/EFI/initramfs.img

The handover protocol is also used by Tianocore's OVMF firmware for QEMU when using the -kernel command line parameter to directly boot a kernel, e.g.

    qemu-system-x86-64 -kernel /path/bzImage

Whichever option you pick, the beauty is that a single kernel image can be built that supports all of the schemes.

Comments (10 posted)

CrunchBang Linux exits the stage

On February 6, CrunchBang Linux founder Philip Newborough announced that he would halt development of the distribution. The reason for the decision, he said, was that the landscape of Linux distributions has changed considerably over the years, and in the current climate, there was no longer a need for CrunchBang. In the long term, of course, distributions (like other free-software projects) come and go, but this announcement was still a sad one for many in the community.

Newborough posted the shutdown announcement on the CrunchBang forum, thanking his wife and the CrunchBang community for their years of support. Regarding the decision to stop development, his comments were brief:

Newborough did say that the CrunchBang forums will remain online, and that he is happy to support them for as long as is necessary. The response from the forum users was swift and sizable; 14 pages (and counting) of messages followed, with almost all expressing a combination of disappointment at the loss of CrunchBang and gratitude to Newborough for his years of coordinating the project.

For those who are unfamiliar with its history, CrunchBang was started in 2008, when netbooks like the Eee PC were first hitting the store shelves. Those machines were notorious for their lack of processing power and memory in comparison with contemporary desktop hardware. The distinction between "low resource" and "standard" hardware specs has become far more blurry in recent years, but when the netbook craze started, it necessitated taking a different approach to provide a usable, responsive desktop environment.

CrunchBang was one of those projects that took such an approach. It bundled Debian with the lightweight Openbox window manager. Openbox is one of several stacking window managers for X, one that can run with significantly less GPU power by omitting window compositing and other graphical enhancements. There have been numerous other "lightweight" desktop distributions over the years, but CrunchBang fans consistently praised the work that went into integrating Openbox with other features so that it serves as a modern environment—and not just a generic package with minimal features. CrunchBang's desktop and GUI themes have always been regarded as well-made, with attention paid to the details, and the project provided a set of well-tested Python scripts to replicate the "modern" features implemented in more heavyweight window managers or desktop shells.

Nevertheless, since 2008 there has been no shortage of "lightweight" desktop distributions available. Another change in recent years is that the Debian community now actively supports Openbox and several other lightweight desktop environments and window managers (e.g., Xfce and FluxBox), making it comparatively simple to set up a CrunchBang-like system.

Still, there is a significant difference between the ability to install and configure Openbox and the ability to boot into a ready-to-use CrunchBang system. Consequently, not everyone on the forum concurred with the notion that vanilla Debian was a suitable CrunchBang alternative. Forum commenters brought up several other potential replacements, such as antiX and Semplice. Both are Debian-based distributions that focus on lightweight window managers—although neither uses OpenBox.

Forum user pvsage announced an effort to explore resurrecting CrunchBang under a new name (initially "Sparkle Dancer" but, more recently, "Debarchery"). Newborough responded to that idea with his encouragement. Users interested in the idea have since started a separate discussion thread on the CrunchBang forum to discuss it. So far, though, progress on a revived distribution remains in the planning stages.

Even if switching to a new distribution (be it pvsage's replacement or an unrelated lightweight distribution) is eventually necessary, the other lingering question is what existing CrunchBang users need to do in order to keep their systems running and up-to-date. Forum user iMBeCil responded that there were plenty of CrunchBang users who would still benefit from seeing the next planned CrunchBang release, tentatively named Janice, actually delivered.

At present, it seems that the Janice release has simply been scrapped altogether, which could understandably be a source of anxiety for users. More than a few forum members asked about the possibility of the community raising funds to underwrite continued development—and, evidently, one forum member even went so far as to set up a fundraising site, although forum moderators subsequently removed the post.

The good news is that the current CrunchBang release, Waldorf, should continue to work with the Debian wheezy repositories for the foreseeable future. And, as forum user tknomanzr commented, adapting Waldorf to work with the Debian jessie repositories works as well, with only "a few hitches" concerning GTK+ themes. There is also a guide available that details the steps to update a Waldorf system to run on top of Debian unstable.

Whenever jessie is released, Debian wheezy will become the oldstable distribution, at which point it will continue to receive backported security updates until the debut of the Debian stable release after jessie. That will add up to a significant amount of time, so the CrunchBang community will not be left in a vulnerable position any time soon.

Still, it is always sad to see a distribution close its virtual doors, and CrunchBang was always a distribution that drew praise for its merits, not on glitz or on dubious claims about performance or style. In short, Newborough and CrunchBang earned fans by executing well. There may yet be a future for many of the ideas that made CrunchBang useful for its user base, but measuring up to CrunchBang's reputation isn't trivial.

Comments (4 posted)

Distribution quote of the week

Comments (none posted)

The end of CrunchBang Linux

Comments (31 posted)

New Debian security mirror for Asia

Full Story (comments: none)

Bits from the NM process

Full Story (comments: none)

Project Secretary appointment

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 596 (February 9)
• Ubuntu Weekly Newsletter, Issue 403 (February 8)

Comments (none posted)

The first Tizen smartphone isn’t an “Android killer”—it’s a bad Android clone (ars technica)

Comments (58 posted)

GCC 5 in Fedora (Red Hat developer blog)

Comments (40 posted)

Fed up with systemd and Linux? Why not try PC-BSD? (ITWire)

Comments (2 posted)

Open-source FPS gaming with Xonotic 0.8

Linux has been getting more attention from commercial developers as a gaming operating system. With the Steam gaming service available natively for Linux, major video game companies have been porting popular proprietary games to the platform. But there are also many quality open-source games for Linux, with some, such as the first-person shooter (FPS) Xonotic, able to hold their own against their better funded, professionally developed competitors. Xonotic's recent 0.8 release, which comes a year and a half after 0.7, adds an "Invasion" game mode, a new lightning weapon, and other new features—it packs in lots of fun for open-source game players.

FPS games all have several things in common. Players have a first-person perspective in a three-dimensional game world. A variety of weapons are available for slaying enemies and the player character has a health meter that tracks any damage received. If the meter drops to zero, the player character dies. The primary gameplay goals are typically achieved by slaughtering opponents using the weaponry.

Amidst the competition, Xonotic offers something unique. It is a hectic, fast-paced multiplayer shooter with a variety of modes and interesting weapons. For example, there is a "Capture the Flag" mode that uses grappling hooks to propel characters lighting-fast around the map and has sniper rifles to put a quick stop to an escaping flag-carrier. Succeeding in this mode, which pits two teams of human players against each other, relies on sharp reflexes and good instincts. There is just a fraction of second after identifying an opponent to snipe them down; any hesitation and they'll be a mile away. But being too trigger-happy can be a liability, one that may result in slaying a teammate by accident.

There's also a "Key Hunt" mode: each team has a player who holds a key, and killing the opponent's key holder is the path to victory. "Onslaught" requires teams to destroy enemy power generators while protecting their own. Those interested in something a bit more silly can try "Nexball", which is a weapon-free game of soccer.

Weapons in Xonotic include familiar FPS staples like shotguns and machine guns, but also some unique weaponry. There's the Crylink, which can shoot several bursts of energy that can bounce off walls. A player more interested in demolitions can try the Hagar, a rapid-fire rocket launcher, or the grenade-launching Mortar.

With the latest 0.8 version, there is a new "Invasion" mode, where players fight off waves of monsters. This is reminiscent of popular, survival-horror-themed FPS games, like the Left 4 Dead series and Killing Floor, which both feature cooperative, team-based multiplayer modes that make players fend off ever more dangerous swarms of computer-controlled enemies. However, while the code for Invasion mode is in 0.8, there are no maps yet; Xonotic developers are considering holding a contest to make maps for the mode. When these maps come out, the new lightning gun, named Arc, should come in handy. It shoots out a ray of energy for powerful close-quarter combat but can overheat if used to excess.

There are a large number of public multiplayer servers to choose from. Unfortunately, only a few are populated, but there are enough to ensure that one will always find a game to play. The server hosted by Jupiter Broadcasting, an information-technology podcasting company that has drawn attention to Xonotic, is almost always populated, so those in North America should try that one. For those on the other side of the Atlantic, there are popular servers in Europe that are mostly German-speaking. You'll be too busy trying to survive to chat much, though, so a language barrier really isn't a concern. Servers are also available in Japan and Australia.

From the main menu, players can choose a single-player mode, which is purely a tutorial to learn the game and to practice against computer-controlled opponents, the multiplayer mode (where the meat of the game is), and the options menu. In the latter, players can change a variety of settings including controls for graphics quality. It's not necessary to have the latest NVIDIA or Radeon GPU to enjoy Xonotic, as it can be run on its lowest graphical settings on machines with low-end graphics. I was able to run the game on almost maximum graphics quality (disabling bloom purely out of preference though, since it was way too bright for my liking) on my laptop with Intel HD 4000 integrated graphics.

The player base is quite active. Discussions on the official forums range from new players introducing themselves to news about official and unofficial tournaments for those interested in competition. For instance, a group of dedicated players set up an official "defrag championship" with cash prizes for the winner.

On the technical side, Xonotic is based on the engine from Quake 1, which is one of the most influential FPS games made. One might be startled to think that a twenty-year-old engine is powering this game, but a Jupiter Broadcasting podcast interview with developer "Antibody" noted that the Xonotic engine involved "lots of modifications, stripping it all the way down, building it all the way up". With the 0.8 version, the code now relies on Simple DirectMedia Layer 2.0, the latest version of the "cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D".

Xonotic is free software, which makes it an excellent means for aspiring game developers to see (and modify) working game code. The game was originally called "Nexuiz", but a dispute over naming and rights to the code led to a name change. The Xonotic FAQ page has the details of the change. The game is packaged for many Linux distributions, with the code and art assets available under GPLv2-or-later. The binaries for Linux and Windows also incorporate the LGPLv3-or-later GNU Multiple Precision Arithmetic Library (GMP). For those who don't have the latest version available in their distribution, there's one unified download that contains binaries for Linux, Windows, and OS X.

The project continues to be actively developed. Xonotic developer "TimePath" is planning to archive older branches to remove clutter from the tree in order to facilitate further development. Progress is being made on the user interface, with a recent focus on improving the in-game weapons panel (indicating which weapons are possessed). Those interested in contributing can check out the project's GitLab repositories, where one can see frequent patches and engaged commentary about development. The official Xonotic website was also updated a couple weeks ago to look more modern. Xonotic continues to showcase some of the best in open-source game development and gameplay—I look forward to seeing the project continue to grow.

Comments (none posted)

Quotes of the week

Comments (3 posted)

GNU C library version 2.21 released

Full Story (comments: none)

ownCloud Server 8 released

Comments (14 posted)

Git v2.3.0 available

Git version 2.3.0 has been released. New in this release are "lots of small corrections and improvements without big uncomfortably exciting features", although many Git users may find something to be excited about. Included in the small improvements are a new environment variable for use in passing extra arguments down to ssh, the ability to try multiple credential helpers in turn until one of them succeed, and numerous new flags for various subcommands.

Full Story (comments: 9)

Development newsletters from the past week

• What's cooking in git.git (February 5)
• Haskell Weekly News (February 4)
  (Readers should take note that, as of this issue, longtime HWN editor Daniel Santa Cruz is stepping down, and HWN will only continue if a new editor can be found.)
• LLVM Weekly (February 9)
• OCaml Weekly News (February 10)
• OpenStack Community Weekly Newsletter (February 6)
• Perl Weekly (February 9)
• PostgreSQL Weekly News (February 8)
• Python Weekly (February 5)
• Qt Weekly (February 10)
• Ruby Weekly (February 5)
• This Week in Rust (February 9)
• Tor Weekly News (February 11)
• Wikimedia Tech News (February 9)

Comments (none posted)

GCC5 and the C++11 ABI (Red Hat developer blog)

Comments (29 posted)

FSFE: Show your love for Free Software

Full Story (comments: none)

FSF JavaScript guidelines picked up by Posteo Webmail

Full Story (comments: 1)

Second batch of ELC 2014 videos

Full Story (comments: none)

The World’s Email Encryption Software Relies on One Guy, Who is Going Broke (ProPublica)

Comments (28 posted)

Linux Plumbers Conference call for proposals

Comments (3 posted)

FUDCon APAC 2015 - Call for Papers

Full Story (comments: none)

MiniDebConf Bucharest Call for Talks

Full Story (comments: none)

CFP Deadlines: February 12, 2015 to April 13, 2015

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

NetDev 0.1 final schedule

Full Story (comments: none)

Events: February 12, 2015 to April 13, 2015

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