Building GNOME Builder

At SCALE 13x in Los Angeles, Christian Hergert presented a session about his recent work on Builder, which is often referred to as an integrated development environment (IDE) for the GNOME desktop. But, as Hergert explained, the game plan for Builder extends far beyond the typical confines of IDE functionality. Builder, as he sees it, is GNOME's opportunity to reach newcomers who are learning about programming for the very first time—then to teach them the software-development skills that will help them become contributors.

Hergert started off by explaining the roots of the Builder project—a tale that began with a brief history of the GNOME project. Over the past 15 or so years, he said, GNOME has always placed a lot of emphasis on providing a good user experience. Often that has put GNOME in a position where it uncovers pain points elsewhere in the stack—many users, for example, first discovered bugs in their video drivers when they tried early versions of GNOME 3. Similar problems were uncovered with PulseAudio configuration and network-connection management when GNOME set out to implement better user interfaces for those subsystems.

One result of all of this work in other parts of the stack, though, is "the GNOME desktop environment" today means something much larger than the window-manager-and-dock that it meant in the early days. It includes a window compositor, media pipelines, input methods, filesystem abstractions, key management, tools for working with printers and devices, and APIs for geolocation and many other services. Thus, every year, the workload to maintain GNOME gets bigger—yet the GNOME community has remained approximately the same size for quite some time. Clearly, something more could be done to attract and cultivate new developers.

The other side of the story was Hergert's, rather than GNOME's. In 2012, he had published an open offer online, saying he would teach anyone the basics of coding in C if they just emailed him. Although he expected a handful of responses, he actually got thousands. In fact, he said, his inbox is still full of requests he has not had the time to answer. "And I'm a dinosaur," he added, "for using C. Imagine what the numbers would be if we were talking about Python or JavaScript."

Hergert tried to fulfill the C lesson requests students had asked for, he said, but ultimately failed. Initially he blamed himself for that, but, upon more reflection, he stopped taking it personally and started thinking about what sorts of questions the students had asked. The tools available were not up to the challenge: important utilities like Autotools were arcane and difficult to learn. But what struck him the most was that these students were interested in learning about free software, and the inability to "get started" with programming in general was essentially driving them away from GNOME and, presumably, toward other platforms.

What GNOME needs, he decided, is some way to guide newcomers through the getting-started process while also introducing them to the platform. Android, for instance, has a "developer mode" that does more than simply switch on new privileges: it also provides tools and helps the user learn about the software.

Those are the goals of GNOME Builder, the project that Hergert initiated in mid-2014. Builder will include an IDE, but the IDE will be geared toward developing software that works on GNOME—hooking into the build system, project management tools, diagnostics, and much more. Moreover, programming tutorials will be built-in, as will templates for working with GNOME libraries and a code-search tool that is linked to the GNOME source code.

The vision behind Builder is ambitious. Hergert voluntarily quit his day job to start the project; he was able to support himself for about four months working on Builder full-time, and subsequently ran a crowdfunding campaign that will pay for at least six more months of development time. In addition to himself, he said there are about 50 active contributors.

Currently the project involves two distinct pieces: the Builder user interface and the LibIDE shared library. It is "pre-pre-alpha," he said, but is fairly usable with C. Although he ultimately plans of focusing on other languages, Hergert said it was important to get C support working first in order to bootstrap the project. As of now, essential code editing, syntax highlighting, symbol resolution, and code search are working, and there is a sizable collection of boilerplate and template code for GNOME development that Builder can access. The initial keybindings and editor functionality implement a Vim mode, though Hergert said that an Emacs mode had landed just days earlier.

LibIDE is the focus of most of Hergert's development time. One of the more interesting features is live diagnostics: if the user types a syntactic error, the UI can highlight it using squiggly underlines akin to spellchecker warnings. That functionality is possible because the library uses Clang as its back end. Hergert said he would really like to use GCC as the compiler backend, but the GCC project's decision to not implement a library-like API (for things like accessing the abstract syntax tree) makes that impossible.

LibIDE supports Automake and Autotools at present, and will add additional build systems like Meson and CMake next. Similarly, although the library only supports Git version control now, other version-control systems like Bazaar are on the to-do list.

LibIDE is also scriptable with both JavaScript and Python. Hergert showed example scripts for automatically translating newlines on each save and for triggering a rebuild whenever a specific device (say, a Raspberry Pi) is attached over USB. The latter feature relates to Builder's support for cross-compiling—it is a specific goal to make Builder a useful IDE for writing programs for mobile devices and single-board computers. The scripting functionality can also be used to add new code-search providers, build extensions, and refactoring tools, he said.

He also discussed some of the GNOME integration work that is still under development. One example was writing a program that is meant to utilize a specific D-Bus service. The traditional approach might be to allow easy insertion of some boilerplate code, but that still leaves the user with the job of figuring out the right service to connect to and what syntactic sugar is required. Instead, LibIDE will provide a way to bring up a list of the currently running D-Bus services on the local machine; the user will only need to select the service of interest, and Builder will insert the properly customized code, rather than a blank boilerplate. Similarly, he hopes to have Builder automatically "do the right thing" for tasks like putting icons in the correct directory—tasks that, while supposedly simple, are often only dealt with well after development and during the packaging phase.

The session ended with a Q&A period. An audience member asked if writing the tutorials might be an opportunity to collaborate with an existing project like Codecademy. Hergert said that although he would like to do something like that, Codecademy is not a great fit, since it is not written with Linux systems (or GNOME in particular) in mind. Another question dealt with how Builder has uncovered pain points in the GNOME stack, like Hergert had mentioned at the beginning of his talk. He replied that there were some examples; he has decided that the normal GtkTextView widget does not work well for Builder's use case, and speculated that a "text grid" widget might be necessary, to correctly deal with monospaced text navigation.

