Leading items

X.Org mulls joining SPI

The X.Org Foundation is voting on whether or not to embark on a significant structural shift, in which it would move from a standalone nonprofit organization (in the eyes of the US Government, that is) to being a member project of Software in the Public Interest (SPI). The visible effects of the change to X.Org members should be minor, and the effects to X software users virtually nil, but the decision is still one that has ramifications and warrants a closer look.

At issue is X.Org's status as an independent entity. The organization gained formal approval by the US Internal Revenue Service (IRS) as a 501(c)(3) charity in 2012. While that is an important legal hurdle (as well as being one that other free-software projects have had difficulty in clearing), it comes at a cost. 501(c)(3) organizations enjoy tax-free status and can accept tax-deductible donations from members of the public but, in return, they must adhere to some strict paperwork and filing requirements at the IRS.

X.Org, unfortunately, has found those requirements to be a bit of a burden over the course of the past few years. That is hardly a surprise. X.Org, perhaps more so than the average free-software organization, exists almost entirely as a development entity. It does not have a marketing arm, it does not set up booths at conferences and sell T-shirts, and it does not engage in public-activism campaigns. Its members merely work on window-management software, video drivers, display servers, and related code.

SPI

But the overhead of dealing with legal issues is not a minor concern. The IRS briefly revoked X.Org's 501(c)(3) status in 2013 when the organization did not file its paperwork (a misunderstanding rooted in the fact that X.Org had no income for the year), though the status was restored in short order. The organization has also had to switch banks in recent years due to changes in the old bank's fee structures and terms of service (which is as unpleasant a process for organizations as it is for individuals). Lastly, a large percentage of X.Org members are from outside the US (which makes working on compliance with unfamiliar US tax regulations all the more burdensome for them).

In 2013, the notion began to circulate within the project that X.Org might be better off to offload the red-tape side of being a non-profit organization to an "umbrella" organization that serves that function for other projects. There are several such umbrella organizations these days: Software Freedom Conservancy, the Free Software Foundation, Apache Software Foundation, and SPI being arguably the best-known. The X.Org board of directors voted in favor of SPI at the 2013 X Developers Conference (XDC).

In February 2014, board member Martin Peres gave a FOSDEM presentation outlining the background of the proposed change and making the case that SPI was the best fit moving forward. He also created a branch of the official X.Org bylaws to track the specific changes in wording that would implement the move.

In an email, Peres noted that there was essentially no feedback at that time from the general X.Org membership. The board then turned its attention to SPI, making inquiries about how becoming a member project would affect X.Org's regular operations, its record keeping, and so on. SPI has its own process for determining whether or not to take on a given project as a member, but in February 2015 it finally notified the X.Org board that it would accept X.Org's membership application.

Unfortunately, the length of time between when X.Org first approached SPI and when the final decision came back triggered some practical problems. The X.Org Foundation bylaws state that changes must be voted on by the full membership, not just the board, so it was decided to place that question on the ballot with the annual board election—which was originally scheduled to start on March 9. But SPI had some feedback on X.Org's proposed bylaw wording. The X.Org board had asked for such feedback from SPI's stable of experienced organizational-structure specialists.

At its March 5 and March 19 meetings, the X.Org board voted to push back the election, pending the final changes to the proposed bylaw text. The changes were eventually merged in and posted [PDF] for review. Voting began on March 23 and will continue through April 5.

Revisions and ballots

Like many of the project-umbrella organizations, SPI has some flexibility in how it partners with its member projects. In the case of X.Org, the plan is for SPI to hold all of X.Org's funds and assets, provide legal representation when needed, and to handle the process of dispensing (and reimbursing) funds. As is also typical, X.Org will have the right to leave SPI at any time, and SPI will not have any input on the technical direction or inner workings of X.Org.

Although the X.Org wiki hosts a FAQ page about the proposed change, that page does not go into detail about the nature of the feedback or the wording changes discussed with SPI prior to the election. Examining the Git log for Peres's copy of the bylaws provides some more detail, though.

A March 17 revision clarifies that X.Org membership is separate from SPI membership, removes language that distinguished how donations were handled when the amount exceeded $300, and removes a statement specifying the X.Org Foundation's 501(c)(3) status. Other changes to the repository include one that removes a reference to the "seal of X.Org" from the bylaws and another that resolves a question about the bylaw prohibiting X.Org officers from borrowing money on X.Org's credit.

