A Wayland full-screen shell

There are a number of features that users are used to in X that are not simple to handle in Wayland, such as screen sharing and recording. Jason Ekstrand gave a talk at the 2014 X.Org Developers Conference on some ideas he has to make those easier. Instead of teaching each and every Wayland compositor to handle various protocols for screen sharing and other features, he proposed using compositor nesting to hand the problem off to a dedicated process.

Ekstrand introduced himself as a PhD student in mathematics at Iowa State University. He got involved in the Wayland project in early 2013. Since June, he has also been working for Intel on the i965 graphics driver.

The Wayland model is quite different from that of X, he said. Instead of an X server, Wayland has compositors that serve many of the same functions. Clients talk to a Wayland compositor, which in turn talks to the hardware.

The X server handled a lot of different functions that now fall to Wayland compositors to implement. The solution to that has been libraries and subsystems to deal with different portions of the compositor's job: KMS for mode setting, DRM for buffer handling, OpenGL for accelerated graphics, libinput for input handling, and so on. Some of these are starting to be incorporated into the X server, which is nice, he said, because it means that Wayland compositors and X servers can share code.

So, he asked, why not just use X? It is a fine display server, so long as you are willing to let it handle input and compositing. Most modern desktops (e.g. GNOME and KDE) want to handle input and compositing themselves, so the X model doesn't work so well.

In addition, X has a common global namespace for everything. Any client can resize and reposition any window, get the contents of any window, and send input to any window. Window managers are just X clients that manage other clients' windows.

In Wayland, things are different. Every client has its own namespace and gets input directly from the compositor. In general, clients are not aware of the existence of other clients, and the contents of surfaces are only shared between a client and the compositor. All of that has many security benefits, Ekstrand said.

But there are features X provides that Wayland doesn't, including a common, user-space I/O layer. All that needs to be done is to implement a device-dependent X (DDX) driver for the X.Org server (or implement a full X server) and clients will just run on it. On the other hand, DRM, KMS, and OpenGL, which are used by Wayland, are focused on getting images to hardware—but some output mechanisms are not hardware (e.g. screen sharing or remote sessions).

Virtual network computing (VNC) and remote desktop protocol (RDP) sessions are often implemented using an X.Org DDX. That server runs in user space and does not require root privileges. Clients and window managers talk to that server like any other X server; there is no graphics acceleration, but otherwise it all works the same. FreeRDP and x11vnc have taken this approach, for example.

But doing that poses some problems for Wayland. Its I/O abstractions assume hardware. KMS and DRM require a kernel driver, for example. There are external libraries to implement protocols like VNC/RDP, but they require every compositor to add support for each library, which leads to a combinatorial explosion of compositors and protocols. Weston currently has an RDP backend that works pretty well, Ekstrand said, but it doesn't make sense to add a backend for every protocol.

Another use case that is problematic for Wayland is screen recording and sharing. On X, these are implemented as clients that grab the frame buffer and store it or send it. Input is faked as needed. That raises "huge security concerns", he said. Sensitive information can be grabbed, other clients can be controlled, and malicious input can be sent to clients.

In Wayland, though, clients are isolated, so any screen capturing must be done by the compositor. The output could be passed to a trusted client or handled by the compositor itself. There is some support for that in Weston already, via the weston-screenshooter client that will write to a PNG file. There is also the ability to record the screen, outputting H.264. All of that is both Weston and format specific, so if you wanted to support those features for GNOME or KDE, they would need to be implemented in their compositors.

Some have suggested writing a "trusted" protocol that is only accessible to trusted clients. It would be able to capture the screen and provide input to other clients. That would mean that compositors only need to implement that one protocol, and that multiple different sharing/recording clients can be written to use it, but it turns out that is a lot of protocol, Ekstrand said.

So his suggestion is to use what we have already: the Wayland protocol. In this model, a VNC or RDP server would implement a Wayland compositor. It would be launched as a trusted compositor by the main compositor. The main compositor would send its screen contents to the trusted compositor as a surface, which would then get sent across the network. Likewise, input would come from the network to the trusted compositor which would pass it to the main compositor. That leaves the main compositor in control of who gets screen contents and input. And, for the most part, that protocol is already written.

Ekstrand has proposed the wl_fullscreen_shell as the way forward to solve these problems (he also described the motivations and ideas for it in an earlier message). It would add two requests: present_surface, which would provide the trusted compositor with a surface (and possible scaling mode) to output, and present_surface_for_mode, which is similar, but would allow the main compositor to do some rudimentary mode setting for the output. Once that surface is established, the standard Wayland protocol is used to do input and output.

Originally, he wanted to demonstrate the full-screen shell, but he ran into some technical problems on the laptop he was using. Instead he described what he has working: a modified Weston compositor that, when ctrl-alt-s is pressed, will spawn a second Weston compositor with an RDP backend as a trusted compositor. One can then connect to that RDP server from the network to view the screen and send input to it. The "demo" is also a good example of the multi-seat capabilities of Wayland, since there are separate cursors and input devices (e.g., mouse and keyboard) for the main system and those connected over RDP.

Screen recording and sharing are "just the beginning", he said. For one thing, the ideas behind the full-screen shell will make it easier to write compositors. Those who want a simple compositor can write it as a Wayland client and let Weston handle the input and output. It could also be used as the basis of a user-space Miracast (for wireless screen-casting).

There is some discussion of Ekstrand's patches going on in the wayland-devel mailing list, but there don't seem to be any major objections. Those looking for more information can check out the slides [PDF] and video [WebM] from the talk.

[ I would like to thank the X.Org Foundation for travel assistance to Bordeaux for XDC. ]

Comments (8 posted)

A look at Emacs 24.4

Emacs 24.4 is the newest release of the venerable editor, released on October 20. Despite being a point release and not a major version-number bump, there are quite a few significant changes rolled into the update. Among them are user-interface improvements, security features, several enhancements to various editing modes, and the addition of a new built-in web browser. Even if the thought of browsing the web from entirely within Emacs does not sound revolutionary, there appears to be something new for just about every Emacs user.

Editing

For general text-editing purposes, arguably the most significant change in the new release is the default activation of "electric" indentation. This is an auto-indentation mode that indents or re-indents lines whenever certain trigger characters are types—namely, Enter, Return, and closing parentheses. It was first added in Emacs 24.1; the new release simply makes it the default behavior. This is a somewhat controversial change, mainly because some third-party language modes (such as YAML and Ruby modes) require some additional tweaks to produce proper results.

Another wide-ranging (albeit small) change is the addition of superword-mode, which alters how Emacs treats certain characters within words. In previous releases, Emacs would treat hyphens, underscores, and similar characters as word breaks, which is not how they should be treated when editing code. superword-mode corrects this, so that word-by-word navigation and commands function correctly. Also in the code-editing vein is an improved show-paren-mode, the function responsible for highlighting paired delimiters. In previous releases, only simple matches like [ to ] and ( to ) were supported. The new update also matches programming language control constructs like do to end.

Users that work with bidirectional text documents (that is, mixing left-to-right with right-to-left text in one file) may also appreciate the new visual-order-cursor-movement setting. When set to a non-nil value, this option makes the cursor always move in the "arrow" direction when navigating with the keyboard, regardless of which direction the text is oriented. So hitting the left arrow moves the cursor to the left, whether Latin, Arabic, Hebrew, or other text happens to be beneath it. There is also a new rectangle-mark-mode, with which the user can highlight a rectangular block of text (to cut or copy), rather than making only line-oriented selections. Users should be forewarned, however, that while basic kill/yank functionality supports rectangle selection, various other commands may not understand it yet.

Interfaces

Quite a few improvements in 24.4 affect the various Emacs user interfaces, rather than editing itself. For example, while the GUI interface has supported menus for many years, 24.4 is the first to add menu support to the text-mode interface as well. When using Emacs in a terminal, all of the same menus are now available; on mouse-less systems one can open the first menu by hitting F10.

GUI users also gain several enhancements, including support for multiple monitors (in particular, the ability to query the sizes and properties of multiple monitors, which is likely to affect extension developers most immediately), improved full-screen support, and support for saving and restoring window and frame layout between sessions. "Frames," in Emacs lingo, are what most operating systems call windows, it should be noted, but whatever one calls them, Emacs can now save and restore their configuration. Full-screen support can be activated with F11, and a frame can be maximized with Meta-F10 (or, in traditional Emacs parlance, M-F10). Although X-based systems have behaved correctly for quite some time, the new release also fixes several outstanding bugs related to pixel-based window sizing and resizing; users can now rest assured that their frames and windows will be the proper dimensions on any OS.

A new prettify-symbols-mode has been added that will substitute a text representation of a character name with the proper Unicode character. Being a Lisp-centric project, of course, Emacs's canonical example of this is replacing the string lambda with the Greek letter λ, but there are certainly other possibilities. Another potentially controversial change is that cursors will now stop blinking after 10 blinks if there is no activity. As Mickey Petersen quipped in his blog post about the 24.4 release, "I wonder how many surveys, usability studies, committee meetings and research went into deciding it must be ten blinks and not nine or eleven." The number is, however, configurable with the blink-cursor-blinks variable.

Finally, there is also a new remember-notes command in this release. It creates a buffer akin to the "scratch" buffer (an Emacs mainstay), but which is saved when exiting the editor. Since many people, rightly or wrongly, use "scratch" to save notes and snippets of text, apparently the development team determined that a significant number of them were frustrated by the fact that "scratch" is destroyed on exit.

Security

A handful of security-related improvements were also added in this release. Emacs now supports checking digital signatures on Emacs Lisp packages. This ties in to another recent feature: the built-in package manager, which connects to the official Emacs Lisp Package Archive (ELPA) run by the GNU project. While ELPA and the other large package archive sites may not add signatures for many packages in any kind of short time frame, it is certainly a welcome feature for anyone who occasionally installs a third-party package from a somewhat less-familiar source.

Emacs can also be compiled with support for access control lists (ACLs), both on local and remote files. This feature requires operating-system support; on Linux this means the presence of libacl. Finally, there is a new option available to require SSL/TLS certificate verification; if GnuTLS determines that a certificate is invalid, the gnutls-verify-error setting will cause Emacs to reject the SSL/TLS certificate and stop the connection. It is important to note, though, that gnutls-verify-error is currently set to nil by default—but that default will likely change in some future release.

...And the rest

With a project as large and as modular as Emacs, there are clearly too many changes to describe adequately in anything close to readable brevity. But among the many other updates found in 24.4, perhaps the most oft-discussed is the new web browser module, Emacs Web Wowser or eww.

There have been several other browser modules in the past, but the previous one (W3) had fallen out of active development. Eww is implemented almost entirely in Emacs Lisp (though it requires the presence of libxml2), and supports HTML5 and CSS. The documentation is lacking, so it is not clear what portions of HTML and CSS are supported at present (and JavaScript appears to be off the table entirely), but it will certainly be a project worth watching.

Among the other Emacs modes and packages, some additional noteworthy developments include support for file notifications and improvements to image-mode. On Linux, the file-notification support requires Emacs to be compiled with inotify.c; it lets Emacs report changes to files: deletions, renames, and modifications. image-mode gains new commands for stepping through the files in a directory, stepping through individual frames of an animated image, and new magnification features like fit-to-frame.

The Emacs 24.4 release is available as in source-code bundles from GNU mirrors, but packages for a variety of Linux distributions have already started to appear.

Comments (28 posted)

The Google Summer of Code Reunion

Google Summer of Code (GSoC) 2014 is over and the 2015 edition has been announced. A record number of 1307 students from 73 countries participated in 2014, working on 190 open-source projects. One of the traditions of Google Summer of Code is to host a Mentor Summit in the fall, which is an unconference that two mentors from each organization participating in GSoC can attend.

In celebration of the 10th year of Google Summer of Code, Google held a GSoC Reunion. Breaking tradition with the Mentor Summit, the GSoC Reunion was open not just to mentors, but also to students. Google allowed each of the 190 projects that participated in this year's GSoC to send two delegates. Additionally, Google held a lottery for additional places, bringing the total attendance to around 500. I was fortunate to attend as one of the representatives of Software Freedom Conservancy, which handles GSoC payments for multiple projects and also worked with a GSoC student of its own in 2014. We will look at some highlights from the dinner reception and cover two of the unconference sessions.