In conclusion, Hergert commented that much of what goes into making an IDE work is not visible to the user. The Builder UI is minimalist; most of the work takes place behind the scenes: "if we do our jobs right," he said, "you won't have to care about anything but the UI." Looking forward, Hergert said that LibIDE and Builder will probably not be ready for inclusion in the upcoming GNOME 3.16 release (currently expected in approximately five weeks), but he thought that GNOME 3.18 was a reasonable target.

Comments (17 posted)

Makers and open source

At SCALE 13x in Los Angeles, Ruth Suehle spoke about the "maker" movement and its relationship to the open-source community—but she made it clear that, despite the affinity that the communities feel for each other, there are some stark differences between the two. The most troubling difference is that, particularly in recent years, the maker movement has drifted toward an "open by accident" model, without a strong commitment to freely sharing information. But open-source advocates can bring the maker movement back around, she said, by showing how they have addressed tricky problems like license compatibility and the challenge of making money while "giving everything away."

Suehle, who called herself a maker at heart, started off with a historical look at "making" in the physical world, from the advent of stone-age tools up through modern electronics. Sharing information is a through-line that permeates this history: early humans had to share information from person to person, she said. Imagine what the outcome would have been if one cave man refused to discuss discovering fire, she suggested.

But in much more recent times, people decided to stop sharing their knowledge. The ancient Greek city-state of Sybaris granted a patent-like protection to cooks, safeguarding their recipes against imitators for a year. A bit later, Roman blacksmiths started putting literal "trade marks" on their wares. In the 6th Century, the Irish missionary Saint Columba sparked one of the first conflicts over copyright when an abbot objected to Columba's practice of hand-copying books. The modern framework for patents originated with glassmakers in 1600s Venice—and rapidly spread to the rest of the world.

We now live in a world with contradictory messages about sharing, Suehle said. One of the first lessons children are taught is that sharing is important but, ironically, the adults who do the teaching no longer believe in the principle. In effect, they say "you should share your toys ... just as long as they're not my toys." This viewpoint, along with the rise of disposable consumer goods culture, led to the decline of fixing and repairing one's own property, she said.

The maker movement (at least, in the modern sense) started off as a revival of this older interest in fixing and modifying things. Suehle pointed out that the maker movement coincided with the prominence of "steampunk"—which just happens to be a throwback to an earlier era when technology was about hands-on work and tangible machinery.

Open by accident

Given its roots in the historical practice of sharing information, she said, it might seem like the maker movement should be enthusiastically committed to an "open by default" ethic. But that is not the way the maker movement is trending. Similarly, the open-hardware movement, while more formal about its principles than the decentralized maker movement, also seems to be drifting away from open-by-design ideas, with projects keeping certain parts of their work secret. Instead, she said, the movement seems to feature openness by accident, with people sharing their projects online solely because it is the "Internet age" and the Internet is the easiest way to publicize something.

By way of example, Suehle described her trip to the Open Hardware Summit in 2012. She went expecting to see lots of strong connections to the open-source movement, she said—but came away with deep concerns. Her write-up of the event for Opensource.com was headlined "Open Hardware Summit open to hybrid models," an assessment that she told the SCALE crowd was putting things optimistically.

In actuality, she found it deeply disconcerting how many high-profile speakers at the summit had downplayed or openly rejected the ideals of transparency and openness. She quoted keynote speaker Chris Anderson, who started off his talk by saying: "Everything I've learned as I built my own business is because people shared what they knew." But he followed that up a few minutes later with a different sentiment entirely, saying "I don't think we should be dogmatic. We need to consider other possibilities and approaches to open-based innovation."

In a more extreme example, she pointed out that Makerbot founder Bre Pettis had said in 2011 that "In the future, people will remember businesses that refused to share with their customers and wonder how they could be so backwards." But less than a year later, Makerbot took its previously open-hardware products closed. Pettis made that announcement at the summit:

Later, during his keynote at the event, Pettis referenced the community's reaction:

The same story was found at Maker Faires, Suehle said. In early years, the events were dominated by booths from Sparkfun and Radio Shack where visitors could learn to solder. Today, the exhibitors are predominantly there selling products—and, in many cases, products with (at best) tenuous connections to the maker movement, like Purina's latest line of cat feeders.

How open source can help

Suehle also noticed that essentially no one at these events was running Linux, which is telling. The maker community seems to be struggling today with many of the same problems that the open-source community solved ten years ago. Those problems include how to cope with project cloning, how to address legal issues, how to work with the user community, and how to make money.

The cloning issue, she said, is what Makerbot "freaked out" about, causing the company to take its Replicator2 printer proprietary. But there are plenty of success stories among those companies who release only open-source products—Suehle's employer, Red Hat, being one, she said. And there are examples of successful open hardware closely tied to the open-source software world. The Raspberry Pi, she said, has been cloned and modified and duplicated many times; "if there's a fruit, somebody has made a 'Pi' board for it," she said. Yet that has not diluted the popularity or success of the Raspberry Pi Foundation's products.

Makers and open hardware projects have legal concerns distinct from open source, she said. While open-source software is driven by copyright licensing, factors other than copyright are involved when dealing with physical objects. The community has developed two separate open-hardware licenses: one from CERN and one from Tucson Amateur Packet Radio (TAPR). Both, interestingly enough, are named "Open Hardware License." Reconciling them may prove difficult, but that is the sort of problem that the open-source community has dealt with many times in the past.

Suehle pointed out that the open-source movement resolved many of its difficulties by working through them as a community, which the maker movement will probably do as well. Today much of the maker movement community is found in local and regional hackerspaces. The hackerspaces are often isolated from one another, but there are examples where the movement is working together in large-scale, national or international efforts, which is a promising sign. She gave the open medical-device community as a key example.

The next challenge for the maker movement will be to figure out viable business models that can make money, she said. Many of the movement's highest-profile successes have been crowdfunding campaigns. They can have positive benefits, such as building an interested user community before launch, but they are still far from an instant-success formula.

The good news, Suehle said in conclusion, was that the drift away from "open by default" thinking among a few key players in the maker movement by no means spells disaster. Ultimately, the maker movement is made up of millions of people, and the open-source community can help them re-center themselves. Makers are a community that like to adapt and that thrive on innovation.