For X.Org members, the primary impact of joining SPI will be that money will be handled by SPI rather than by the X.Org treasurer. Whether that money relates to travel expenses, organizing XDC, or running the Endless Vacation of Code (EVoC) mentoring program, the accounting and disbursement will be handled by the SPI treasurer. Approval decisions for expenditures, however, will still be made by the X.Org board. To the public at large, the only visible difference will be that donations to X.Org must now go through SPI. While SPI retains 5% of public donations in order to underwrite its operating costs, X.Org will be entitled to receive some portion of all donations that are made to SPI's general fund because it is a member project.

The changes to the bylaws include one other noteworthy revision: the new bylaws explicitly state that X.Org's purpose includes the development and support of some other software—namely the Direct Rendering Manager, Mesa, and Wayland.

Although joining SPI may be the most fundamental question on the ballot this year, the current election is also being held to elect four of the eight seats on the X.Org board. The seats held by Peres, Alan Coopersmith, Peter Hutterer, and Stuart Kreitmann are all expiring. Peres, Hutterer, and Kreitmann are running for reelection, and are joined on the list of candidates by Rob Clark, Emil Velikov, and Daniel Vetter.

Each candidate has a brief bio and personal statement on the election page. One thing that distinguishes the X.Org board election from the Debian Project Leader election is that the X.Org candidates' question-and-answer process is conducted on the closed X.Org members' mailing list.

Although it is far from a foregone conclusion, the X.Org board's support for joining SPI and the lack of a significant opposition movement both suggest that the proposed bylaw change will be approved. For users of X, Wayland, and the other software projects, the only real impact may be that mishaps like 2013's loss of 501(c)(3) status become a thing of the past. For those watching from other software projects, X.Org's experience may be a valuable lesson in the pros and cons of existence as a separate entity versus belonging to an umbrella organization.

How such pros and cons balance out is always tricky to figure out—some participants understandably fear the loss of autonomy that might come from a bad relationship with an umbrella organization. SPI seems to have established a reliable track record over the years, of course, but it has been a while since a project on the scale of X.Org has moved from an independent to a member project. Plenty of other projects, no doubt, will be watching the outcome.

Comments (none posted)

Mailman 3.0 to modernize mailing lists

More than a decade after its last major rewrite, the GNU Mailman mailing list manager project aims to release its 3.0 suite in April, during the sprints following PyCon North America. Mailman 3 is a major rewrite that includes a new user membership system, a REST API, an archiver replacement for Pipermail, and a better web interface for subscriptions and settings — but it carries with it a few new dependencies as well. Brave system administrators can try out the fifth beta version now.

Mailman has been a ubiquitous if slow-moving part of the social infrastructure for many open-source projects for decades. More than fourteen years have passed since the Mailman 2.0 release in November 2000, twelve years since the first release of the last stable version (2.1), and seven years since first alpha of the 3.0 branch. However, Mailman has stayed under continuous development during that time; new 2.0 branch releases have come out about twice annually, with new features in point releases (e.g., the DMARC mitigations added in 2.1.16 to keeps lists from running afoul of an anti-spam measure). It supports moderation, list digests, bounce detection, spam protection, multilingual lists, archiving, and list administration via email or web interfaces, among other features. The new release aims to get rid of some annoyances and to refresh Mailman for administrators' and users' current needs.

What's new

The architecture and user interfaces of previous versions of Mailman reflect a different era of the web, and of application interoperability. Mailman 2 was a single codebase, written in Python 2, encompassing a rudimentary web application for subscription and list management (and incorporating the Pipermail web archiver) as well as the engine for receiving, moderating, and propagating messages. Lead developer Barry Warsaw explained in the overview he wrote for The Architecture of Open Source Applications that, beyond the browser-based interface, Mailman 2 also offered a dedicated command-line interface, and a Python internal API that system administrators could integrate with by writing Python code.

In contrast, Mailman 3 is a suite of five connected projects, each of which can run independently:

• The Mailman core provides the backend engine that interacts with Mail Transfer Agents (e.g., Exim, Postfix, sendmail), manages users, messages, and lists, and processes mail based on the lists' rules (e.g., filtering out spam, queueing messages for moderation, distributing them to a list's membership). Mailman core also exposes a RESTful API to provide easier integration for other applications or scripts. Mailman core is written entirely in Python 3, thus requiring system administrators to have Python 3 installed.
• mailman.client is the official Python bindings for the REST API, and requires Python 2.6 or newer.