Musings on the history of GSoC and some surprise speakers

Friday started with a visit to California's Great America, which is an amusement park with roller coasters and other attractions. The park was only open to GSoC Reunion attendees, which meant that people got to enjoy the rides without any queues. In the evening, Google hosted a dinner reception at The Tech Museum of Innovation in San Jose. The dinner reception provided an interesting exhibition, food, and some surprise speakers.

The first speaker was hardly a surprise. Chris DiBona, director of open source at Google, talked about the history and significance of Google Summer of Code. He recounted a meeting with Google co-founder Larry Page, who lamented that computer science students spend the academic year learning about computers but often regress with their learning during the summer holidays because they cannot focus on coding. Page gave DiBona a simple mission: fix this problem.

DiBona thought it would be a great idea to get students to work on open source over the summer and asked several projects if they would be able to do anything with some students. The response was generally positive, as long as projects were not forced to integrate the code from a student if it didn't meet the project's criteria for inclusion, and this this is how Google Summer of Code was born. Thanking everyone for their work and contributions, DiBona stated that "we're all here for a reason"—people were not selected by chance, but because of the work they have done.

After two more speakers from Google, two GSoC mentors were introduced. They turned out to be Linus Torvalds and Dirk Hohndel. While Torvalds may be known for popular projects like Git and the Linux kernel, they were invited to the GSoC Reunion as mentors representing Subsurface, a piece of software for planning and logging dives. Torvalds was quick to point out that he was, in fact, not a GSoC mentor because he would only scare students away, but Hohndel confirmed his own role as mentor and organization administrator for Subsurface.

In a Q&A-style session, Torvalds was asked to give his insights on what it takes to become a good programmer. One of the key characteristics, according to Torvalds, is perseverance. Debugging is a good example because you have to drill down until you get to the bottom of the problem and understand what's going on.

Another key requirement is taste. Torvalds said that he couldn't describe what he means by taste, but that it's something he knows when he sees it. Taste allows you to make the right decisions. The good taste shown by certain developers enables Torvalds to trust them completely because he knows that they will do the right thing. It allowed him to hand the maintainership of Git over to Junio Hamano and to accept pull requests from certain Linux developers without looking at the code.

Torvalds argued that experience makes you faster, but is often overrated. He can frequently judge patches in seconds these days because of experience, but experience doesn't replace taste. Unfortunately, Torvalds didn't know how people can develop taste.

Hohndel also chimed in with his insights, recommending that students "think small". Instead of planning to design a completely new system, they should focus on their immediate needs—fixing bugs in software they use is usually how people get started.

Paid and unpaid contributors

The first unconference session I attended was on paid and unpaid FLOSS contributors. This session was suggested by Thorsten Behrens, chairman of the board of The Document Foundation. He observed that LibreOffice has a lot of volunteers as well as a lot of paid developers, and that the Document Foundation recently published a tender for paid development work.

While many developers are paid to work on open-source software these days, paying people as well as mixing volunteers and paid developers in a project can be delicate issues. There was a general feeling in the session that projects comprising both paid and unpaid contributors treat all contributors equally. The only exception are projects sponsored by a single company in which priority is often given to developers from that company, for example when it comes to reviewing patches.

Robert Kaye from the MusicBrainz project explained that its development process is driven by the community through a bug tracker. While companies cannot tell the project what to do, they can participate in the development process—just like anyone else. The MetaBrainz Foundation (which sponsors MusicBrainz) has a steady flow of income from companies such as Google and Last.fm that use MusicBrainz data; it uses that money to employ people. A key here is transparency, something that was echoed by others in the room. Perl, for example, has a grant process that allows developers to apply for funding. What works well is that the process of applying for grants is well described and open to anyone.

Someone in the audience suggested that paying people who have been long-term volunteers works well. However, when money goes to newcomers, it can lead to distortions because these people may come in with a different motivation compared to people who started out as unpaid volunteers. Someone noted that only paying people who have a history of unpaid contributions makes it hard for certain groups to get started. She acknowledged that many people start doing open source as their second shift (meaning work done at home in their spare time), but creating more opportunities to work on open source on the first shift (i.e. as paid work) can have a positive impact on diversity.

When a project wants to pay developers, the big questions are how much and what for. The salary question can be complex since many projects are global. If you have a fixed budget of $60K, this salary figure means something completely different to someone living in San Francisco than it does to someone in a low-cost location. In answer to the question of what to pay for, someone from FreeBSD suggested that paying for activities that are extremely complex and hard to perform in someone's spare time works well, such as legacy build systems and kernel video drivers. These tasks are "almost impossible if people don't get paid". Similarly, paying people for tasks considered boring, such as code review or documentation, has worked well.

There are some issues with paying people, though. One is that other people often avoid a particular area when they see that someone is getting paid to work on it, even though the activity could benefit from more contributors. There's also the phenomenon of "cookie licking"—marking a particular area as yours and getting offended when other people want to work on it.

There was a general agreement in the room that paying students through GSoC works well, although some noted that there can be resentment when the work of a student who gets paid to work on a project doesn't meet the project's quality standard—why is the student paid for something an existing volunteer could have done better? However, this is generally not a big deal since it's not the organization's money that is being spent on the student.

As open source is getting increasingly popular, the majority of projects will consist of both unpaid and paid contributors. Projects have to ensure that all participants can co-exist without resentment, particularly if the project itself starts paying certain developers. Projects are increasingly gaining experience with questions related to paying developers and we can all benefit from sharing those experiences.

Making your project more approachable to new contributors

Another session I attended was on making projects more approachable to new contributors. This session was led by Angela Byron, a former GSoC student, and Chandan Singh, a GSoC 2014 student working on Drupal. Together, they presented several blockers that contributors often face. Byron explained that she installed Debian many years ago, but that she never considered contributing to the project at that time because she thought that she wasn't skilled enough.

When GSoC was launched, Byron applied as a student, thinking that you're not expected to already know how everything works as a student. This worked out really well and Byron is now a Drupal core committer. Another assumption that stops potential contributions is that you have to be a developer in order to contribute. There are many other ways to make significant contributions and projects should offer tasks that require diverse skill sets.

Singh observed that newcomers are often overwhelmed by the scale of a project and don't know where to start. When you find a problem, it's hard to know where to begin if you want to fix the problem. A representative from Eclipse in the audience noted that people often don't even know that they can contribute.

A good way to make things easier for new contributors is to post clear signs on how to get started. A LibreOffice developer mentioned LibreOffice Easy Hacks, which highlights bugs and tasks that are easy to tackle, as a good initiative that made it easier to get started. Other projects have similar initiatives, such as Drupal's Novice tags; a student in the audience confirmed that highlighting easy tasks "really helps".

There was general agreement that it's important to make it as easy as possible to get started. Someone suggested providing a complete environment, such as a VM image, that includes the tools required to hack on a project. Byron mentioned the Drupal Ladder, which breaks down the tasks required to get started into simple steps, such as installing Git, getting familiar with the issue tracker, and eventually submitting patches. Each step is accompanied by a tutorial, which makes it easy to take the step and advance on the ladder. It's important to think about the steps required to become proficient at something; in the process you should try to eliminate as many steps as possible. After all, "nobody wants a 27-step ladder", Byron said.

Good mentoring can make a real difference to newcomers. Drupal has taken mentoring to its heart, according to Byron. The project offers core mentoring hour—twice a week, mentors are available on IRC to help new contributors get started. Mentors curate lists of issues that newcomers can work on and guide them through the steps required. A representative from Ceph noted that they host quarterly online developer meetings through video chat, which allow new contributors to interact with developers. He observed that the "human element is huge".

Overall, many good ideas were discussed in this session and there was an understanding that projects can drive many activities to make it easier to get started.

Conclusions

I found the GSoC Reunion to be quite a stimulating event. What's unique about the event is the diverse nature of attendees. I cannot think of another event that brings contributors from so many different projects together. Open-source communities are different, but at the end of the day we often face similar issues. We can all benefit from sharing experiences—positive as well as negative—with each other and the Google Summer of Code gathering is an excellent venue for this.

Comments (none posted)

Darkcoin: A cryptocurrency with more anonymity

Since the release of Bitcoin in 2009, open-source cryptocurrencies have had a substantial economic impact on the world. The most popular ones have millions and, sometimes, billions of dollars worth of currency in circulation. While cryptocurrencies provide a digital form of cash transactions, they have also raised the ire of those who argue that they sustain online black markets. A new currency, Darkcoin, which had an open-source release in September, has a distinction from its competitors in its focus on making transactions untraceable.

The project was announced in January 2014, but was only released as open source in September, when project members deemed the technology ready for mainstream use. Based on Bitcoin, Darkcoin seeks to improve upon that foundation, particularly with regard to anonymity. As the project notes: "With Bitcoin, transactions are published to the blockchain and you can prove [who] made them, but with Darkcoin the anonymization technology makes it impossible to trace them."

For those unfamiliar with how Bitcoin transactions operate, here's a quick primer. When trying to create a new digital cash system from scratch, the same problem that the music and movie industry have faced crops up: how to stop computers from copying valuable bits? Bitcoin solves this problem by incorporating a public ledger in its code. Everyone who wants to use Bitcoin has to download a copy of the complete database of all the Bitcoin transactions ever made, and keep it up-to-date. This database is known as the blockchain.

To give a financial incentive for individuals to provide the computing infrastructure necessary to keep the database and Bitcoin network working, and to provide a controlled means to increase the number of Bitcoins in circulation to deal with inflation, the ability to "mine" Bitcoins is built into the software. Those who provide nodes to help sustain the Bitcoin network also devote resources to brute force instances of an automatically-generated cryptography problem. This problem is a cryptographic classic: the Byzantine Generals' Problem. The first miner to solve an instance of this problem is awarded some free Bitcoins from a combination of automatic transaction fees from across the Bitcoin network, along with a set number of Bitcoins (presently, twenty-five, though that will diminish, eventually to zero, over time). The code is designed to adapt the difficulty of the cryptographical problem to the computational power of the network so that, on average, the problem will be solved every ten minutes.

The blockchain leads to a privacy problem: while a paper cash transaction is not easily traceable, every Bitcoin transaction is publicly recorded. To mitigate this problem, transactions are recorded using pseudonyms (Bitcoin addresses); users can generate as many different addresses as they want. For some, this approach is insufficient; tracing the transaction history in the blockchain or other techniques may be able to deanonymize Bitcoin owners.

Darkcoin's claimed innovation to address this issue is its mixing software named DarkSend, which uses decentralized "masternodes" in a fashion somewhat similar to onion routing: "Obfuscation is achieved by using network nodes in order to break up and reroute the flow of money in a way that is hard to track down". Masternodes are given a financial incentive to operate, but must hold an initial minimum amount of Darkcoin to participate, to try to deter surveillance:

DarkSend also pools Darkcoin before completing transactions, to make it much less clear where payments originated from. Basically, instead of paying someone directly, one pays into a pool, managed by the masternodes. When that pool grows large enough, the pool then pays the recipients, making it difficult to trace the source of the payments. As stated in the Darkcoin FAQ, masternodes never actually hold the Darkcoin from the pool, so they cannot steal any. Payments from pools are all equal sums to further obfuscate the source. That is, buying something for ten Darkcoin could contribute to a pool that, when it reached 1000 Darkcoin, would complete 100 different transactions each for ten Darkcoin. In the project's words:

Security researcher Kristov Atlas's detailed analysis [PDF] of DarkSend offers an analogy to help explain it: "Imagine you're flying in a helicopter trying to track a red car on the highway, and it passes under a bridge. If two red cars emerge on the other side of the bridge, it's ambiguous which one you want to follow" (page 4). Atlas's article is worth the read for anyone interested in cryptocurrency security. He breaks down which types of entities take part in DarkSend, what role they play, and how that role may or may not compromise transactional anonymity. For example, masternodes, which play a critical role in mixing Darkcoin before completing transactions, are also a potential avenue for compromising user privacy: "Malicious Masternodes can record the input and output relationships for any transaction they are chosen to orchestrate" (page 10).