The open-source community knows both of those principles well—Suehle pointed out that open-source developers are, in fact, "makers" in their own right. The question is, what will the open-source community do to make things better in the maker movement, and to encourage the maker movement's virtuous cycle of innovation?

Comments (31 posted)

What's new in Krita 2.9

The newest update to the Krita digital painting application has been released. Version 2.9 introduces several new user-interface features, updates to the layers system, and a variety of tool and rendering improvements. The 2.9 development cycle was also the project's first to be centered around a crowdfunding campaign. In addition to raising funds, Krita's campaign allowed backers to vote on the priority of new feature work. The process was evidently successful enough that the Krita team is planning to use it during the next cycle as well.

The last major Krita release was version 2.8 in March of 2014, which we looked at back at the time. The 2.9 builds for supported platforms are available on the downloads page. Linux users, however, may find that the packages are available early through their distribution or through volunteer-run repositories. There is, for instance, a personal package archive (PPA) for Ubuntu-based systems.

The project started a crowdfunding campaign for the 2.9 cycle on Kickstarter in June, with a €15,000 goal that would be enough to fund one developer to work on twelve features to be chosen (by the donors) from a list of candidates detailed on the campaign page. A stretch goal would have support a second paid developer targeting twelve additional features for the same time period. The project beat its primary goal by a healthy margin (€19,955 in total), which meant the single-developer funding was secured. The project did, however, work on additional features during the development cycle. Backers voted on which features would be implemented, ultimately selecting an assortment of new transformation tools, improvements to the way Krita uses layers and masks, and fixes for some individual tools as the targeted feature set.

As of now, the project has successfully completed eleven of the twelve new features—in an email, Krita's Boudewijn Rempt said that the twelfth will arrive in the first point release following 2.9. It is always nice to see a free-software application have a successful fundraiser, of course, but the Krita campaign is also interesting because of the issues that the backers ranked as being of high importance. Specifically, many of them address transformations and layer manipulation, as opposed to (say) new brush engines. That suggests that Krita's core functionality—natural media simulation—is more-or-less meeting the needs of its users.

More than meets the eye

The transformation tools allow the user to warp and distort image content. The application has long had a standard-issue transform tool that could do skewing, stretching, and the like on a selected region. The new perspective transform is another option likely to seem familiar from other graphics applications; it lets the user distort the selection as if stretching it toward a vanishing point. A particularly nice touch is the red dots that help the user line up the transformation by showing where the vanishing points are. Users can also set up a "perspective assistant" using the ruler tool; the assistant is a grid overlay that provides lines running to the vanishing points so that it is easier to keep transformed objects properly aligned.

The "cage," "warp," and "liquify" transforms are a bit more interesting. The cage tool lets the user draw an arbitrarily shaped selection with straight line segments, then grab any number of vertices and move or rotate the drawing using the mouse. GIMP has a similar tool; it is most useful because the selection cage that the user draws serves to constrain where and how the distortions affect the image. A simple rectangle only has four corners to manipulate, so the content near those corners invariably get more distorted than whatever is in the center.

The warp tool is similar, except that the user chooses control points inside the selection, rather than using the vertices on the outside. Liquify is yet a third variation. Basically, it lets the user perform warp-like transformations anywhere in an image, without having to make a selection first.

The warp and liquify transformations are particularly sensitive to rendering problems; they distort the original image, so pixelated or blocky artifacts can be even more distracting if the transformation happens to enlarge the affected part of the image. Another feature funded by the Kickstarter campaign was to improve the quality of the transforms: the image data is sampled at 4x resolution and there is a new antialiasing algorithm.

Layering and masking

Several changes have been made to how the user works with layers and masks in Krita. For example, the user can now automatically create a mask for a layer that is generated directly from the layer's alpha channel. In other words, rather than trying to select all of the non-transparent pixels in a layer to mask them off, the same selection can be done with one click. Better still, the mask supports alpha transparency, so pixels with an intermediate alpha value get a semi-transparent mask.

Transparency masks are useful for protecting part of a layer from getting accidentally painted over. Krita has had support for the feature for a while, but a new feature in 2.9 is that these masks can be exported and loaded into different documents. That is primarily a feature that regular Krita users will appreciate, since it saves duplication of effort.

Transparency masks are made by painting a black-and-white layer; areas painted white are opaque (masking off the underlying image), while areas painted black are transparent and let the image beneath show through. The various values of gray in between constitute semi-transparent regions.

Finally, the transformation tools mentioned above can be applied to masks and layers, rather than operating directly on selected pixels. In essence, this means that the transformations can be saved as non-destructive operations that can be switched on and off by showing and hiding the mask or layer.

For anyone who is curious, the one new feature that did not land in time for the 2.9.0 release is a related idea. It is also one that will almost certainly be talked about by users who are converts to Krita from proprietary applications: support for "layer styles." A layer style is the ability to apply a "live" filter effect (blur, color adjustment, etc.) to a layer, so that the filter is applied to whatever content is visible from the layers below.

Photoshop has had a similar feature for a while and, rightly or wrongly, critics of free-software graphics applications are quite fond of pointing out specific differences like layer styles as evidence their applications are better. Whatever one thinks about the wisdom of implementing features first seen in proprietary applications, they are often the features that are requested the most.

Editing tools and workflow

Support for working with vector shapes has improved noticeably in the new release. Vector objects can now be rescaled to any size, regardless of the resolution of the canvas in the document. Previously, such scaling was constrained by the resolution of the document, which undermined a lot of the advantages of drawing with vectors to begin with.

Another new feature is support for gradients that follow the shape of an object. Previously, Krita had the usual palette of standard gradient types (linear, radial, etc.). The new gradient type allows for an even-looking gradient that fits into any polygon, selection, or even inside of text.

Krita 2.8 introduced initial support for the G'MIC image-filter system as a plugin. The 2.9 release finally supports the full G'MIC filter set. The user interface is the same as the G'MIC plugin for GIMP, which will certainly please all those who switch back and forth between several applications.