• HyperKitty is a Django-based archiver application that replaces Pipermail, which we previewed last April. It provides a modern web interface to browse and search archived messages and threads (see this live demo); interestingly, it also allows users to post to discussions, so that by default users can interact with any Mailman mailing list as though it were a web forum, if they prefer. HyperKitty is written in Python 2. It uses mailman.client to interact with the core engine for administrative purposes, and uses Mailman core's Python-based IArchiver API to access the mailing list posts that have been successfully posted and thus should be archived.
• Postorius is a Django-based web application for administering lists and managing user preferences. The refreshed appearance (see screenshots) and theming capabilities should make it easier for communities to integrate Postorius into their websites without a jarring contrast. Postorius is written in Python 2 and, like HyperKitty, uses mailman.client to interact with Mailman's core engine.
• The bundler is a set of small Python scripts to bundle Mailman components together for easy installation.

Mailman 3 also provides improved abstractions for dealing with lists and users. Instead of using pickled files, Mailman 3 stores configuration data in a SQL database (by default, SQLite). This and other new features make it easier to (for instance) manage multiple mailing lists with the same name in different domains (e.g., dev@example.com and dev@example.org), give someone administrative power over all the lists within a domain, and provide a unified user interface to a person who subscribes to multiple lists with different email addresses.

To answer the question that at least a few dozen of you are looking for: Mailman 3 will not, by default, send you a monthly reminder that includes your password in plain text. In fact, it can't; Mailman 3 hashes passwords before storing them.

Implications

Developers are aiming for Mailman 3.0 to be at feature parity with Mailman 2.0, so users should not experience much degradation in functionality, but there are a few newer features in 2.1 that have not yet been ported forward into 3.0; this is still being finalized. Localization is still up in the air. The Mailman community is committed to improving the currently labor-intensive process it uses for managing string translations, but the developers have not yet decided on a platform for translators.

The new release includes several usability updates, such as the HyperKitty interface that allows subscribers to interact with lists via the web, and list subscription management improvements on the backend. However, at first, system administrators will probably be hesitant to adopt the new release. In order to run all the components of the Mailman 3.0 suite, they will have to be willing to install more dependencies (such as Django) and install and run two different versions of Python. Mailman 2.1 may seem serviceable enough; for core infrastructure like mailing list software, user interface improvements and better scriptability may not make this upgrade feel urgent.

The new features may change many open-source citizens' habits, such as subscribing and auto-archiving a list just to be able to search it easily, and using and linking to third-party sites like Nabble and gossamer-threads for convenience in discussing threads. And the web-native feel of HyperKitty (whose interaction design was led by Máirín Duffy and Karen Tang) may help Mailman compete with proprietary hosted list-style competitors, such as Google Groups, and with open-source forums that feel web-native, such as phpMyBB, Discourse, and Community.

Mailman's developers have gone with current trends in the Python community by using Django, but have made a bold move in converting the core engine to a Python 3 codebase. For many system administrators, Mailman 3.0 will be the first application that requires Python 3; in fact, Warsaw wrote some core Python code in order to support Mailman's use cases. It will be worth watching to see how this influences the overall adoption of Python 3, for which the rollout has been gradual.

The new release's REST API provides a more modular and flexible way for administrators and developers to reuse the Mailman core engine in other applications, replace Postorius or HyperKitty with custom web applications, or otherwise script and hook other actions into mailing list traffic. Mailman's API also goes further with its REST interface than many other web APIs, as it takes a particularly hypermedia-centric approach to resource representation and retrieval. It (unusually) even uses the HTTP verbs PUT and PATCH, which will exercise some of the less full-featured HTTP interaction libraries.

With its large suite of unit tests and a dedicated, active, and friendly community of creators and users, Mailman seems poised to continue improving, and to stay a premier competitor among open-source mailing list managers. Its new architecture and dependencies also point to continuing trends in server-side applications in general. For open-source communities already using Mailman 2.x, this is a welcome update, and its rollout will make open source as a whole a bit easier on the eyes.

[Thanks to Mailman developers Terri Oda, Barry Warsaw, Stephen J. Turnbull, Aurélien Bompard, and Florian Fuchs for fact-checking on this article.]

Comments (29 posted)

TextSecure and SMS transport

Like it or not, an ever-increasing percentage of the world's computing and communication takes place over mobile phone networks. But there has historically been a dearth of privacy- and security-protecting software targeting mobile devices—a fact that made it all the more alarming when the developers of the TextSecure messaging app for Android announced that they were dropping support for encrypting Short Message Service (SMS) text messages in the next release. The developers' argument is that supporting the SMS network is simply not worth the effort in comparison to messages delivered over generic data transports. Needless to say, not everyone agrees with that assessment.