The actively developed code is available under the X11 license at Darkcoin's GitHub repository. Discussion happens on the project's official forums and on a dedicated subreddit. The project leads are ambitious and appear to have a semi-academic approach with frequent releases of white papers. A recent paper [PDF] describes "transaction locking": a proposed means "to enable instant validation of payments without having to wait for blockchain confirmation". This would make Darkcoin transactions competitive with credit cards for speed of validation; another improvement over Bitcoin. A message from the project's official Twitter account states that this technology will be coming soon to Darkcoin.

No matter how well-done, a cryptocurrency is merely of academic value if no vendors will accept it as payment. With many merchants offering goods and services in exchange for Darkcoin, this appears not to be an issue for the currency. A Canadian vineyard got the ball rolling this past May, when it announced that it will "be the first retail business to accept DarkCoin". The official Darkcoin forums have a section where vendors can advertise that they accept Darkcoin. The list is diverse: there's a law office in Brazil, a VPN service based in Belize, a VHS-to-digital conversion service in Texas, and many more. A merchant directory lists several other vendors, including an auction site, a computer hardware vendor, a board game company, and a house planner.

With Darkcoin's focus on online privacy, certain questionable or illegal activities have capitalized on the new currency. Gambling, drugs, and guns all appear to be available to those who hold Darkcoin. All of these black markets are hidden services on Tor to avoid law enforcement actions. Nonetheless, there are plenty of legitimate uses for Darkcoin. With a focus on privacy, ambition from its developers to break new technical ground, and strong interest from vendors, Darkcoin will likely continue to make an impact in cryptocurrency technology innovation.

Comments (5 posted)

Security quotes of the week

— Bruce Schneier in an article about Spritz [PDF], which is a redesigned RC4

— Steve Friess on a report [PDF] about emergency e-voting in New Jersey after Hurricane Sandy

— Robert McMillan

— Patrick Howell O'Neill

Comments (12 posted)

Garrett: Linux Container Security

Matthew Garrett considers the security of Linux containers on his blog. While the attack surface of containers is likely to always be larger than that of hypervisors, that difference may not matter in practice, but it's going to take some work to get there:

Comments (62 posted)

A "highly critical public service announcement" from Drupal

The Drupal project has put out an advisory that if you haven't already patched the recent SQL injection vulnerability, it's probably too late. "Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement of SA-CORE-2014-005 - Drupal core - SQL injection. You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement."

Comments (26 posted)

devscripts: directory traversal

Package(s):	devscripts	CVE #(s):	CVE-2014-1833
Created:	October 28, 2014	Updated:	June 17, 2015
Description:	From the CVE entry: Directory traversal vulnerability in update in devscripts 2.14.1 allows remote attackers to modify arbitrary files via a crafted .orig.tar file, related to a symlink.
Alerts:	Ubuntu USN-2649-1 devscripts 2015-06-16 Fedora FEDORA-2014-13063 devscripts 2014-10-28

Comments (none posted)

ejabberd: incorrectly allows unencrypted connections

Package(s):	ejabberd	CVE #(s):	CVE-2014-8760
Created:	October 24, 2014	Updated:	March 30, 2015
Description:	From the Mageia advisory: A flaw was discovered in ejabberd that allows clients to connect with an unencrypted connection even if starttls_required is set.
Alerts:	Mandriva MDVSA-2015:175 ejabberd 2015-03-30 Mandriva MDVSA-2014:207 ejabberd 2014-10-24 Mageia MGASA-2014-0417 ejabberd 2014-10-23

Comments (none posted)

file: out-of-bounds read flaw

Package(s):	file	CVE #(s):	CVE-2014-3710
Created:	October 29, 2014	Updated:	November 28, 2014
Description:	From the Red Hat bugzilla: An out-of-bounds read flaw was found in file's donote() function in the way the file utility determined the note headers of a elf file. This could possibly lead to file executable crash.
Alerts:	Gentoo 201701-42 file 2017-01-17 Scientific Linux SLSA-2016:0760-1 file 2016-06-08 Oracle ELSA-2016-0760 file 2016-05-13 Red Hat RHSA-2016:0760-01 file 2016-05-10 Scientific Linux SLSA-2015:2155-7 file 2015-12-21 Oracle ELSA-2015-2155 file 2015-11-23 Red Hat RHSA-2015:2155-07 file 2015-11-19 Oracle ELSA-2015-1135 php 2015-06-23 Mandriva MDVSA-2015:080 php 2015-03-28 Gentoo 201503-03 php 2015-03-08 Ubuntu USN-2494-1 file 2015-02-04 Slackware SSA:2014-356-02 php 2014-12-22 Mandriva MDVSA-2014:236 file 2014-11-28 openSUSE openSUSE-SU-2014:1516-1 file 2014-11-27 Debian DSA-3074-2 php5 2014-11-19 Debian DSA-3074-1 php5 2014-11-18 Mageia MGASA-2014-0441 php 2014-11-12 Debian DSA-3072-1 file 2014-11-12 Scientific Linux SLSA-2014:1768-1 php53 2014-11-03 Scientific Linux SLSA-2014:1767-1 php 2014-11-03 CentOS CESA-2014:1768 php53 2014-10-31 CentOS CESA-2014:1767 php 2014-10-31 CentOS CESA-2014:1767 php 2014-10-31 Oracle ELSA-2014-1768 php53 2014-10-30 Oracle ELSA-2014-1767 php 2014-10-30 Oracle ELSA-2014-1767 php 2014-10-30 Mageia MGASA-2014-0439 file 2014-10-31 Red Hat RHSA-2014:1766-01 php55-php 2014-10-30 Red Hat RHSA-2014:1765-01 php54-php 2014-10-30 Red Hat RHSA-2014:1768-01 php53 2014-10-30 Red Hat RHSA-2014:1767-01 php 2014-10-30 Ubuntu USN-2391-1 php5 2014-10-30 Fedora FEDORA-2014-13571 file 2014-10-29

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2014-3688 CVE-2014-3687 CVE-2014-3673 CVE-2014-3690 CVE-2014-8086
Created:	October 28, 2014	Updated:	February 4, 2015
Description:	From the CVE entry: Race condition in the ext4_file_write_iter function in fs/ext4/file.c in the Linux kernel through 3.17 allows local users to cause a denial of service (file unavailability) via a combination of a write action and an F_SETFL fcntl operation for the O_DIRECT flag. (CVE-2014-8086) From the Red Hat bugzilla: It was found that Linux kernel's sctp stack is prone to remotely triggerable memory pressure issue caused by excessive queueing. A remote attacker could use this flaw to cause denial-of-service conditions on the system. (CVE-2014-3688) Kernel panic is encountered when sctp stack receives duplicate asconf chunks. (CVE-2014-3687) Kernel panic (via skb_over_panic) is encountered when sctp stack receive a malformed asconf chunks. (CVE-2014-3673) I was found that the host cr4 value can change across vm entries on the same vcpu and yet it was being treated as being constant. This can interfere with, for example, PR_SET_TSC settings (cr4/TSD bit), leading to inconsistent state. A local, unprivileged user could use this flaw to cause denial of service on the system. (CVE-2014-3690)
Alerts:	SUSE SUSE-SU-2015:1376-1 kernel-rt 2015-08-12 SUSE SUSE-SU-2015:1478-1 kernel 2015-09-02 SUSE SUSE-SU-2015:1489-1 kernel 2015-09-04 SUSE SUSE-SU-2015:0812-1 kernel 2015-04-30 Scientific Linux SLSA-2015:0864-1 kernel 2015-04-21 Oracle ELSA-2015-0864 kernel 2015-04-21 CentOS CESA-2015:0864 kernel 2015-04-22 SUSE SUSE-SU-2015:0736-1 Real Time Linux Kernel 2015-04-20 Red Hat RHSA-2015:0864-01 kernel 2015-04-21 Red Hat RHSA-2015:0782-01 kernel 2015-04-07 SUSE SUSE-SU-2015:0652-1 Linux kernel 2015-04-02 SUSE SUSE-SU-2015:1071-1 kernel 2015-06-16 Scientific Linux SLSA-2015:0290-1 kernel 2015-03-25 SUSE SUSE-SU-2015:0581-1 kernel 2015-03-24 openSUSE openSUSE-SU-2015:0566-1 kernel 2015-03-21 Oracle ELSA-2015-3012 kernel 2015-03-19 Oracle ELSA-2015-3012 kernel 2015-03-19 SUSE SUSE-SU-2015:0529-1 the Linux Kernel 2015-03-18 Red Hat RHSA-2015:0694-01 kernel-rt 2015-03-17 Mandriva MDVSA-2015:058 kernel 2015-03-13 SUSE SUSE-SU-2015:0481-1 kernel 2015-03-11 Red Hat RHSA-2015:0290-01 kernel 2015-03-05 Oracle ELSA-2015-0290 kernel 2015-03-12 Red Hat RHSA-2015:0115-01 kernel 2015-02-03 SUSE SUSE-SU-2015:0178-1 kernel 2015-01-30 Red Hat RHSA-2015:0062-01 kernel 2015-01-21 Mandriva MDVSA-2015:027 kernel 2015-01-16 SUSE SUSE-SU-2015:0068-1 the Linux Kernel 2015-01-16 SUSE SUSE-SU-2014:1695-2 Linux kernel 2015-01-14 Red Hat RHSA-2015:0043-01 kernel 2015-01-13 SUSE SUSE-SU-2014:1695-1 kernel 2014-12-23 SUSE SUSE-SU-2014:1693-1 kernel 2014-12-23 SUSE SUSE-SU-2014:1693-2 kernel 2014-12-24 openSUSE openSUSE-SU-2014:1677-1 kernel 2014-12-21 openSUSE openSUSE-SU-2014:1678-1 kernel 2014-12-21 Debian-LTS DLA-118-1 linux-2.6 2014-12-21 Ubuntu USN-2448-2 kernel 2014-12-19 Ubuntu USN-2447-2 kernel 2014-12-19 Scientific Linux SLSA-2014:1997-1 kernel 2014-12-17 Oracle ELSA-2014-1997 kernel 2014-12-16 CentOS CESA-2014:1997 kernel 2014-12-17 Red Hat RHSA-2014:1997-01 kernel 2014-12-16 Ubuntu USN-2447-1 linux-lts-utopic 2014-12-11 Ubuntu USN-2445-1 linux-lts-trusty 2014-12-11 Ubuntu USN-2448-1 kernel 2014-12-11 Ubuntu USN-2446-1 kernel 2014-12-11 Ubuntu USN-2441-1 kernel 2014-12-11 Ubuntu USN-2442-1 EC2 kernel 2014-12-11 Oracle ELSA-2014-3103 kernel 2014-12-11 Oracle ELSA-2014-3104 kernel 2014-12-11 Oracle ELSA-2014-3105 kernel 2014-12-11 Oracle ELSA-2014-3103 kernel 2014-12-11 Oracle ELSA-2014-3105 kernel 2014-12-11 Oracle ELSA-2014-3104 kernel 2014-12-11 Scientific Linux SLSA-2014:1971-1 kernel 2014-12-10 Oracle ELSA-2014-1971 kernel 2014-12-09 CentOS CESA-2014:1971 kernel 2014-12-10 Red Hat RHSA-2014:1971-01 kernel 2014-12-09 Oracle ELSA-2014-3096 kernel 2014-12-04 Oracle ELSA-2014-3096 kernel 2014-12-04 Mandriva MDVSA-2014:230 kernel 2014-11-27 Ubuntu USN-2418-1 linux-ti-omap4 2014-11-24 Ubuntu USN-2419-1 linux-lts-trusty 2014-11-24 Ubuntu USN-2421-1 kernel 2014-11-24 Ubuntu USN-2420-1 kernel 2014-11-24 Ubuntu USN-2417-1 kernel 2014-11-24 Fedora FEDORA-2014-14068 kernel 2014-11-16 Oracle ELSA-2014-3087 kernel 2014-11-13 Oracle ELSA-2014-3087 kernel 2014-11-13 Oracle ELSA-2014-3088 kernel 2014-11-13 Oracle ELSA-2014-3088 kernel 2014-11-13 Debian DSA-3060-1 kernel 2014-10-31 Fedora FEDORA-2014-13558 kernel 2014-10-28

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2014-3610 CVE-2014-3611 CVE-2014-3646 CVE-2014-8369
Created:	October 28, 2014	Updated:	April 23, 2015
Description:	From the Red Hat bugzilla: If the guest writes a noncanonical value to certain MSR registers, KVM will write that value to the MSR in the host context and a #GP will be raised leading to kernel panic. A privileged guest user can use this flaw to crash the host. (CVE-2014-3610) There's a race condition in the PIT emulation code in KVM. In __kvm_migrate_pit_timer the pit_timer object is accessed without synchronization. A local guest user with access to the PIT i/o ports could use this flaw to crash the host. (CVE-2014-3611) On systems with invvpid instruction support (corresponding bit in IA32_VMX_EPT_VPID_CAP MSR is set) guest invocation of invvpid causes vm exit, which is currently not handled and causes unknown exit error to be propagated to userspace. A local unprivileged guest user could use this flaw to crash the guest. (CVE-2014-3646) A flaw was found in the way iommu mapping failures were handled in kvm_iommu_map_pages() function in the Linux kernel (introduced by the fix for CVE-2014-3601). A privileged user in the guest could use this flaw to crash the host in case the guest has access to passed in device. (CVE-2014-8369)
Alerts:	Oracle ELSA-2015-2152 kernel 2015-11-25 Oracle ELSA-2015-0869 kvm 2015-04-22 Scientific Linux SLSA-2015:0869-1 kvm 2015-04-22 CentOS CESA-2015:0869 kvm 2015-04-22 Red Hat RHSA-2015:0869-01 kvm 2015-04-22 SUSE SUSE-SU-2015:0736-1 Real Time Linux Kernel 2015-04-20 SUSE SUSE-SU-2015:0581-1 kernel 2015-03-24 openSUSE openSUSE-SU-2015:0566-1 kernel 2015-03-21 Oracle ELSA-2015-3012 kernel 2015-03-19 Oracle ELSA-2015-3012 kernel 2015-03-19 SUSE SUSE-SU-2015:0481-1 kernel 2015-03-11 Red Hat RHSA-2015:0674-01 kernel 2015-03-11 Oracle ELSA-2015-0674 kernel 2015-03-11 Mageia MGASA-2015-0078 kernel-vserver 2015-02-19 Mageia MGASA-2015-0076 kernel-tmb 2015-02-19 Mageia MGASA-2015-0077 kernel-rt 2015-02-19 Mageia MGASA-2015-0075 kernel-linus 2015-02-19 Oracle ELSA-2015-0290 kernel 2015-03-12 Red Hat RHSA-2015:0284-01 kernel 2015-03-03 Ubuntu USN-2491-1 EC2 kernel 2015-02-03 SUSE SUSE-SU-2015:0068-1 the Linux Kernel 2015-01-16 SUSE SUSE-SU-2014:1695-2 Linux kernel 2015-01-14 Ubuntu USN-2464-1 linux-ti-omap4 2015-01-13 Ubuntu USN-2462-1 kernel 2015-01-13 Ubuntu USN-2463-1 kernel 2015-01-13 CentOS CESA-2015:0674 kernel 2015-03-12 Scientific Linux SLSA-2015:0674-1 kernel 2015-03-12 SUSE SUSE-SU-2014:1695-1 kernel 2014-12-23 SUSE SUSE-SU-2014:1693-1 kernel 2014-12-23 SUSE SUSE-SU-2014:1693-2 kernel 2014-12-24 Ubuntu USN-2448-2 kernel 2014-12-19 Ubuntu USN-2447-2 kernel 2014-12-19 Oracle ELSA-2014-1997 kernel 2014-12-16 Ubuntu USN-2447-1 linux-lts-utopic 2014-12-11 Ubuntu USN-2445-1 linux-lts-trusty 2014-12-11 Ubuntu USN-2448-1 kernel 2014-12-11 Ubuntu USN-2446-1 kernel 2014-12-11 Oracle ELSA-2014-1971 kernel 2014-12-09 Debian DSA-3093-1 kernel 2014-12-08 Oracle ELSA-2014-3096 kernel 2014-12-04 Oracle ELSA-2014-3096 kernel 2014-12-04 Mandriva MDVSA-2014:230 kernel 2014-11-27 Ubuntu USN-2418-1 linux-ti-omap4 2014-11-24 Ubuntu USN-2417-1 kernel 2014-11-24 Mageia MGASA-2014-0474 kernel 2014-11-21 Mageia MGASA-2014-0475 kernel 2014-11-21 Fedora FEDORA-2014-14068 kernel 2014-11-16 Scientific Linux SLSA-2014:1843-1 kernel 2014-11-12 Oracle ELSA-2014-1843 kernel 2014-11-11 CentOS CESA-2014:1843 kernel 2014-11-11 Red Hat RHSA-2014:1843-01 kernel 2014-11-11 Scientific Linux SLSA-2014:1724-1 kernel 2014-11-03 Ubuntu USN-2396-1 kernel 2014-10-31 Ubuntu USN-2394-1 linux-lts-trusty 2014-10-30 Ubuntu USN-2395-1 kernel 2014-10-30 Debian DSA-3060-1 kernel 2014-10-31 Oracle ELSA-2014-3084 kernel 2014-10-30 Oracle ELSA-2014-3085 kernel 2014-10-30 Oracle ELSA-2014-3085 kernel 2014-10-30 Oracle ELSA-2014-3084 kernel 2014-10-30 Oracle ELSA-2014-1724 kernel 2014-10-28 CentOS CESA-2014:1724 kernel 2014-10-29 Red Hat RHSA-2014:1724-01 kernel 2014-10-28 Fedora FEDORA-2014-13773 kernel 2014-10-28

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2014-3645
Created:	October 29, 2014	Updated:	October 29, 2014
Description:	From the Red Hat advisory: It was found that the Linux kernel's KVM subsystem did not handle the VM exits gracefully for the invept (Invalidate Translations Derived from EPT) and invvpid (Invalidate Translations Based on VPID) instructions. On hosts with an Intel processor and invept/invppid VM exit support, an unprivileged guest user could use these instructions to crash the guest.
Alerts:	Red Hat RHSA-2015:0284-01 kernel 2015-03-03 Oracle ELSA-2014-1997 kernel 2014-12-16 Oracle ELSA-2014-1971 kernel 2014-12-09 Oracle ELSA-2014-3096 kernel 2014-12-04 Oracle ELSA-2014-3096 kernel 2014-12-04 Mandriva MDVSA-2014:230 kernel 2014-11-27 Ubuntu USN-2418-1 linux-ti-omap4 2014-11-24 Ubuntu USN-2417-1 kernel 2014-11-24 Scientific Linux SLSA-2014:1843-1 kernel 2014-11-12 Oracle ELSA-2014-1843 kernel 2014-11-11 CentOS CESA-2014:1843 kernel 2014-11-11 Red Hat RHSA-2014:1843-01 kernel 2014-11-11 Scientific Linux SLSA-2014:1724-1 kernel 2014-11-03 Debian DSA-3060-1 kernel 2014-10-31 Oracle ELSA-2014-3084 kernel 2014-10-30 Oracle ELSA-2014-3084 kernel 2014-10-30 Oracle ELSA-2014-1724 kernel 2014-10-28 CentOS CESA-2014:1724 kernel 2014-10-29 Red Hat RHSA-2014:1724-01 kernel 2014-10-28