Another interesting change in Krita 2.9 allows the user to have the same file open in more than one window or tab. That means it is possible to see a zoomed-out perspective on the entire document while also working on a specific detail. In fact, the ability to have several images visible simultaneously is a new feature in its own right. The user can have, say, a reference image open in one part of the Krita application and work in another. In previous releases, the user would be able to switch back and forth between image tabs, but this is more convenient.

As is usually the case with Krita, there are far more small changes and updates than there is space to discuss in any detail. There are new color selectors for previously unsupported color models, there is a high-dynamic range painting mode, and there is support for saving and sharing collections of resources (like brushes and patterns) in external files.

Up next, the project plans to initiate another crowdfunding campaign to implement another batch of features—presumably including several from the 2014 fundraiser that have not been addressed yet. But the details of that next development round have yet to be announced; for now there is much for artists to explore in the 2.9 release without also worrying about what might be added further down the line.

Comments (none posted)

Lenovo and Superfish

While it doesn't directly affect Linux users, Lenovo's bundling of the Superfish adware—malware is probably more accurate—is serious enough to warrant a look. It is a blunder that has been compared with the Sony rootkit scandal of the mid-2000s and, in truth, is probably worse. Due to the bundling, users of Windows on certain Lenovo laptop models have had both their privacy and their security imperiled—sacrificed on the altar of ad delivery. It's not terribly surprising that Lenovo and Superfish have tried to downplay the severity of the incident, but that narrative seems unlikely to prevail.

Web browsers use a collection of root certificates (called the root store) to identify certificate authorities (CAs) and their keys. The public keys in those certificates are trusted to verify the TLS/SSL certificates for other web sites. Attackers who have access to the private key associated with a certificate in the root store can sign a certificate that purports to be from any domain on the internet. That certificate will be accepted by browsers without any questions or warnings. So a user visiting their bank might get an attacker-controlled certificate from a "man in the middle", who could proxy the traffic to the actual bank site while capturing passwords and other sensitive information.

Lenovo pre-installed Superfish to serve ads in the web browser on some of its laptop models; a list can be found at the end of Lenovo's first response to the incident. The company said that it stopped bundling Superfish in January after customer complaints. For those concerned that they might be affected, there is a site that they can visit to determine if Superfish (or some other forms of ad-malware) are running on their systems.

When it was installed by Lenovo, Superfish placed a root certificate into the Windows system root store; it also added the certificate to Firefox's (and Thunderbird's) separate root store. The intention is to be able to intercept the user's encrypted traffic so that ads can be shown; these will even show up on TLS-protected sites (i.e. HTTPS).

As it turns out, the Superfish ad serving proxy uses an "SSL hijacker" from Komodia [Wayback Machine link due to a denial of service attack against Komodia] to actually perform the man-in-the-middle attack. The Komodia hijacker intercepts the server certificate presented by the remote site, replaces the public key in the certificate with its own, then signs the certificate with the private portion of the public key placed into the root store.

The Komodia private key is protected by a password, but the password (which is the super-secure string "komodia") is the same on all of the installations. In fact, all of the Superfish-infected Lenovo laptops share the same key, but other Komodia-using applications get their own key. All appear to use the same password, however. Anyone with access to the keys can use them to sign any certificate they want, which will be accepted without complaint by the Komodia/Superfish-infected systems.

Unfortunately for Komodia, Superfish, Lenovo, and others, it gets worse than that. A man-in-the-middle attacker doesn't even need to use the easily available keys because the Komodia proxy will re-sign any bad certificate that it receives with its own key. It effectively launders bad certificates, turning them into valid certificates. It does actually change the domain name on the bad certificate, which will lead to a warning from the browser—except when it doesn't.

While it is likely that many users will just click past the warning, changing a self-signed certificate for example.com to verify_fail.example.com (as Komodia hijacker does) at least gives the user some warning. But the Komodia code doesn't handle any alternate names in the certificate, so an attacker can just put the real domain name they want to spoof in the alternate name field, Komodia will re-sign the certificate, and the browser will accept it without any questions. It makes exploiting the Komodia hijacker all that much easier.

The reaction from the players has ranged from nearly comical ("Despite the false and misleading statements made by some media commentators and bloggers, the Superfish software does not present a security risk", Superfish said) and Lenovo's since-removed original response ("We have thoroughly investigated this technology and do not find any evidence to substantiate security concerns") to a slowly evolving recognition that there is a real problem at hand (Lenovo's second and third statements on the uproar). So far, Komodia has not put out a statement at all.

While this "attack" targeted Windows, there is nothing that makes it an inherent problem for that operating system. A rogue application could certainly interfere with the root store(s) on a Linux system. It might be aimed at delivering ads, as this was, or perhaps as some kind of anti-cheating mechanism for a game or a DRM measure for some kind of media. In any of those cases, or other, similar scenarios, it would be hard to see that action as anything other than a man-in-the-middle attack.

But, in essence, the mechanism used is no different from what some network administrators do to the machines on their network: add a root certificate that provides a local trust anchor so that they can decrypt TLS traffic. That is why the certificate pinning feature that originated in Chrome/Chromium and has been added to Firefox does not thwart root certificates that have been installed locally. Thus the current implementations of certificate pinning are no defense against the Superfish/Komodia software. If pinning were to ignore local trust anchors, it would take away local administrators' ability to install their own certificates, either for snooping on traffic or simply to enable a separate company-controlled signing authority to avoid the expense of CAs. On the other hand, recent Android systems do warn users about certificates that have been added to the root store.

The real lesson from this horrendous security botch by Lenovo—beyond the idea of simply listening to security researchers rather than trying to bluster your way around them—is yet another reminder that the certificates stored on your systems need to be jealously guarded. Whether a rogue root certificate comes from a CA with inadequate safeguards or from a company that thinks it is a good idea to inject ads into your supposedly secure browsing hardly matters. The end result is the same: degradation or elimination of your privacy and security.