For those unfamiliar with it, TextSecure is an open-source app developed by Open Whisper Systems (OWS), a non-commercial project that produces a number of free, security-driven mobile apps. Several of the team members (including Moxie Marlinspike and Lilia Kai) are well-known for their history with other privacy and security efforts.

Up through version 2.6 (which was released March 5), TextSecure let users exchange encrypted messages delivered over SMS, Multimedia Messaging Service (MMS), or its own "TextSecure transport layer" that used the phone's data connection. Starting with version 2.8.0 (which was released March 19), only the TextSecure transport layer is supported. The message format uses ephemeral Curve25519 keys, and the app performs the key exchange between clients over the same transport used for the message itself. In other words, when two TextSecure users communicate over SMS, the key-exchange step is done over SMS as well.

While that makes perfect sense from a design standpoint, it was evidently part of the burden of supporting SMS transport that OWS found increasingly difficult. In the announcement heralding the end of SMS support, OWS notes that the key exchange "can never be seamless" over SMS and that "we don’t believe that people should even need to know what a “key” is, so this added bit of friction has always felt wrong to us." In addition, users who uninstall TextSecure might continue to get encrypted SMS messages from their old contacts, which would then amount to useless, garbled text.

The announcement goes on to list three other reasons why SMS transport is being dropped. First, OWS has finally released a TextSecure-compatible app for iOS, and iOS does not include an API that could be used to encrypt or decrypt SMS traffic—making data-channel message exchange the only possibility for iOS–Android conversations.

Second, it says, SMS itself is fundamentally insecure. The messages "leak all possible metadata 100% of the time to thousands of cellular carriers worldwide." Although users like to think of text-messaging as an "offline" option, the announcement adds, in reality the messages are all routed through carriers' servers, where metadata is logged and, perhaps, even monitored by government entities (something that the US National Security Agency is reported to do). Ultimately, the announcement said, the effort required to support SMS was holding back other, more important work on the project.

The third point made in the announcement is that SMS is not as widely used as many smartphone users seem to believe. Unlimited messaging plans are really only available in the US and Europe, it said, and SMS can be quite expensive for much of the rest of the world.

Y U NO ENCRYPT?

Public reaction to the announcement varied (the Reddit discussion thread, for example, covers most of the comment responses). While some agreed that the limitations of SMS and its exposure to carrier data-logging make it a poor choice for the truly security-conscious, the fact remains that there are few—if any—alternative apps that offer any sort of privacy for SMS users.

The loss of the only reliable SMS-encryption mechanism is significant because it effectively leaves an entire transport unprotected. Although it has its shortcomings, SMS is often available in more areas than data services, it works across carrier boundaries, and could be used on a phone whose International Mobile Station Equipment Identity (IMEI) number is not previously associated with (for example) a Google account.

There are several other options available for encrypted smartphone chat over data networks (ChatSecure and SilentText, for example), but having no option for SMS messaging could leave some users out in the cold. After all, there are usually ways to minimize the metadata-collection issue, such as using store-bought phones and prepaid account-refill cards. Using more elaborate measures, one can gain quite a bit of anonymity.

But that is a solution that puts significant burdens onto the user; one of TextSecure's strengths has always been its ease of use. Users who still have version 2.6.0 can simply refuse to update to a more recent version, although there is a risk that future releases will break compatibility. In that case, users that want to communicate to some contacts over SMS and to others that use an updated TextSecure will find themselves in a bind.

Luckily, fans of the SMS-transport option have created a fork of the TextSecure 2.6 code, named SMSSecure. Even better, SMSSecure has been added to the submission queue at the F-Droid free-software repository for Android. TextSecure was removed from the F-Droid repository in 2012 for a number of reasons. Among those reasons were that OWS reportedly asked F-Droid not to distribute its own builds (i.e., packages signed by F-Droid and not OWS), and the fact that TextSecure used some proprietary libraries—namely Google's "Google Play Services."

On that last point, OWS's announcement about dropping SMS also noted that it would be dropping Google Play Services—at least for data transport. The Google library will still be used to relay wakeup events, the announcement said.

Among security professionals, a recurring refrain is that cell phones represent a far larger (and more important) attack surface than desktop machines and, thus, should be the focus of privacy- and security-development initiatives. Nevertheless, there are still precious few free-software apps for mobile devices that offer solid security and privacy features. Time will tell if SMSSecure will fill the gap opened by TextSecure's abandonment of text messaging, but it is reassuring to see that the community cares about such matters.

Comments (21 posted)