Comments (none posted)

keystone: information leak

Package(s):	openstack-keystone	CVE #(s):	CVE-2014-3621
Created:	October 23, 2014	Updated:	November 12, 2014
Description:	From the Red Hat advisory: A flaw was found in the keystone catalog URL replacement. A user with permissions to register an endpoint could use this flaw to leak configuration data, including the master admin_token. Only keystone setups that allow non-cloud-admin users to create endpoints were affected by this issue. (CVE-2014-3621)
Alerts:	Ubuntu USN-2406-1 keystone 2014-11-11 Red Hat RHSA-2014:1789-01 openstack-keystone 2014-11-03 Red Hat RHSA-2014:1790-01 openstack-keystone 2014-11-03 Red Hat RHSA-2014:1688-01 openstack-keystone 2014-10-22

Comments (none posted)

konversation: information disclosure

Package(s):	konversation	CVE #(s):	CVE-2014-8483
Created:	October 29, 2014	Updated:	March 9, 2015
Description:	From the Mageia advisory: Due to and out-of-bounds read issue in Konversation in The ECB Blowfish decryption function, a malicious client can cause either denial of service or disclosure of information from process memory by using an improperly formed message.
Alerts:	openSUSE openSUSE-SU-2015:0573-1 kdebase4-runtime, 2015-03-23 Debian-LTS DLA-168-1 konversation 2015-03-07 Fedora FEDORA-2014-13702 konversation 2014-11-15 Fedora FEDORA-2014-13791 konversation 2014-11-15 openSUSE openSUSE-SU-2014:1406-1 konversation 2014-11-12 Ubuntu USN-2401-1 konversation 2014-11-10 openSUSE openSUSE-SU-2014:1382-1 quassel 2014-11-10 Debian DSA-3068-1 konversation 2014-11-07 Debian DSA-3063-1 quassel 2014-11-02 Mageia MGASA-2014-0436 quassel 2014-10-29 Mageia MGASA-2014-0437 konversation 2014-10-29

Comments (none posted)

mythtv: SSDP reflection attacks

Package(s):	mythtv	CVE #(s):
Created:	October 29, 2014	Updated:	October 29, 2014
Description:	From the Mageia advisory: MythTV's UPNP component was susceptible to SSDP reflection attacks and has been hardened to disallow SSDP device discovery from non-local addresses as mitigation.
Alerts:	Mageia MGASA-2014-0435 mythtv 2014-10-29

Comments (none posted)

nova: privilege escalation

Package(s):	openstack-nova	CVE #(s):	CVE-2014-8750
Created:	October 23, 2014	Updated:	November 3, 2014
Description:	From the Red Hat advisory: A race condition flaw was found in the way the nova VMware driver handled VNC port allocation. An authenticated user could use this flaw to gain unauthorized console access to instances belonging to other tenants by repeatedly spawning new instances. Note that only nova setups using the VMware driver and the VNC proxy service were affected. (CVE-2014-8750)
Alerts:	Red Hat RHSA-2014:1781-01 openstack-nova 2014-11-03 Red Hat RHSA-2014:1782-01 openstack-nova 2014-11-03 Red Hat RHSA-2014:1689-01 openstack-nova 2014-10-22

Comments (none posted)

packstack: unexpected firewall disable

Package(s):	packstack	CVE #(s):	CVE-2014-3703
Created:	October 23, 2014	Updated:	October 29, 2014
Description:	From the Red Hat advisory: It was discovered that the nova.conf configuration generated by PackStack did not correctly set the libvirt_vif_driver configuration option if the Open vSwitch (OVS) monolithic plug-in was not used. This could result in deployments defaulting to having the firewall disabled unless the nova configuration was manually modified after PackStack was started. (CVE-2014-3703)
Alerts:	Red Hat RHSA-2014:1691-01 openstack-packstack 2014-10-22

Comments (none posted)

php: three vulnerabilities