Comments (16 posted)

Security quotes of the week

Comments (6 posted)

EFF: Lenovo is breaking HTTPS security on its recent laptops

There are a lot of Lenovo users in LWN's audience. Presumably most of them have long since done away with the original software, but those who might have kept it around would be well advised to look into the issue; this site can evidently indicate whether a machine is vulnerable or not.

Comments (144 posted)

Green: Another update on the Truecrypt audit

Comments (5 posted)

Remote code execution vulnerability in Samba

Comments (68 posted)

apache-poi: denial of service

Comments (none posted)

bind9: denial of service

Comments (none posted)

drupal6-views: multiple vulnerabilities

Comments (none posted)

drupal7-path_breadcrumbs: access restriction bypass

Comments (none posted)

e2fsprogs: code execution

Comments (none posted)

freetype: many vulnerabilities

- Fixes CVE-2014-9656
   - Check `p' before `num_glyphs'.
- Fixes CVE-2014-9657
   - Check minimum size of `record_size'.
- Fixes CVE-2014-9658
   - Use correct value for minimum table length test.
- Fixes CVE-2014-9675
   - New macro that checks one character more than `strncmp'.
- Fixes CVE-2014-9660
   - Check `_BDF_GLYPH_BITS'.
- Fixes CVE-2014-9661
   - Initialize `face->ttf_size'.
   - Always set `face->ttf_size' directly.
   - Exclusively use the `truetype' font driver for loading
     the font contained in the `sfnts' array.
- Fixes CVE-2014-9662
   - Handle return values of point allocation routines.
- Fixes CVE-2014-9663
   - Fix order of validity tests.
- Fixes CVE-2014-9664
   - Add another boundary testing.
   - Fix boundary testing.
- Fixes CVE-2014-9665
   - Protect against too large bitmaps.
- Fixes CVE-2014-9666
   - Protect against addition and multiplication overflow.
- Fixes CVE-2014-9667
   - Protect against addition overflow.
- Fixes CVE-2014-9668
   - Protect against addition overflow.
- Fixes CVE-2014-9669
   - Protect against overflow in additions and multiplications.
- Fixes CVE-2014-9670
   - Add sanity checks for row and column values.
- Fixes CVE-2014-9671
   - Check `size' and `offset' values.
- Fixes CVE-2014-9672
   - Prevent a buffer overrun caused by a font including too many (> 63)
     strings to store names[] table.
- Fixes CVE-2014-9673
   - Fix integer overflow by a broken POST table in resource-fork.
- Fixes CVE-2014-9674
   - Fix integer overflow by a broken POST table in resource-fork.
   - Additional overflow check in the summation of POST fragment lengths.

Comments (none posted)

glibc: sends DNS queries to random file descriptors

Comments (none posted)

glibc: code execution

Comments (none posted)

java: unspecified vulnerability

Comments (none posted)

kernel: two vulnerabilities

Comments (none posted)

kernel: two vulnerabilities

Comments (none posted)

mozilla: multiple vulnerabilities

Comments (none posted)

openstack-glance: access restriction bypass

Comments (none posted)

php5: code execution

Comments (none posted)

php: use after free

Comments (none posted)

ruby-redcloth: cross-site scripting

Comments (none posted)

samba: root code execution

Comments (none posted)

tomcat: HTTP request smuggling

Comments (none posted)

typo3-src: authentication bypass

Comments (none posted)

xdg-utils: command execution

Comments (none posted)

Kernel release status

Stable updates: none have been released in the last week. The 3.18.8, 3.14.34, and 3.10.70 updates are in the review process as of this writing; they can be expected on or after February 27.

Comments (none posted)

Quotes of the week

Comments (none posted)

Lazytime hits a snag

That does not necessarily mean that 4.0 users will be able to enable this option, though. Jan Kara has identified some problems with the implementation that can cause incorrect times to be recorded in some situations. The issues look serious enough that use of lazytime in its current form is probably not a good idea. Ted is looking into the report, noting that the option can be disabled before the 4.0 release if the problems are not easily fixed.

According to Jan, that chances are that an easy fix will not be within reach. So it may well be that, while the 4.0 kernel will have the lazytime code, users will not yet have access to it. Having kernel features work as intended before exposing them to users is one thing developers cannot be lazy about.

Comments (none posted)

The end of the 4.0 merge window

• The overlayfs union filesystem can now support multiple read-only layers.

• The virtio subsystem has been updated for compliance with the recently adopted virtio 1.0 standard.

• The Btrfs filesystem has received a set of out-of-space-handling fixes resulting from its use at Facebook. The pull request suggests there will be more of these coming in the future.

• The dm-crypt device mapper target has seen a number of scalability improvements that improve its performance on larger systems.

• New hardware support includes:
  • Systems and processors: Intel Quark X1000 SoC boards and MIPS processors running MIPS32 Release 6.

  • Clock: TI CDCE706 clock synthesizers and Qualcomm IPQ806x and APQ8064/MSM8960 LPASS clock controllers.

  • Miscellaneous: Hisilicon NAND flash controllers, Renesas R-Car Gen2 DMA controllers, IMG multi-threaded DMA controllers, Allwinner SoC pulse-width modulator (PWM) controllers, Imagination Technologies PWM controllers, Intel Baytrail I2C semaphores, and Broadcom iProc I2C controllers.

  • Power management: Richtek RT5033 power management ICs, Dialog Semiconductor DA9150 charger fuel-gauge chips, and Qualcomm resource power managers.

  • Watchdog: Imagination Technologies PDC watchdog timers and Mediatek SoC integrated watchdogs.

The indications at the beginning of the merge window were that this would be a relatively small development cycle. In fact, as can be seen in the table below, one has to go back to 3.6 (released in September 2012) to find a merge window with fewer patches:

Patches pulled during the merge window
Release	Patches
4.0	8,950
3.19	11,408
3.18	9,711
3.17	10,872
3.16	11,364
3.15	12,034
3.14	10,622
3.13	10,518
3.12	9,479
3.11	9,494
3.10	11,963
3.9	10,265
3.8	10,901
3.7	10,409
3.6	8,587
3.5	9,534
3.4	9,248
3.3	8,899
3.2	10,214
3.1	7,202
3.0	7,333

From the table, one can see that there is a natural ebb and flow to the kernel development process; sometimes there is simply more going on than others. The overall trend remains in the upward direction, though, with the number of changes going into the kernel growing over the long (or even medium) term.

As was expected, Linus has bumped the major version number of this release to "4". There is little significance to this change beyond the fact that the minor numbers were getting large.

This development cycle has now moved into the stabilization phase where the remaining bugs are (hopefully) found and fixed. The last three development cycles have been exactly nine weeks long; if that pattern holds this time around as well, the 4.0 kernel will be released on April 12.

Comments (1 posted)

A rough patch for live patching

The code merged for 4.0 is a common core that is able to support patching with both kpatch and kGraft. It provides an API that allows patch-containing modules to be inserted into the kernel; it also allows the listing and removal of patches if need be. This API performs the low-level redirection needed to replace patched functions. That is good as far as it goes, but it is missing an important component, called the "consistency model," that ensures the safety of switching between versions of a function in a running kernel. If the change is simple, it may be possible to safely make the change at any time. More complicated changes, though, may require that no kernel code is running in any of the affected functions before the switch can be done. The consistency model as found in kpatch and kGraft is where some of the biggest differences between those two implementations lie, so some work will clearly be needed to bring them together.

As originally developed, kpatch worked by calling stop_machine() to bring the entire system to a halt. It then would check the stack of every process in the system to ensure that none are running within the function(s) to be patched; if the affected functions are not currently running, the patch can proceed, otherwise the operation fails. KGraft, instead, used a "two-universe" model where every process in the system is switched from the old code to the new at a "safe" point. The most common safe point is exit from a system call; at that point, the process cannot be running in any kernel code.

A unified consistency model

Both approaches have their advantages and disadvantages; an attempt to unite them would, hopefully, take the best from each. And that is what Josh Poimboeuf tried to do with his consistency model patch set posted in early February. This approach retains the two-universe model from kGraft, but it uses the stack-trace checking from kpatch to accelerate the task of switching processes to the new code. In theory, this technique increases the chances of successfully applying patches while doing away with kpatch's disruptive stop_machine() call and much of kGraft's higher code complexity.

The first objections to be raised focused on one particular aspect of the consistency code: the stack check. As Peter Zijlstra put it:

Ingo Molnar also came out against the use of stack traces. It comes down to the fact that getting a reliable stack trace out of a process running in kernel space is not as easy as one might expect. There have been lots of bugs in that code in the past, and each architecture brings its own set of special glitches to deal with. And, as Ingo pointed out:

What that means is that a bug in the traceback code is quite likely to stay out of sight until some distributor issues a live patch, at which point things will go badly wrong. The idea of things going badly wrong and disrupting a running system is just what users calling for live patching are most wanting to avoid, so one can imagine that widespread unhappiness would ensue. But it is a risk that will always be hard to avoid, since the correct functioning of the kernel does not otherwise depend on perfectly accurate stack traces.

There are a number of approaches to consistency, and not all of them use stack traces. Given the opposition to that idea, it seems likely that future proposals will omit that technique. But that leaves open the question of what will be used. Ingo is pushing strongly for an approach that forces every process in the system into a quiescent, non-kernel state before applying a patch. It is arguably the simplest approach; it also puts the kernel in a state where it is easy to know that applying the patch is a safe thing to do.

But, as it turns out, the "simplest" approach still has a fair number of tricky details. Kernel threads cannot be pushed out of kernel space, so some other solution must be found for them. Processes that are blocked in the kernel for some sort of long-term wait need to be unblocked, preferably in a way that can be restarted transparently once the patching process is complete. That could require changes to the implementation of a lot of system calls — and, perhaps, a lot of drivers as well. Some ideas for simplifying this task have circulated, but it would take a while to get an implementation to the point where it would reliably succeed in patching a running kernel.

An alternative would be to just go with the kGraft two-universe model, which does not depend on stack traces. The downside with this approach is that the process of trapping every process in a safe place can take an unbounded period of time during which the system is in a weird intermediate state. Yet another alternative is to do without the consistency model entirely. That would severely limit the range of patches that could be applied, but it seems that most security fixes (involving, say, the addition of a simple range check) could still be applied to a running system.

Live kernel upgrades

Perhaps feeling that he had not stirred the anthill sufficiently, Ingo went on to propose giving up on both kpatch and kGraft, saying "I think they are fundamentally misguided in both implementation and in design, which turns them into an (unwilling) extended arm of the security theater". Rather than trying to patch a running kernel, he suggested, why not just save the entire state of the system, boot into an entirely new kernel, then restore the previous state on top of the new kernel? That would get rid of consistency models, greatly expand the range of patches that can be applied, and, in theory, would be more robust.

This idea is not new, of course. The developers working on CRIU (checkpoint-restore in user space) have had seamless kernel upgrades in their list of use cases for a while, and they evidently have it working for some workloads. But making this functionality work robustly on all systems would require a great deal of extra work to snapshot the full system state (including the state of devices) and restore it all under an arbitrarily different kernel. Vojtech Pavlik, one of the developers behind kGraft, estimated that it would take ten years to make such a system work.

The users asking for live patching, it is safe to say, would not be thrilled about the prospect of waiting that long. It is also far from clear that the full-upgrade technique, once it actually works, can ever be fast enough to keep those users happy. Ingo estimated that a live upgrade could complete within ten seconds, but that is an eternity to users who find even subsecond stalls for patching to be overly disruptive. So, while there is widespread agreement that live upgrades are an interesting and possibly useful technology, there is little chance that any of the developers currently working on live patching will decide to refocus their efforts on live upgrades.

So work on live patching will continue, but it is not clear what direction that work will take. The hopes of getting the consistency-model code ready for the 4.1 merge window now seem somewhat remote; getting consensus on a design that can be merged could take some time. So, while it is still possible that the kernel will have an essentially complete live-patching feature by the end of the year, it may happen rather closer to the end of the year than the developers involved might have hoped for.

Comments (2 posted)

Key management with Gentoo Keys

In mid-January, Pavlos Ratis announced the first release of Gentoo Keys, which is a Python toolkit for handling OpenPGP keys. It is, in some sense, a complement to a plan for using OpenPGP keys within the distribution for signing files that has been adopted by the project. Ultimately, it is one of a number of efforts over the years for organizations of various sorts to standardize the best practices for using cryptographic keys. It is, it seems, something that each free-software project has to work out for itself.

While OpenPGP is the standard (codified in RFC 4880), one will commonly hear references to GNU Privacy Guard (aka GnuPG or GPG), since that is the dominant free-software tool that implements the standard. Essentially, GPG implements public-key cryptography for use in various ways. Some of the more common uses are for email encryption and for digital signatures that authenticate the source for a particular message or file. Those signatures can only be made by the holder of the private half of the key pair—that effectively means it was signed by the same person who registered the public half of the key pair.

Users, particularly security-conscious users, would like to know that the software they are downloading actually contains what they expect and has not been tampered with either in the repository or by some kind of "man in the middle" along the way. That is why distributions generally sign their packages with a distribution-specific key; package managers like RPM and dpkg can then verify those signatures. If the signatures do not match, the package manager can refuse to install the package.

But packages are built by developers and are uploaded into the project's infrastructure before they make their way out to users. Like with downloading packages, there are opportunities for attackers to tamper with the updated package source before users receive it. Ensuring that channel is secure requires a different strategy, with keys for each individual developer that can be used to sign the uploaded code.

As noted in the announcement, Gentoo Keys will help "establish the trust between the users and developers" by handling various key-related tasks. The intent is that it will verify keys and signatures "for Gentoo's release media, packages and other OpenPGP signed documents, i.e LiveDVDs, LiveCD's , stage* releases, Gentoo tree ebuild commits, [and] layman repositories list".

Gentoo Keys currently consists of two helper programs, gkeys-ldap and gkeys-gen, as well as the main gkeys program. gkeys-ldap is a tool that will be used inside the Gentoo infrastructure to do an LDAP lookup of developers' keys for use in "seed" files. Those files will contain a list of trusted key fingerprints, which can then be retrieved as needed by using the gkeys commands.

The gkeys-gen utility is meant to create keys for Gentoo developers based on the requirements adopted as part of Gentoo Linux Enhancement Proposal (GLEP) 63. The idea is to allow developers to generate keys that fulfill the GLEP 63 guidelines without needing to understand the details of GPG. Users can just run gkeys-gen, type in their name, email address, and password, and the program will generate a compliant key, as Gentoo Keys lead Brian Dolbec described. He also pointed to the project's first use page for additional information.

Another wiki page covers the steps to take after the keys are generated, such as backing up and publishing the generated keys. Given that those steps require using GPG directly, they would seem like something that might be pulled into gkeys-gen down the road.

The core of the new functionality resides in gkeys, itself. As described in its help page, gkeys has numerous sub-commands to manage keys and seed files, as well as to sign files and to verify signatures. When Gentoo Keys is first installed, it will install the keyring that holds the Gentoo release-media keys as well as a key that is used to sign seed files.

The seed files for Gentoo developers will also be installed. The actual keys can be retrieved as needed using the gkeys import-key command. The fingerprint of that key is then checked against what is listed in the signed seed file to ensure that the proper key has been retrieved. That provides a way for users and developers to retrieve the keys as needed but to ensure they have not been tampered with. In addition, gkeys spec-check can test keys to see whether they are GLEP 63 compliant.

As noted, Gentoo Keys is a toolkit. It provides tooling to help distribute, manage, and validate keys, but does not mandate how they are to be used. It would seem that more will be coming once the developers have generated their GLEP 63 keys, as the requirements for using the keys are still unspecified. But getting the right kinds of keys into the hands of developers, as well as the tools to manage them, is a good first step.

Comments (1 posted)

KaOS ISO 2015.02

Comments (none posted)

Ubuntu 14.04.2 LTS released + 15.04 ("Vivid Vervet") feature freeze

One other note from the Ubuntu world: a feature freeze is in effect for 15.04 ("Vivid Vervet"), which is due in April.

Full Story (comments: 9)

Debian Technical Committee: Transition plan to systemd by default

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 598 (February 23)
• Linux Mint Monthly News (February)
• Ubuntu Weekly Newsletter, Issue 405 (February 22)

Comments (none posted)

5 specialized Linux distributions for computer repair (Opensource.com)

Comments (1 posted)

A GNU C Library update

Recent history

The glibc 2.20 release came out last August featuring contributions from 69 developers. This release fixed 160 bugs, four of which had CVE numbers attached to them. It added support for Intel's MPX memory protection mechanism to the dynamic loader; that support is not useful for much now, but it will be a useful preparation once MPX-enabled applications appear in the future. Lock elision support has been added for the s390 architecture. There are new, optimized string functions for the ARMv7 and ARM64 subarchitectures, while support for the ancient AM33 subarchitecture has been removed.

Also in 2.20, the _BSD_SOURCE and _SVID_SOURCE feature test macros have been removed. The declarations formerly available under those macros are now under _DEFAULT_SOURCE, but, since it's the default, one need not set it explicitly. Roland's suggestion, though, was that most code would (continue to) want to use _GNU_SOURCE or one of the POSIX-specific macros. (See this article for an introduction to glibc feature test macros).

Support for file-private POSIX locks has been added to this release. And, finally, as of 2.20, the oldest supported kernel release is 2.6.32. Users staying with older kernels are, most likely, not going to update their C library either.