Package(s):	php	CVE #(s):	CVE-2014-3669 CVE-2014-3670 CVE-2014-3668
Created:	October 23, 2014	Updated:	January 9, 2015
Description:	From the Fedora advisory: Fixed bug #68044 (Integer overflow in unserialize() (32-bits only)). (CVE-2014-3669) Fixed bug #68113 (Heap corruption in exif_thumbnail()). (CVE-2014-3670) Fixed bug #68027 (Global buffer overflow in mkgmtime() function). (CVE-2014-3668)
Alerts:	SUSE SUSE-SU-2016:1638-1 php53 2016-06-21 Oracle ELSA-2015-1135 php 2015-06-23 Mandriva MDVSA-2015:080 php 2015-03-28 Red Hat RHSA-2015:0021-01 php 2015-01-08 openSUSE openSUSE-SU-2015:0014-1 php5 2015-01-07 openSUSE openSUSE-SU-2014:1733-1 php5 2014-12-31 openSUSE openSUSE-SU-2014:1391-1 php5 2014-11-11 openSUSE openSUSE-SU-2014:1377-1 php5 2014-11-10 Gentoo 201411-04 php 2014-11-09 CentOS CESA-2014:1824 php 2014-11-06 Oracle ELSA-2014-1824 php 2014-11-06 Scientific Linux SLSA-2014:1824-1 php 2014-11-06 Red Hat RHSA-2014:1824-01 php 2014-11-06 Debian DSA-3064-1 php5 2014-11-04 Slackware SSA:2014-307-03 php 2014-11-03 Scientific Linux SLSA-2014:1768-1 php53 2014-11-03 Scientific Linux SLSA-2014:1767-1 php 2014-11-03 CentOS CESA-2014:1768 php53 2014-10-31 CentOS CESA-2014:1767 php 2014-10-31 CentOS CESA-2014:1767 php 2014-10-31 Oracle ELSA-2014-1768 php53 2014-10-30 Oracle ELSA-2014-1767 php 2014-10-30 Oracle ELSA-2014-1767 php 2014-10-30 Red Hat RHSA-2014:1766-01 php55-php 2014-10-30 Red Hat RHSA-2014:1765-01 php54-php 2014-10-30 Red Hat RHSA-2014:1768-01 php53 2014-10-30 Red Hat RHSA-2014:1767-01 php 2014-10-30 Ubuntu USN-2391-1 php5 2014-10-30 Mageia MGASA-2014-0430 php 2014-10-28 Fedora FEDORA-2014-13031 php 2014-10-28 Mandriva MDVSA-2014:202 php 2014-10-23 Fedora FEDORA-2014-13013 php 2014-10-23

Comments (none posted)

phpmyadmin: cross-site scripting

Package(s):	phpmyadmin	CVE #(s):	CVE-2014-8326
Created:	October 24, 2014	Updated:	November 3, 2014
Description:	From the Mageia advisory: In phpMyAdmin before 4.1.14.6, with a crafted database or table name it is possible to trigger an XSS in SQL debug output when enabled and in server monitor page when viewing and analyzing executed queries.
Alerts:	openSUSE openSUSE-SU-2014:1347-1 phpMyAdmin 2014-11-03 Fedora FEDORA-2014-13504 phpMyAdmin 2014-11-01 Fedora FEDORA-2014-13521 phpMyAdmin 2014-10-28 Mandriva MDVSA-2014:208 phpmyadmin 2014-10-24 Mageia MGASA-2014-0420 phpmyadmin 2014-10-23

Comments (none posted)

pidgin: multiple vulnerabilities

Package(s):	pidgin	CVE #(s):	CVE-2014-3694 CVE-2014-3695 CVE-2014-3696 CVE-2014-3698
Created:	October 24, 2014	Updated:	December 11, 2014
Description:	From the Debian advisory: CVE-2014-3694: It was discovered that the SSL/TLS plugins failed to validate the basic constraints extension in intermediate CA certificates. CVE-2014-3695: Yves Younan and Richard Johnson discovered that emotictons with overly large length values could crash Pidgin. CVE-2014-3696: Yves Younan and Richard Johnson discovered that malformed Groupwise messages could crash Pidgin. CVE-2014-3698: Thijs Alkemade and Paul Aurich discovered that malformed XMPP messages could result in memory disclosure.
Alerts:	Slackware SSA:2014-344-05 pidgin 2014-12-10 openSUSE openSUSE-SU-2014:1397-1 pidgin 2014-11-12 openSUSE openSUSE-SU-2014:1376-1 pidgin 2014-11-10 Fedora FEDORA-2014-14069 pidgin 2014-11-10 Ubuntu USN-2390-1 pidgin 2014-10-28 Mageia MGASA-2014-0425 pidgin 2014-10-25 Debian DSA-3055-1 pidgin 2014-10-23

Comments (none posted)

rubygem-httpclient: allows ssl negotiation

Package(s):	rubygem-httpclient	CVE #(s):
Created:	October 28, 2014	Updated:	October 29, 2014
Description:	From the Fedora advisory: Updated to 2.4.0 which stops hard-coding ssl v3 and allows ssl negotiation.
Alerts:	Fedora FEDORA-2014-13070 rubygem-httpclient 2014-10-28 Fedora FEDORA-2014-13040 rubygem-httpclient 2014-10-28

Comments (none posted)

sddm: multiple vulnerabilities

Package(s):	sddm	CVE #(s):	CVE-2014-7271 CVE-2014-7272
Created:	October 28, 2014	Updated:	December 4, 2014
Description:	From the Red Hat bugzilla: [ 1 ] Bug #1149608 - CVE-2014-7271 sddm: user "sddm" can login without authentication. [ 2 ] Bug #1148659 - sddm: multiple flaws in SDDM display manager leading to privilege escalation to root [ 3 ] Bug #1149610 - CVE-2014-7272 sddm: several local privileges escalation issues
Alerts:	Mageia MGASA-2014-0504 sddm 2014-12-03 Fedora FEDORA-2014-12442 sddm 2014-10-31 Fedora FEDORA-2014-12308 sddm 2014-10-28

Comments (none posted)

wget: symlink attack

Package(s):	wget	CVE #(s):	CVE-2014-4877
Created:	October 28, 2014	Updated:	March 29, 2015
Description:	From the Mageia advisory: Wget was susceptible to a symlink attack which could create arbitrary files, directories or symbolic links and set their permissions when retrieving a directory recursively through FTP.
Alerts:	Mandriva MDVSA-2015:121 wget 2015-03-29 Red Hat RHSA-2014:1955-01 wget 2014-12-03 Fedora FEDORA-2014-15405 wget 2014-12-01 Fedora FEDORA-2014-15385 wget 2014-11-22 Gentoo 201411-05 wget 2014-11-16 SUSE SUSE-SU-2014:1366-2 wget 2014-11-12 SUSE SUSE-SU-2014:1408-1 wget 2014-11-12 openSUSE openSUSE-SU-2014:1380-1 wget 2014-11-10 SUSE SUSE-SU-2014:1366-1 wget 2014-11-06 Scientific Linux SLSA-2014:1764-1 wget 2014-11-03 Debian DSA-3062-1 wget 2014-11-02 Ubuntu USN-2393-1 wget 2014-10-30 CentOS CESA-2014:1764 wget 2014-10-30 CentOS CESA-2014:1764 wget 2014-10-30 Oracle ELSA-2014-1764 wget 2014-10-30 Oracle ELSA-2014-1764 wget 2014-10-30 Red Hat RHSA-2014:1764-01 wget 2014-10-30 Slackware SSA:2014-302-01 wget 2014-10-29 Mandriva MDVSA-2014:212 wget 2014-10-29 Mageia MGASA-2014-0431 wget 2014-10-28

Comments (none posted)

Kernel release status

The current development kernel is 3.18-rc2, released on October 26. "I had hoped that the rc1 release would mean that a few stragglers would quickly surface, and then the rest of the rc would be more normal. But no, I had straggling merge-window pull requests come in all week, and rc2 is bigger than I'd like." Perhaps the most significant of those requests was for the overlayfs union filesystem, which has finally been merged after years of trying.

Stable updates: no stable updates have been released in the last week. As of this writing, the 3.17.2, 3.16.7, 3.14.23, and 3.10.59 updates are all in the review process; they can be expected on or after October 30.

Comments (none posted)

Toward better CPU idle-time predictions

The CPU idle ("cpuidle") code has one of those tasks that would be best handled with absolute knowledge of the future: knowing how long the processor will be idle so that the most appropriate sleep state can be chosen. Since that knowledge is hard to come by, the cpuidle code must get by with heuristics. At the 2014 Linux Plumbers Conference (LPC), Daniel Lezcano talked about a scheme he has to improve those heuristics and, in the process, bring about better integration between the scheduler and the cpuidle subsystem.

The current cpuidle code suffers from a number of shortcomings. It is not actually tied to the scheduler, so it has no idea of what the scheduler plans to do next. Even the most sophisticated governors tend to get things wrong, leading to the wrong sleep states being chosen. By focusing on a few relatively predictable parameters, Daniel hopes to come up with an approach to cpuidle that is both simpler and more accurate.

The "menu" cpuidle governor used on many systems looks at the recent past and tries to come up with a good guess as to how long the system will sleep the next time it goes idle. But actual system behavior depends on a wide variety of different events. Some, like timer expirations, are entirely predictable. Others, such as block I/O operations, are reasonably predictable, especially if one is watching carefully. Others, including things like keyboard events, are not predictable at all. Including these latter events in the calculation, Daniel said, leads to bad predictions and erratic performance from the cpuidle governor.

Daniel's cpuidle patch set addresses the most predictable wakeup events by having the scheduler pass the next timer expiration time into the cpuidle code. The scheduler also passes in the current latency requirement; cpuidle can use that information to avoid putting the processor into an overly deep sleep. The most unpredictable events, instead, are simply ignored in this version of the cpuidle code.

That leaves the moderately predictable events, primarily block I/O. Daniel's patch set starts by maintaining a simple running average of per-task I/O completion times. All tasks waiting for block I/O on a given CPU are put into a red-black tree; the closest expected completion time is easily obtained from that tree and used to predict the next wakeup time. But the running average is a bit too simple, being overly affected by the occasional operation that takes much longer (or much less time) than expected. So something a bit more complex is called for.

Daniel's response is to divide I/O completion times into buckets; after some investigation, he settled on 200µs as the optimal bucket granularity. Each bucket contains a counter of "hits," being the number of times that an operation has fallen into that bucket's duration. The buckets tracking I/O completion times are stored in a linked list. When a process first starts up, the data structure might look something like this:

The "hits" counter is incremented in the appropriate bucket for each I/O operation completion. After a small number of operations, the data structure might look like this:

Something interesting happens every time one bucket gains five hits though: it is moved to the beginning of the list. So, if the next operation completes in just over 200µs, the data structure will look like this:

The idea is that the buckets that see the most activity will be found toward the beginning of the list. When it comes time to predict when the next operation will complete, Daniel's code iterates through the list, computing a score for each bucket. Essentially, that score is the number of hits in the bucket divided by 1+2p, where p is the bucket's position in the list. So the bucket in the second position must have three times as many hits to get a higher score than the bucket in the first position.

The idea is to try to guess the most likely completion time based on both long-term and recent history. According to Daniel, it works pretty well, yielding far better results than the existing menu governor. Even so, this design did not survive the discussion in the LPC microconference, so any version of this patch set that gets into the mainline kernel is likely to look somewhat different.

The issue was the use of a per-task data structure for I/O completion time tracking. The advantage of this approach is that, when a task moves between CPUs, the tracking information will move with it, so the scheduler on the new CPU has an immediate idea of how long that task's I/O operations will take. But I/O completion times are not really a task-specific parameter; they are, instead, tied to the underlying device. And, as it happens, the kernel is already tracking device performance in the block layer. That information reflects current loads and should be quite accurate; using it might enable the entire bucket data structure to be done without.

So a future version of this patch set will probably be recast along those lines, using the backing store information already maintained by the kernel. But there are other challenges looming for this code. As Peter Zijlstra pointed out, the block layer is increasingly trying to maintain locality in I/O requests, ensuring that the CPU handling an I/O completion is the one that initiated the operation. Better locality makes sense, Peter said, but it also can conflict with the scheduler's attempts at distributing load across a system. It is harder to guess at wakeup times if it's not clear which CPU will wake up to deal with a specific I/O completion. The multiqueue block layer code is going to make this problem worse; some work will have to be done to reconcile these differing approaches to performance.

But, even if it is not a complete solution to the problem, Daniel's patch achieves the goals of better sleep-time predictions and better integration of the cpuidle code with the scheduler. That should be sufficient to get some version of this code into the mainline — someday.

[Your editor would like to thank the Linux Foundation for supporting his travel to this event].

Comments (9 posted)

In a bind with binder

The Android microconference at the 2014 Linux Plumbers Conference started off with an assessment of how the Android project was doing with regard to integration of its kernel changes with the mainline. The general feeling was that things are getting better; with 3.14, Android carries "only" 346 patches on top of the mainline kernel. But subsequent events have shown that the long-lasting tension between Android and mainline kernel developers has not entirely dissipated yet; the much-maligned Android "binder" mechanism is now one of the central points of that tension.

Many of the Android-specific components that are in the mainline kernel still live in the staging tree. Early in the session, Greg Kroah-Hartman got up to discuss whether any of those components should be moved out of staging — either out of the kernel tree entirely, or into the mainline proper. As an example of the first type, the Android "logger" module, which is no longer used as of the Lollipop release, may simply go away entirely. The story with binder is different, though.

Android's binder has a long history, having first shown up as part of the BeOS system. It is a mechanism for remote procedure calls and remote object management that is used heavily within the Android system. For an overview of how binder relates to other interprocess communication mechanisms, see this 2011 article by Neil Brown. Almost nobody seems to like binder; it is seen as abusing various low-level kernel interfaces, has known security problems when used outside of the tightly controlled Android setting, and more. But Android needs it, so it persists.

In the Plumbers session, Greg noted that binder had been in the staging tree for years. Since it is in active use, binder is not going away anytime soon. It is "horrible" and "broken by design," but it is an ABI that we need to support, Greg said, so we might as well move it out of the staging tree. No objections to the idea were raised in the session; everybody seemed happy with the idea of getting binder out of staging.

Greg wasted no time before posting a patch to move binder out of staging; it was on the lists before the Android microconference had concluded its business. Whether Greg expected the wider discussion to go as smoothly as the microconference is not clear; what is clear is that's not what he got.

John Stultz, who has done a lot of work toward the mainlining of Android-specific features, expressed a few concerns. The first of those had to do with maintenance: who was going to be the maintainer of this code, and had the Android developers agreed with that decision? Greg's response to this question was to note that the binder code had not changed in any significant way for a long time; there is not, he feels, a lot of maintenance that is needed. To the extent that binder needs a maintainer, Greg has volunteered to do it.

Another concern of John's had to do with efforts to replace binder with something better tied into the kernel; work is progressing on writing a binder-compatible library over the (still out-of-tree) kdbus interface. Moving binder into the mainline, he thought, might reduce the incentive to get that work done. Greg's answer here was that any such work is entirely new code; it doesn't mitigate the need to maintain the existing code "forever." "So as there really is nothing left to do on it, it deserves to be in the main part of the kernel source tree."

Finally, John worried that moving binder to the mainline might encourage others to make use of it; this was a concern that Alan Cox shared. Greg's response here is that there is never a way to control how others will use the software we ship. But, if anybody outside of Android were to use binder, he said, "you deserve all of the pain and suffering and rooted machines you will get."

Arnd Bergmann raised a number of issues mostly relating to security. Evidently Android does not use the full API exported by binder; he would like to see an audit of how the API is used so that the unneeded parts can be removed, reducing the attack surface of the whole thing. Binder also leaks kernel-space pointers into user space and has no awareness of namespaces, so it can also leak information between containers in undesirable ways. These points have not been addressed in the discussion so far.

Finally, Christoph Hellwig attempted to block the move outright, saying:

Greg disagreed about the claim that no work was being done toward a new interface; he also repeated that, no matter how that work goes, the existing interface needs to be supported indefinitely. Christoph was not satisfied by the answer, though; here he represents a group of kernel developers who feel that the Android developers are still not really trying to work with the mainline kernel. From this point of view, merging substandard Android code just allows Google to offload the pain of maintaining it and encourages more of the same behavior in the future. About the only tool that the kernel developers have to address this problem, as they see it, is their ability to refuse to accept inadequate code.

At that point, the discussion wound down. Greg has not said whether he still plans to move binder regardless of the points that have been raised. In the end, it could be said to make little difference; binder will be shipped with the kernel tree whether it is moved or not. But the decision to move binder or not could send a message on how the kernel development community feels about its relationship with the Android team.

[Your editor would like to thank the Linux Foundation for supporting his travel to the Linux Plumbers Conference].

Comments (6 posted)

A desktop kernel wishlist

GNOME developer Bastien Nocera recently shared a "wishlist" with the kernel mailing list, outlining a number of features that GNOME and other desktop-environment projects would like to see added to or enhanced in the kernel. In the resulting discussion, some of the wishlist items were subsequently crossed off, but many of the others sparked real discussion that could, in time, develop into mainline kernel features.

Nocera prefaced his list by saying that GNOME has had productive discussions with kernel developers in the past, and that the current list consisted of "items that kernel developers might not realise we'd like to rely on, or don't know that we'd make use of if merged." Most of these items fall into either one of two categories: power management or filesystem features, although there are a handful of others in the mix as well.

Less power

Under power management, Nocera listed native support for hybrid suspend (known as Intel Rapid Start on certain hardware), connected standby support, "a hibernation implementation that doesn't use the swap space", and several smaller items (such as establishing uniform semantics for screen-backlight settings and better documentation for managing USB power).

Hybrid suspend is a firmware-level feature intended to minimize the time require to restore a system from the suspended state. It works by initially suspending the system to RAM, but then writing the memory contents to disk (directly from the firmware) after a given time period and hibernating. Resume will be fast before the timeout expires, but the system will preserve its state regardless of how long it is suspended. Matthew Garrett wrote a patch implementing support for the feature in mid-2013, which Nocera subsequently made a push to merge upstream—a push that ultimately stalled. One of the critiques was that Intel's hybrid-suspend feature would eventually be made obsolete by connected standby, a newer idle-state power mode that allows certain background processes to continue. Garrett has also worked on an approach to connected standby.

John Stultz asked for clarification about one other power-management request: exporting the cause of a wake event. Nocera elaborated, saying that the goal was to be able to determine whether the machine was awakened by a user event or by a hardware event (such as the realtime clock alarm), in order to respond accordingly to different scenarios. The use case he cited was for user-space code to try and determine if it was a good time to run a previously scheduled backup: if the user woke the machine by opening the laptop lid, presumably it would be a bad time to start a lengthy backup process. If the wake was automatic, the backup should proceed.

Stultz, however, argued that reporting the cause of the wakeup would not truly satisfy the use case—in part because any number of wake events could take place (and, being asynchronous, could arrive in an unhelpful order) in between the kernel waking up and user-space code being able to run. But more importantly, as Zygo Blaxnell put it, which event was most recent is far less important than (for example) whether or not the user is actually using the machine—a fact that could be determined through other means, such as keyboard activity. Alan Cox, on the other hand, commented that, in the long term, most of the assumptions that go with current thinking about suspend, resume, and hibernation states may go away anyhow:

Filesystem issues

The second large category of feature requests concerned filesystem features and the VFS layer. First, Nocera reported that inotify is not meeting the needs of desktop utilities in a number of ways. Performance on large directory structures consumes too many resources, file-creation notification requires watching an entire directory, and monitoring directories' file-renaming and removal events is expensive on large directories. These limitations impact the performance of filesystem indexers, backup tools, and programs that manage file "libraries" (e.g., music and video managers).

Sergey Davidoff of elementary OS elaborated on the subject, saying that desktop application developers are keen to move to the file-library concept (as used in music and video managers) in other application types as well. Presenting the user with the filesystem hierarchy, he said, is far less useful than intelligently tracking the relevant files and allowing the user to search and interact with them based on their metadata. fanotify, as both noted, lacks the proper level of detail, such as reporting rename and move events.

Nocera also asked for a way to propagate timestamp changes up a directory chain. That is, if a file located in /foo/bar/ changes, there would be a way to detect the change not only on the file itself, but also on /foo/bar and on /foo itself. He added, though, that simply updating the change time on the containing directories would clearly be the wrong solution, since it would break many programs.

In short, he said, user-space programs would benefit from a better file-change notification system—ideally one that would consolidate events and monitor a directory structure without re-crawling it periodically. The combination of improving fanotify and adding user-space glue might work, he said, as would adding the changelog features currently available in Btrfs and XFS to other filesystems.

Pavel Machek asked whether or not a adding a (hypothetical) recursive version of the mtime timestamp would be a possible solution. Davidoff replied with skepticism that it would work for monitoring online changes, but that monitoring Btrfs's changelog "more or less as it happens" would probably suffice. In particular, monitoring Btrfs changelogs on the fly could at least ensure that a fixed-size buffer would get the job done, as opposed to the unbounded memory that fanotify would require for the same task.

Miscellany

Nocera's final cluster of wishlist items is a bit of a grab bag. It includes a better user-space API for the industrial input/output (IIO) subsystem used for various sensors, a user-space helper for the out-of-memory (OOM) killer, a system call to poll whether any processes out of a set of processes have exited, and a variant of epoll_wait() that accepts an absolute time rather than a timeout.

As was the case with the other categories, some of these items sparked quick responses. Patrik Lundquist suggested that the desired epoll_wait() functionality could be achieved with timerfd(). To that, Nocera quoted the original source of the request, Ryan Lortie, who said that making a separate call to set up timerfd() on every instance of entering the kernel to sleep is cumbersome, and that "epoll in general suffers from being _way_ too chatty about the syscalls that you have to do." Andy Lutomirski added that he had implemented procfs polling several years ago, and would be willing to resume work on it if it were useful. procfs polling would allow a user to open a set of /proc directories corresponding to a chosen set of processes, then poll the directories to see if any exit.

As to the other suggestions, there has thus far been little reaction either way. Certainly a number of the wishlist items boil down to implementing friendlier user-space APIs. Nocera commented on both the IIO and wake-event reporting issues that the present-day interface of examining raw sysfs files is far from sufficient.

On the whole, though, the kernel community has clearly been receptive to these needs of desktop-environment projects. On the wishlist wiki page, Nocera likened the exercise to the "plumbers' wishlists" submitted to kernel developers by Kay Sievers, Lennart Poettering, and Harald Hoyer. The plumbers' wishlist approach, of course, was successful enough that the plumbers in question have since repeated it. That bodes well for Nocera's desktop wishlist.

It is fairly common to hear about new kernel work that is driven by the needs of either high-end data center users or embedded-system builders—perhaps simply because companies in those lines of business tend to hire kernel developers. Thus, is it always good to see that the kernel community is equally responsive to the needs of user-space developers working in other areas, when those developers take time to reach out with their concerns.

Comments (14 posted)

A Debian init system GR flurry

One might have hoped that that Debian systemd debate would have wound down several months ago, after the technical committee decided the default init system question and especially after Matthew Vernon's general resolution on init system choice was withdrawn due to a lack of seconds. The Debian community, it seemed, was tired of this discussion and ready to move on. Given a few months to rest, though, even old, tiresome subjects can once again seem worthy of discussion. So now we have a return of the init system choice resolution — along with three alternatives of varying scope.

The GR returns

On October 16, Ian Jackson reposted Matthew's general resolution text as a new proposal. The core of this text is simple enough: "In general, software may not require a specific init system to be pid 1." There are some obvious exceptions — init systems themselves, for example — but the point of the resolution is that nearly the entire Debian distribution must be able to run, with nearly full functionality, under multiple init systems.

In March, this proposal failed to gain the required six seconds to go forward to a full-project vote. This time around, instead, the seconds came quickly, so the proposal will be voted on in the relatively near future. But the increased availability of seconds does not mean that there is a clear consensus behind this proposal.

One of the biggest concerns is about the effect this resolution will have on the upcoming "jessie" release, which is due to head into a feature freeze on November 5. Adding a new set of requirements to the distribution at this time, some think, is a sure recipe for delaying the jessie release. It has been pointed out that, seemingly, there are no packages in Debian now that require a specific init system, so no changes should be required for jessie. To some, that means that the resolution is not needed at all; others say that this is just the right time to address the issue before it does become a problem. In any case, Ian has added an amendment (which, like all of the options, can be seen on the Debian vote page) making it clear that this resolution is not expected to delay the jessie release.

Another objection is that this resolution imposes work on developers by forcing them to support multiple init systems whether they want to or not. Not forcing developers to do work is one of the core principles enshrined in the Debian constitution:

The question, is thus, whether rules on init system support constitute assigned work or whether they are simply rules that a developer may not act against. The case for the latter is perhaps best expressed by Steve Langasek, whose message deserves reading in full for those wanting to know where the motivation for this general resolution is coming from. As Steve put it:

Russ Allbery, instead, sees the init system issue as being similar to Debian's adoption of udev or the fact that Debian only works with one C library. He has a lot of faith that, as with previous issues, this one will work out over time if Debian developers are allowed to do what they see as the right thing. The general resolution, he thinks, is not the path toward that goal:

Anthony Towns takes a bit of a different approach, seeing init system support as a policy issue. Policy is not normally set by general resolution in Debian; instead, there is a policy committee charged with handling such issues. In his view, no developer could be compelled to add support for multiple init systems to a package, but, equally, the release managers could not be compelled to include that package in the distribution if policy argues otherwise. Anthony has a github repository containing his suggested policy changes.

Alternatives

While some developers have taken positions of opposition to Ian's proposal, others have taken the approach of offering amendments — alternatives that will be voted on with the initial proposal. As of this writing, there are three of these amendments, varying considerably in their approach to the problem.

The first of these, put forward by Debian project leader Lucas Nussbaum, aims for init system diversity but applies a lighter hand. Where Ian's proposal uses, in IETF terms, "MUST" phrasing, Lucas's uses "SHOULD" instead. The proposal says that packages should support the default init system on the architecture for which they are built, and that packagers should accept patches that increase init system portability in general. This proposal points in generally the same direction as Ian's, but it takes the form of advice rather than commandments.

The second amendment came from Luca Falavigna. It states that:

It goes on to say that a developer's technical decisions will not be overruled in the absence of documented defects, and that "fear, uncertainty, and doubt are not considered as evidence of defects." This amendment clearly runs counter to the first two, in that it explicitly allows developers to create packages that are dependent on a specific init system.

The final amendment comes from Charles Plessy. It states, simply, that things are working well as they are now and that no general resolution is needed. It could be thought of as an alternative to the required "further discussion" option that, with luck, would allow the project to do without having to actually endure further discussion on the subject.

Further discussion

If there is one thing the past few years of systemd debates have shown clearly, though, it's that further discussion is almost inevitable. Those who see systemd as the answer to a long list of system administration problems are unlikely to give up on exploiting its features to the extent that they are useful. Those who do not like the systemd approach or its development community, or who have, as Steve put it, "grave misgivings about Debian being tied to an upgrade treadmill by an upstream that may pay little heed to things that matter to Debian's community in the absence of a forcing function" are unlikely to be comforted without several years of experience to the contrary. With positions this far apart, one can be assured that there will be more to talk about.

The immediate question should be answered within a few weeks; this resolution is likely to go to a vote in early November. Whether that answer puts the issue to rest will depend on a number of things, starting with the Debian community's willingness to accept the answer and return to work putting together the jessie release. A stronger show of a desire to cooperate and respect Debian's concerns from the systemd community would certainly not hurt. Both communities will also have to make a point of ignoring the large mob of trolls that seems to revel in stirring up flame wars on this topic wherever it can.

That's a tall order, but, as Russ put it, Debian has been through many large, controversial decisions in the past and has always come out strong. There is no reason to believe that the project will fail to live up to that history this time around. But the process of getting there may be a bit messy for a while, yet.

Comments (140 posted)

Distribution quotes of the week

-- Stephen John Smoogen

-- Steve Langasek

-- Ian Jackson

-- Philip Hands (Thanks to Jóhann B. Guðmundsson)

Comments (6 posted)

Release for CentOS-6.6 i386 and x86_64

CentOS 6.6 has been released. "There are many fundamental changes in this release, compared with the past CentOS-6 releases, and we highly recommend everyone study the upstream Release Notes as well as the upstream Technical Notes about the changes and how they might impact your installation. (See the 'Further Reading' section of the [CentOS release notes])."

Full Story (comments: none)

First Jessie based Debian Edu alpha released

The first alpha release of Debian Edu (also known as Skolelinux) is available for testing. "Would you like to give your school's computer a longer life? Are you tired of sneaker administration, running from computer to computer reinstalling the operating system? Would you like to administrate all the computers in your school using only a couple of hours every week? Check out Debian Edu Jessie!"

Full Story (comments: none)

openSUSE Factory and Tumbleweed to merge

The openSUSE project has announced that the "Factory" and "Tumbleweed" distributions will merge into a single rolling distribution (called "Tumbleweed"). There is also an FAQ posting about the merger. "With the vast improvements to the Factory development process over the last 2 years, we effectively found ourselves as a project with not one, but two rolling release distributions in addition to our main regular release distribution. GregKH signalled his intention to stop maintaining Tumbleweed as a 'rolling-released based on the current release'. It seemed a natural decision then to bring both the Factory rolling release and Tumbleweed rolling release together, so we can consolidate our efforts and make openSUSE's single rolling release as stable and effective as possible."

Comments (none posted)

Qubes OS release 2 available

Release 2 of the Qubes OS secure desktop system is available. The biggest change, perhaps, is support for "fully virtualized AppVMs"; these allow running any operating system in a fully virtualized mode under Qubes. Other additions include secure audio input to AppVMs (allowing Skype to be run in a sandbox, evidently), policy control over the clipboard, an improved secure backup infrastructure, improved hardware support, and more.

Comments (2 posted)

SUSE Linux Enterprise 12 Now Available

SUSE has announced the release of SUSE Linux Enterprise 12. "New products based on SUSE Linux Enterprise 12 feature enhancements that more readily enable system uptime, improve operational efficiency and accelerate innovation. The foundation for all SUSE data center operating systems and extensions, SUSE Linux Enterprise meets the performance requirements of data centers with mixed IT environments, while reducing the risk of technological obsolescence and vendor lock-in." SUSE Linux Enterprise Server is available for x86_64, IBM Power Systems, and IBM System z.

Comments (24 posted)

Ubuntu 14.10 (Utopic Unicorn) released

Ubuntu has announced its latest release: 14.10 "Utopic Unicorn". As usual, it comes with versions for server, desktop, and cloud, along with multiple official "flavors": Kubuntu, Lubuntu, Mythbuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu Studio, and Xubuntu. All of the varieties come with a 3.16 kernel and many more new features: "Ubuntu Desktop has seen incremental improvements, with newer versions of GTK and Qt, updates to major packages like Firefox and LibreOffice, and improvements to Unity, including improved High-DPI display support. Ubuntu Server 14.10 includes the Juno release of OpenStack, alongside deployment and management tools that save devops teams time when deploying distributed applications - whether on private clouds, public clouds, x86 or ARM servers, or on developer laptops. Several key server technologies, from MAAS to Ceph, have been updated to new upstream versions with a variety of new features." More information can be found in the release notes.

Full Story (comments: none)

The Canonical Distribution of Ubuntu OpenStack

Canonical has announced a new OpenStack-oriented distribution. "Based on Canonical’s industry-leading OpenStack reference architecture and building on Ubuntu’s leading position as the most widely used OpenStack platform, the Canonical Distribution gives users the widest range of commercially-supported vendor options for storage, software-defined networking and hypervisor from Canonical and its OpenStack partners. It then automates the creation and management of a reference OpenStack based on those choices."

Note that some conditions apply: "The Canonical Distribution of Ubuntu OpenStack is now available as a public beta, free for up to 10 physical and 10 virtual machines". See this page for more information.

Comments (14 posted)

Announcing the Fedora 21 Alpha for the Aarch64 architecture

Peter Robinson has announced the release of Fedora 21 Alpha for ARM aarch64. "The initial release of Fedora for aarch64 focuses on the Fedora Base and Server product with support for hardware plarforms such as the APM Storm platform including devices like the Mustang board, AMD Seattle and ARM Versatile Express64 including the Foundation emulator and the Juno hardware platform."

Full Story (comments: none)

Ubuntu Online Summit

The next Ubuntu Online Summit will be held November 12-14. "Ubuntu Online Summit is your opportunity to find out what's new in Ubuntu, what's happening next in your favourite area, to contribute your ideas and bring up topics for discussion."

Full Story (comments: none)

Distribution newsletters

• Debian Project News (October 27)
• DistroWatch Weekly, Issue 582 (October 27)
• 5 things in Fedora this week (October 24)
• Gentoo Monthly Newsletter (September)
• Ubuntu Weekly Newsletter, Issue 389 (October 26)

Comments (none posted)

Ten years of Ubuntu (ars technica)

Here's a lengthy ars technica retrospective on Ubuntu's first ten years. "As you'll soon see in this look at the desktop distro through the years, Linux observers sensed there was something special about Ubuntu nearly from the start. However, while a Linux OS that genuinely had users in mind was quickly embraced, Ubuntu's ten-year journey since is a microcosm of the major Linux events of the last decade—encompassing everything from privacy concerns and Windows resentment to server expansion and hopes of convergence."

Comments (35 posted)

SUSE Linux Enterprise 12 Debuts With 'Rock-Solid' Cloud Support (Linux.com)

Linux.com takes a look at the newly released SUSE Linux Enterprise 12.

Comments (none posted)

Calculate Linux Provides Consistency by Design (LinuxInsider)

LinuxInsider has a review of Calculate Linux. "Calculate Linux 14, developed by Alexander Tratsevskiy in Russia, is not your typical cookie-cutter type of Linux OS. This latest version, released Sept. 5, is a rolling-release distribution that provides a number of preconfigured features. It uses a source-based approach to package management to optimize the software. This in part comes from its roots as a Gentoo Linux-based distribution. Calculate Linux comes in three more versions to expand its reach. Calculate Directory Server is for servers, and Calculate Linux Scratch for building customized systems. The Calculate Media Center is a distro to run a home multimedia center."

Comments (none posted)

A look at the Crosswalk web runtime

At the 2014 Tizen Developer Summit in Shanghai, Sakari Poussa presented an overview of Crosswalk, the web runtime designed to support Tizen's HTML5 application framework. Crosswalk builds on work from the Blink rendering engine and several other projects, but its goal of serving as a web-app runtime system makes for several distinctions with projects designed for use as a browser.

The web runtime is responsible for managing and running HTML5-and-JavaScript applications. In that sense, it serves a role that is similar to that of any web browser, but differs in some key areas. In web apps, the user does not have access to many (or any) of the normal user interface "chrome" or controls that comprise the basic interaction model of a standard browser. In addition, on mobile devices, the web runtime's support for hardware-access APIs is significantly more important, and it is responsible for starting, loading, and shutting down multiple app process at any given time.

Up through the Tizen 2.x series, Tizen releases shipped a web runtime based on WebKit. Crosswalk was started in September 2013, after Google forked its WebKit code into the Blink project. Currently, Poussa explained, new Crosswalk releases are made approximately once every six weeks, after the corresponding Blink release. The Crosswalk team attempts to push its own changes upstream, so that it can periodically rebase on Blink and minimize divergence. There are three Crosswalk release "channels"—Stable, Beta, and Canary (the unstable channel).

In addition to running on Tizen, Crosswalk builds are intentionally released for Android as well, with the goal of making the runtime fully cross-platform. Poussa said that the team is interested in seeing Crosswalk put to use in other open-source projects. That could mean other Linux-based mobile operating systems in need of a web-app runtime, but the Crosswalk implementation of newer APIs could prove useful to other Blink- and WebKit-related work as well.

Although it is easy to describe Crosswalk as "based on Blink," Poussa noted that the runtime also pulled in pieces of several other upstream projects, including Chromium, FFmpeg, the Skia graphics library, the V8 JavaScript engine, and the Cordova Android library. On top of these components are the Crosswalk-specific modules, such as the web-app manifest parser, the app runtime model, the app security framework, Tizen's implementation of the W3C System Applications (SysApps) APIs, and a framework for JavaScript extensions.

APIs

The SysApps APIs, manifest parser, and security framework are all pieces used to hook an HTML5 web app into Tizen's application framework. While some of the Tizen device profiles (such as the smartphone profile) also support native applications through another framework like EFL, not all do—but the HTML5 framework is common to every profile.

Thus, Crosswalk has quite a few HTML5 APIs that it needs to support. Poussa said that the project embraces the W3C APIs, but that it also serves as a "landing zone" for new draft APIs (some of which might undergo significant revision before stabilizing). As of now, he reported, Crosswalk ranks the highest on HTML5test's table of HTML5 API compatibility.