Glibc 2.21 was released on February 6. It had changes from 61 developers, fixing 101 bugs and five security issues. The MIPS architecture has gained support for the O32 FPXX, FP64, and FP64A ABIs. Support for the obsolete sigvec() functions has been removed (though ABI support remains for older binaries). The sigvec() ABI dates back to the 4.2 BSD release and, Roland said, was replaced by sigaction() 25 years ago.

The 2.21 release includes support for a handful of new locales. The i386 memcpy() implementation has been optimized. The PowerPC architecture has gained support for lock elision and optimized string functions as well. Various architecture-specific semaphore implementations have been replaced by a single generic version written in C; that should help the developers to maintain this code and avoid introducing race conditions in the future. Also in this release is support for Altera's NIOS II architecture.

The 2.22 release cycle has just gotten underway; as of Roland's talk it had five bugfixes but not much else. He expects to see a rework of the POSIX thread cancellation code to fix some race conditions there. The process of cleaning up the atomic-operation and futex code will continue as well; it is part of a long-term project to move the library toward the C11 memory model. Once that is done, he said, the developers should be able to have a higher level of confidence in the correctness of the library's synchronization code.

Glibc in the next five years

Looking forward, Roland said that, five years from now, the glibc developers will have put out ten releases and, probably, have fixed about 1,500 bugs. But it would be nice if the project could accelerate a bit, bringing in more useful features while maintaining the quality of the code. To do that, though, the developers need some more help.

One place where interested people could contribute is in bug triage. It takes a lot of work to go through the bug tracker, assign priorities to bugs, determine whether they might have security relevance, create minimal programs to reproduce bugs, and, even, write patches to fix them. Another area where help is needed is with benchmarks; what is there now is not really adequate to judge the value of performance patches. Benchmarks for the math library are especially needed. Microbenchmarks are valuable, but there is also a need for whole-system benchmarks that can be used for workload-specific tuning. Writing benchmarks, Roland said, is a great way to develop a working knowledge of the API.

Then, there is the matter of testing infrastructure. Glibc is, by its nature, a conservative project that puts a premium on not breaking things. Often the biggest blocker for new patches is the simple lack of adequate testing; a good automated testing framework would help the project to merge new code more quickly. The problem is not an easy one, though, he said.

Among other things, the project needs test suites that can run against an installed version of the library. Otherwise it can be hard to test the resolver and other parts of the library that interact with the rest of the system and the network. Some of the more complex tests probably need to be run within containers. Also needed is ABI comparison testing; the project has some "superficial" tests now that look at symbols, versions, and the size of data objects, but there's no testing for ABI breakage beyond that. The libabigail library out of the GCC project should probably be brought in to help with this task.

Finally, the developers could use help supporting the project's infrastructure — the wiki, bug tracker, build systems, etc. Interested people should consult the project's master "todo" list for lots more information.

An audience member asked about the handling of security bugs. Roland answered that the project Bugzilla includes a flag to mark whether any particular bug has been reviewed for security implications. The project could use some help with that kind of review, he said. One of the recent CVE entries for glibc referred to a bug that had been fixed in 2013, but nobody had realized at the time that it was exploitable. It would be nice to catch more of those, but, Roland said, the primary responsibility for identifying and responding to security bugs lies downstream with the distributors.

Another attendee asked about EGLIBC. Roland said that he's not really the right person to talk about that project but that, as far as he can tell, it has mostly gone away. Some of the developers behind the EGLIBC fork are now core glibc developers, and most (but not all) of the EGLIBC changes have been pulled back into glibc. In general, Roland would like to see all of the glibc forks out there merge back into the mainline. But, while distributors have patches that they apply, he is not aware of any distributors shipping forks at this point.

The next question had to do with contributor-agreement process that developers must go through to get code accepted; it was described as being complicated and an obstacle to contribution. Roland agreed with that assessment, but said that the legal aspects were outside of the project's control. Glibc is a GNU project; that fact is not going to change. It would be nice if the agreement process could be streamlined, but it is up to the GNU project to do that.

The last question had to do with support for building the library with the LLVM compiler. It was noted that there has been pushback against the merging of LLVM support into some GNU projects; would there be difficulties in getting LLVM support into glibc? Roland answered that he didn't see any reason for there to be trouble. In general, the glibc developers have been working toward the use of more standard language features and getting away from GCC extensions. That is a technical goal aimed at making the glibc code better. Technical improvement is where the glibc project's interests lie; the glibc developers, he said, are uninterested in the political issues.

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

Comments (48 posted)

Quotes of the week

Comments (none posted)

Astropy v1.0 released

Version 1.0 of the Astropy Python library has been released. Astropy is the core Python package for Astronomy development. Highlights of the 1.0 release include new sub-packages for visualization and for analytical functions, support for Altitude/Azimuth and Galactocentric coordinate systems, and significant speedups when reading and writing ASCII files, thanks to a C-based IO subsystem.

Full Story (comments: none)

GDB 7.9 released

Full Story (comments: none)

GNOME 3.15.90

Full Story (comments: 48)

Firefox 36 released

Comments (48 posted)

Development newsletters from the past week

• What's cooking in git.git (February 19)
• What's cooking in git.git (February 22)
• LLVM Weekly (February 23)
• OCaml Weekly News (February 24)
• OpenStack Community Weekly Newsletter (February 20)
• Perl Weekly (February 23)
• PostgreSQL Weekly News (February 22)
• Python Weekly (February 19)
• Ruby Weekly (February 19)
• This Week in Rust (February 23)
• Qt Weekly (February 23)
• Tor Weekly News (February 25)
• Wikimedia Tech News (February 23)

Comments (none posted)

Morevna Production Report #1

Comments (7 posted)

FOSDEM videos

Comments (9 posted)

Living free: recent updates to the DRM-free Living Guide

Full Story (comments: none)

Call for events: Be a part of Document Freedom Day 2015

Full Story (comments: none)

SciPy Latin América 2015 - Call for Proposals

Full Story (comments: none)

CFP Deadlines: February 26, 2015 to April 27, 2015

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

Events: February 26, 2015 to April 27, 2015

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