Poussa outlined six new features in Crosswalk that were not supported in the old Tizen web runtime. They include Web Components (encapsulated, reusable bundles of custom HTML elements), Service Workers (background JavaScript processes), support for Native Client code, web-app manifests, and two broader feature categories: SysApps and responsive design. The SysApps APIs incorporate several separate pieces related to integrating web apps into the OS platform, such as an API for querying device capabilities, a URI scheme for locally installed apps, and raw network sockets. The responsive design features include support for CSS media queries, the @viewport CSS rule, and the <picture> element (which can specify multiple images source to be used under various circumstances).

In addition, Crosswalk adds support for quite a few new APIs that have only recently become implementable standards, such as Promises (a method to asynchronously reply to resource requests), Resource Timing (for measuring the latency of loading a page resource), User Timing (for timestamping events), Ambient Light, Gamepad, NFC, JavaScript SIMD, WebRTC, Web Animations, and HTML5 Input.

The Tizen 2.x web runtime did ship an NFC "implementation," he noted, but it was a proprietary one, not the W3C standard. Compatibility with Tizen 2.x's runtime is an ongoing concern, he explained. The project is explicitly maintaining 2.x compatibility to ensure that existing web apps continue to function as expected. In addition, the project maintains compatibility with several outside products, such as Intel's XDK and Apache Cordova.

Architecture

Poussa then discussed Crosswalk's architecture. Tizen uses Smack as its security framework, with a significantly simplified, three-domain security policy in the 3.0 series. The Cynara service enforces the security policy, brokering API requests from the apps and checking them against the Smack policy to see if the app has the necessary permissions. Currently, he said, the Smack policy enforces a permission check on all APIs that access the hardware (including the Tizen Device API plus all W3C and experimental APIs that are hardware related). The permissions granted to each individual app are computed at installation time, based on the app's configuration file. Attempts to access anything outside of those permissions are met with a denial from Cynara.

When running on a device, Poussa explained, there is one shared Crosswalk browser process at all times. Each web app spawns a new Blink rendering process of its own and an extension process, so that each app is isolated from the others. These app processes talk to the base browser process via inter-process communication (IPC). The browser process talks to the operating system through the usual mechanisms, such as D-Bus or Unix domain sockets.

An audience member asked how the shared process related to the individual app processes as far as the Smack policy was concerned. In particular, he wondered if the shared process had permission to access all APIs, which might sound like a security risk. Poussa referred the question to Smack maintainer Casey Schaufler, who was also at the session. Schaufler replied that each installed app has its own Smack label, and that the policy rules and the Cynara permission checks were bound to these per-app labels, not to processes.

That explanation did not seem to fully satisfy the questioner, but in the interest of time, Schaufler encouraged him to attend the security session the following day rather than steer the current session off on a lengthy tangent. Despite being the Simplified Mandatory Access Control Kernel, it does seem like many developers have yet to get accustomed to how Smack works in Tizen.

Two other questions from the audience asked for clarification on the raw sockets API and on graphics. Raw sockets, Poussa explained, have been part of a long and slow specification process with the W3C, but the concept is fairly simple: the web app can connect to a general-purpose socket to communicate with another process—the other end of the connection never even knows that it is talking to a web app. The graphics layer uses Ozone, which supports multiple backends. One of those backends is Wayland (which is used by Tizen IVI), but there are other options that may be better suited to other device profiles, such as the hardware-accelerated framebuffer.

In the grand scheme of things, Poussa said, Intel wants Crosswalk to differ from the old, WebKit-based runtime in several key ways. The first is that everything will be done in the open: no code drops or private mailing lists. The team tries hard to keep a balance between implementing new features in Crosswalk and implementing them in the upstream projects first—only when time constraints are a pressing issue, he said, would work start in Crosswalk's branch of an upstream project.

The project also wants to close the gap between native app performance and web app performance, which is why some features (such as raw sockets and Native Client) are so important. In response to an audience question, Poussa said that Crosswalk developers have found Google's Blink project far more suitable for these goals than WebKit was. In WebKit, he explained, the project leadership was adamant that certain features do not belong in the rendering engine, and drew sharp lines that could not be crossed. In Blink, Google is implementing a wider feature set, which in turn makes it easier to extend Crosswalk's functionality.

Commercial Tizen 3.0 devices have yet to hit the market, of course, but Crosswalk could be useful to other open-source projects as well, Poussa said. Participation from non-Intel contributors has risen considerably in recent months, he said, which is a good sign. Regardless of when it reaches the masses, though, Crosswalk remains an interesting testbed for an HTML engine specifically targeting web-app deployment, rather than general browsing.

In many ways, the only major competitor to Crosswalk on today's Linux-powered mobile devices is the Gecko engine used in Mozilla's Firefox OS, although Android has been adding support for web apps as well. At the moment, there do not seem to be any projects other than Tizen making use of Crosswalk, but as interest in up-to-date web runtimes increases on a variety of platforms, that situation could change. At the very least, the competition is likely to be a motivating factor for most of the projects.

[The author would like to thank the Tizen Association for travel assistance to attend TDS 2014.]

Comments (none posted)

Quotes of the week

— Aaron Boxer (hat tip to Mattias Mattsson)

— Keith Packard, on the ups and downs of the e-book marketplace.

Comments (2 posted)

systemd 217 available

Version 217 of systemd has been released. New in this update are the ability for services to notify the manager before they begin a reload, the addition of a user-console daemon, and the removal of user-space firmware loading functionality.

Full Story (comments: none)

Development newsletters from the past week

• What's cooking in git.git (October 24)
• What's cooking in git.git (October 28)
• Haskell Weekly News (October 22)
• LLVM Weekly (October 27)
• OCaml Weekly News (October 28)
• OpenStack Community Weekly Newsletter (October 24)
• Perl Weekly (October 27)
• PostgreSQL Weekly News (October 26)
• Python Weekly (October 23)
• Ruby Weekly (October 23)
• Tor Weekly News (October 29)
• Wikimedia Tech News (October 27)

Comments (none posted)

Schaller: GStreamer Conference 2014 talks online

On his blog, Christian Schaller announced the availability of videos from the recently completed GStreamer Conference. "For those of you who like me missed this years GStreamer Conference the recorded talks are now available online thanks to Ubicast. Ubicast has been a tremendous partner for GStreamer over the years making sure we have high quality talk recordings online shortly after the conference ends. So be sure to check out this years batch of great GStreamer talks."

Comments (none posted)

Taiga, a new open source project management tool with focus on usability (Opensource.com)

Opensource.com takes a look at the Taiga project management tool. "It started with the team at Kaleidos, a Madrid-based company that builds software for both large corporations and startups. Though much of their time is spent working for clients, several times a year they break off for their own Personal Innovation Weeks (ΠWEEK). These are weeklong hack-a-thons dedicated to personal improvement and prototyping internal ideas of all sorts. While there, they unanimously decided to solve the biggest of their own problems: project management. Taiga was born, and by early 2014, the team at Kaleidos was already using Taiga for all their internal projects. Taiga Agile, LLC was formed in February 2014 to give the project a formal structure, and the source code was made available at GitHub."

Comments (5 posted)

Season of KDE 2014

The Season of KDE is a community outreach program, much like Google Summer of Code. "It is meant for people who could not get into Google Summer of Code for various reasons, or people who simply prefer a differently structured, somewhat less constrained program. Season of KDE is managed by the same team of admins and mentors that takes care of Google Summer of Code and Google Code-in matters for KDE, with the same level of quality and care." The student application deadline is October 31. The mentor application deadline is November 5.

Comments (3 posted)

Hildon Foundation assumes ownership of Maemo trademarks

The Hildon Foundation announced that it has reached an agreement with Nokia over the trademarks and other branding assets of the Maemo project. The agreement transfers the trademarks, pending trademark applications, and domain names—including maemo.org—to Hildon, who will take on "full responsibility and liability for the maintenance and support of all the activity that is and will be on-going on the Maemo Website." While undoubtedly a victory for the still-active Maemo community centered around Hildon, the announcement points out that Hildon will not be undertaking customer support for the existing Maemo devices.

Comments (none posted)

The Document Foundation joins the Open Source Business Alliance

The Document Foundation (TDF) has joined the Open Source Business Alliance (OSB Alliance). "'The Open Source Business Alliance has been a key stakeholder for LibreOffice, and for several members of the LibreOffice ecosystem. They have funded several interoperability features with Microsoft OOXML, and are an important source of information on the situation of large LibreOffice deployments', says Thorsten Behrens, TDF Chairman."

Full Story (comments: none)

EFF: Protect Yourself from Electronic Spying with 'Surveillance Self-Defense'

The Electronic Frontier Foundation has released an updated version of its 'Surveillance Self-Defense' report. "Surveillance Self-Defense includes briefings on important security issues, tutorials on using specific privacy software like PGP and OTR, and guides for specific categories of users, like human rights activists or journalism students."

Full Story (comments: none)

CFP Deadlines: October 30, 2014 to December 29, 2014

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

Deadline	Event Dates	Event	Location
November 1	April 10 April 12	PyCon North America 2015	Montreal, Canada
November 7	December 5 December 7	SciPy India	Bombay, India
November 9	March 21 March 22	LibrePlanet 2015	Cambridge, MA, USA
November 30	January 13	Linux.Conf.Au 2015 Systems Administration Miniconf	Auckland, New Zealand
December 1	February 6 February 8	DevConf.cz	Brno, Czech Republic
December 1	March 11 March 12	Vault Linux Storage and Filesystems Conference	Boston, MA, USA
December 7	January 31 February 1	FOSDEM'15 Distribution Devroom/Miniconf	Brussels, Belgium
December 8	February 18 February 20	Linux Foundation Collaboration Summit	Santa Rosa, CA, USA
December 10	February 19 February 22	Southern California Linux Expo	Los Angeles, CA, USA
December 14	January 12	LCA Kernel miniconf	Auckland, New Zealand
December 17	March 25 March 27	PGConf US 2015	New York City, NY, USA
December 21	January 10 January 11	NZ2015 mini-DebConf	Auckland, New Zealand
December 21	January 12	LCA2015 Debian Miniconf	Auckland, New Zealand
December 23	March 13 March 15	FOSSASIA	Singapore

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

LCA 2015 Call for Volunteers

Linux.conf.au is coming to Auckland, New Zealand January 12-16. "Volunteers are needed to register our delegates, show them to their accommodation, guide them around the University and transport them here and there. They will also manage our speakers by making sure that their presentations don't overrun, recording their presentations and assisting them in many other ways during their time at the conference. Anyone who has been a volunteer before will tell you that it’s an extremely busy time, but so worthwhile. It’s rewarding to know that you’ve helped everybody at the conference to get the most out of it. There's nothing quite like knowing that you've made a difference."

Full Story (comments: none)

Events: October 30, 2014 to December 29, 2014

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

Date(s)	Event	Location
October 31 November 2	Free Society Conference and Nordic Summit	Gothenburg, Sweden
November 1 November 2	OpenFest 2014	Sofia, Bulgaria
November 3 November 5	Qt Developer Days 2014 NA	San Francisco, CA, USA
November 3 November 7	OpenStack Summit	Paris, France
November 4 November 7	Open Source Developers' Conference 2014	Gold Coast, Australia
November 6 November 9	mini-DebConf	Cambridge, UK
November 7 November 9	Jesień Linuksowa	Szczyrk, Poland
November 8	Open Source Days	Copenhagen, Denmark
November 9 November 14	Large Installation System Administration	Seattle, WA, USA
November 10 November 14	21'th Annual Tcl/Tk Conference	Portland, Oregon, USA
November 11	Korea Linux Forum	Seoul, South Korea
November 13	Hackaday Munich	Munich, Germany
November 16 November 21	Supercomputing 14	New Orleans, LA, USA
November 17 November 21	ApacheCon Europe	Budapest, Hungary
November 18 November 20	Open Source Monitoring Conference	Nuremberg, Germany
November 19 November 21	CloudStack Collaboration Conference Europe	Budapest, Hungary
November 21 November 23	Debian Bug Squashing Party in Munich	Munich, Germany
November 22 November 23	AdaCamp Bangalore	Bangalore, India
November 25	New Directions in Operating Systems	London, UK
November 29 November 30	OpenPhoenux Hard and Software Workshop	Munich, Germany
December 5 December 7	SciPy India	Bombay, India
December 27 December 30	31st Chaos Communication Congress	Hamburg, Germany

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