The Inkscape 0.92 release

On January 4, the Inkscape project released the latest stable version of its open-source vector-graphics editor. Version 0.92 adds a new tool for creating flexible color gradients that can vary with almost arbitrary complexity and it adds new capabilities to many of its existing drawing tools. There are new features to be found in the set of bundled extensions and path effects, as well as important updates to font features and to the application's ability to tune the XML objects in a scalable vector graphics (SVG) file. There are also some changes to how Inkscape handles some core document properties, however — changes that are mandatory if Inkscape is to fully support the SVG specification, but that might trip up unsuspecting users.

The 0.92 release was accompanied by a detailed set of release notes on the Inkscape wiki. The project has long required developers who check in new features to document those features in the upcoming release-notes page, an admirable practice that other free-software projects would do well to consider. If anything, the wiki page for a new release can veer toward being overly detailed but, on the other hand, there is never a last-minute scramble to write release notes from memory and risk accidentally leaving out something important.

As one would expect, the release itself is available to download for Linux, Mac OS X, and Windows. In addition to the usual packaging options, there is also a self-contained snap bundle available courtesy of Ted Gould (who is a member of both the Inkscape and snap teams). Ubuntu, of course, has built-in support for snap packages; installing the update requires only downloading the bundle. But the snap framework is available for other distributions as well; it may be a simpler way to test out the new release than waiting for a distribution repository update.

Perhaps ironically, the only peculiarity I encountered with the snap package of Inkscape 0.92 is that, when it is run on Ubuntu, it does not pick up the user's GTK+ 2 theme. This is, evidently, a choice that Gould made when creating the package, so that the application would look correct on non-Ubuntu systems. Once Inkscape is ported to GTK+ 3, it will cease to be an issue. Still, theme-sensitive Ubuntu users may prefer to fetch the release through the project's personal package archive (PPA) instead.

New user-visible features

Regardless of what package format you choose, the new Inkscape release sports a lot of user-visible changes. The most substantial is a type of new image element known as a mesh gradient. Part of the SVG specification, mesh gradients are fields of smoothly graduated colors that are defined on a deformable lattice.

The traditional gradients most users are accustomed to are defined on rectangles or ellipses, perhaps with transitions between multiple colors. Mesh gradients are an extension of that same concept; the difference is that the gradient lattice can be twisted around and reshaped arbitrarily, fitting into almost any shape — with as many straight segments, curves, and corners as desired. In addition to being fun to mess around with, mesh gradients are beneficial because they enable artists to create compact SVG documents that still exhibit complex coloration. A well-made mesh gradient element could replace dozens of layers of primitive gradients.

Text objects also gain a powerful new ability in this release: users now have full access to stylistic alternates and glyph variants in OpenType fonts. The variants include well-known examples like smart fractions, discretionary ligatures, and small capitals that are all defined in CSS, but OpenType allows fonts to include arbitrary features. Making use of them in software is still something of an ongoing battle even in the proprietary software world; Inkscape allowing users to access all of a font's OpenType features is a significant move in the right direction.

Also on the font front, whenever the user converts a text object into paths, the ARIA accessibility label (which contains the accompanying text) is now preserved, so users with any form of vision impairment will still be able to access the underlying text.

There are two new tools of interest that concern how Inkscape users manipulate objects in a drawing, even though neither tool is used to draw on the canvas. Each might take a bit of explanation. The first is the "Objects" dialog, which provides a way to access the tree of XML objects within the SVG file. An SVG drawing can easily include hundreds of image and text objects, many of which will be difficult if not impossible to select on the screen with a mouse.

In the past, Inkscape has provided some workarounds for this issue, such as using control keys to rotate through the objects located under the mouse until the right one is selected. But this dialog will be far simpler, for some users at least. Furthermore, having a full-featured dialog box makes it possible to interact with objects immediately. Need to change the color or opacity of an object? Simply type in the desired value. The dialog can also be used to individually lock or hide objects on the page.

The ability to access all of the SVG objects opens up some new possibilities as well. Users can assign meaningful names to every object, layer, or group, thus making those names accessible for other users in the future or to other software tools. For example, a designer can create a page full of icons in one Inkscape document, then run a script to select and export each of them as PNGs in a variety of sizes.

The other new feature is the "Selection sets" dialog, which allows the user to, in essence, define virtual groups of objects in the drawing. But, unlike the existing "group objects" feature, adding objects to a selection set does not permanently bind them together (nor does it change the z-axis ordering of the objects on the canvas). You can easily select the entire set by clicking on its name in the Selection sets dialog, but you can still move and edit the objects individually as needed. Here again, the main benefit is that large, complex documents become easier to work with.

Some smaller features worth pointing out in the new release include the ability to lock guide lines in place, the ability to set the document background to a checkerboard pattern (as opposed to white) so that transparent regions are easier to notice, and support for many more layer blending modes. Previous releases supported only the Multiply, Screen, Darken, and Lighten blending modes. Inkscape now supports eleven more. Furthermore, the blending mode can now be set on each object in a document separately; prior releases supported setting blending modes only at the document-layer level.

There are also some enhancements to existing drawing tools. The pencil tool, for instance, now supports an interactive smoothing feature, so users can simplify their line drawings without oversimplifying them. And the spray tool (which splatters around copies of a selected object in random, spray-paint style) saw numerous updates: an erase mode, better pressure sensitivity, the ability to avoid overlaps, and more.

Extensions and live effects

The above features are built into Inkscape's core drawing tools but, as is usually the case, there are even more new features to be found in the extensions and live path effects (LPEs) that ship with the program.

For instance, the pen tool is used by default to draw Bézier splines. But, with the addition of two new LPEs, it can now also draw B-splines and Spiro curves. Both are spline curves that are subject to special constraints meant to ensure that they exhibit fewer discontinuities. The curves thus appear smoother to the human eye, and they can meet stringent requirements for physical manufacturing.

There is also a suite of new LPEs for transforming objects on the canvas. The Perspective/Envelope transform might be the most familiar-looking: the user can grab handles on any corner of an object's bounding box and drag them around to distort its shape interactively. The Lattice Deformation LPE is more complex: it superimposes a five-by-five grid of handles over the object, and any of the handles — inside or on the perimeter — can be dragged to locally distort the object.

Conversely, the Transform By Two Points LPE is a simpler way to distort a shape: it provides one handle on each end of the object, which the user can drag around to squeeze or stretch things. That might be a preferable method for resizing an oddly shaped object, without distorting it internally. Whether the Perspective/Envelope or Lattice Deformation option is better for doing more complex distortions really depends on the object involved.

Other new LPEs include the "Roughen" and "Simplify" effects that roughen and smooth out vector objects, an effect to automatically rotate multiple copies of an object so that they follow the curvature of a path, and an effect to dynamically draw a mirror image of an object (making it far easier to draw objects with perfect symmetry).

While LPEs operate on top of the drawing surface, Inkscape extensions tend to be a bit more self-contained, such as performing several steps in sequence or iterating through a process. The new release adds several of interest. One helps the user generate seamless patterns, another changes the colors of a drawing to simulate several types of color blindness, another generates high-quality charts from values loaded from a CSV file.

That said, two of the new extensions add subtle enough functionality that they might not stand out as extensions at all. The "deep ungroup" extension will recursively ungroup all of the items in a nested set of groups-of-groups. The "set image attributes" extension iterates through a drawing to set the scaling factor for embedded PNG and JPEG images. In previous releases, whenever such an embedded bitmap file had been resized (particularly if it was resized by different amounts in the horizontal and vertical dimensions), the results would be displayed unpredictably.

Under the hood

As Inkscape moves closer and closer toward supporting the full SVG specification, it has made several changes to the underlying model that it employs for documents. This can be good or bad at any particular moment, depending on what one is doing and how one has used Inkscape in the past.

On one hand, Inkscape now supports many new standard SVG 2 and CSS3 properties such as paint-order and mix-blend-mode — even though the user interface does not yet expose a way to work with these properties. This is clearly good from a compatibility standpoint; SVG files opened in Inkscape will now look more like their original authors intended.

On the other hand, the new release changes the default resolution from 90 DPI to 96 DPI. As was the case with the change of grid-coordinate systems in the 0.91 release, the change brings SVG compliance but it may cause headaches for users who have old Inkscape documents sitting around and who open them in Inkscape 0.92. The application does offer plenty of warnings, but users should watch for oddities nonetheless. Similar caveats apply to text objects in two respects. First, "vertical text" in the Latin script is now rendered with all of the letters rotated 90°. This adheres to the specification, but users expecting the old behavior (with the letters standing upright beneath one another in a column) will have to adjust.

Second, Inkscape now follows the line-height definition as established in the CSS specification. That can affect line spacing in haphazardly created documents, because the CSS specification dictates how the line-height property cascades through the elements in a document. Indeed, one serious Inkscape user has already encountered trouble with this change. David Revoy reported that the line-spacing change "breaks" 10,000 of his files, and lashed out with some rather harsh words for the Inkscape team. Looking a little closer, the issue seems to be that Revoy renders his web comic from SVG source files, pulling in several translations for the captions and speech bubbles from external text files. The line-height change seemed to cause lines of text to collapse into one another.

In the bug report discussion, Tavmjong Bah noted that the line-height property was inappropriately specified in the document root as a percentage of a 12-pixel-high text, while the actual text elements in use within the comic were specified as 48 pixels high. Bah said there were a few options to fix the source files and posted Perl scripts that would transform the documents. Revoy replied that he would rather see a fix released in a post-0.92 update of Inkscape. As of press time, such a change has been staged, but an update has not yet been released.

Future-scape

If there is a lesson to be learned from Inkscape's need to change document defaults in order to follow an external specification, it is probably just that following specifications is difficult work. After all, the SVG and CSS specifications have undergone serious revision and expansion since the Inkscape project was started.

Along those lines, astute Inkscape historians may recall that the project publicly bumped the version number from 0.48 to 0.91 in 2014 in order to communicate to users that it was closing in on its goal of supporting the full SVG specification. At that time, a project spokesperson indicated that 0.91 would likely be the last release before Inkscape 1.0 — but that is clearly not how events have unfolded.

Release manager Bryce Harrington said in an email that the team expects to keep making incremental releases, and that 1.0 is not imminent. But that should not deter anxious Inkscape users from trying out the new release. As a lot of the new features in 0.92 demonstrate, Inkscape is more than just an SVG implementation. It supports a wide range of tasks, from technical work to pure creative expression.

Comments (3 posted)

Three new FOSS umbrella organizations in Europe

Last year, three new umbrella organizations for free and open-source software (and hardware) projects emerged in Europe. Their aim is to cater to the needs of the community by providing a legal entity for projects to join, leaving the projects free to focus on technical and community tasks. These organizations (Public Software CIC, [The Commons Conservancy], and the Center for the Cultivation of Technology) will take on the overhead of actually running a legal entity themselves.

Among other services, they offer to handle donations, accounting, grants, legal compliance, or even complex governance for the projects that join them. In my opinion (and, seemingly, theirs) such services are useful to these kinds of projects; some of the options that these three organizations bring to the table are quite interesting and inventive.

The problem

As a free/open-source software (FOSS) or open-source hardware project grows, it is likely to reach a point where it requires a legal entity for better operation — whether to gather donations, pay for development, handle finances, organize events, increase license predictability and flexibility by consolidating rights, help with better governance, or for other reasons. For example, when a project starts to hold assets — domain names, trademarks, or even just receives money through donations — that should not be the responsibility of one single person, but should, instead, be handled by a legal entity that aligns with the project's goals. A better idea is to have an entity to take over this tedious, but needed, overhead from the project and let the contributors simply carry on with their work.

So far, the options available to a project are either to establish its own organization or to join an existing organization, neither of which may fit well for the project. The existing organizations are either specialized in a specific technology or one of the few technology-neutral umbrella organizations in the US, such as Software in the Public Interest, the Apache Software Foundation, or the Software Freedom Conservancy (SFC). If there is already a technology-specific organization (e.g. GNOME Foundation, KDE e.V., Plone Foundation) that fits a project's needs, that may well make a good match.

The problem with setting up a separate organization is that it takes ongoing time and effort that would much better be spent on the project's actual goals. This goes double and quadruple for running it and meeting with the annual official obligations — filling out tax forms, proper reporting, making sure everything is in line with internal rules as well as laws, and so on. To make matters worse, failure to do so might result in personal liability for the project leaders that can easily reach thousands or tens of thousands of euros or US dollars.

Cross-border donations are tricky to handle, can be expensive if a currency change is needed, and are rarely tax-deductible. If a project has most of its community in Europe, it would make sense to use a European legal entity.

What is common between all three new European organizations is that none demand a specific outbound license for the projects they manage (as opposed to the Apache Software Foundation, for example), as long as it falls under one of the generally accepted free and open licenses. The organizations must also have internal rules that bind them to act in the public interest (which is the closest approximation to FOSS you can get when it comes to government authorities). Where they differ is the set of services they offer and how much governance oversight they provide.

Public Software CIC

Public Software CIC incorporated in February 2016 as a UK-based Community Interest Company. It is a fiduciary sponsor and administrative service provider for free and open source projects — what it calls public software — in Europe.

While it is not for profit, a Community Interest Company (CIC) is not a charity organization; the other two new organizations are charities. In the opinion of Public Software's founders, the tax-deductibility that comes with a charitable status does not deliver benefits that outweigh the limitations such a status brings for smaller projects. Tax recovery on cross-border charitable donations is hard and expensive even where it is possible. Another typical issue with charities is that even when for-profit activities (e.g. selling T-shirts) are allowed, these are throttled by law and require more complex accounting — this situation holds true both for most European charities and for US 501(c)(3) charitable organizations.

Because Public Software CIC is not a charity, it is allowed to trade and has to pay taxes if it has a profit at the end of its tax year. But as Simon Phipps, one of the two directors, explained at a panel at QtCon / FSFE Summit in September 2016, it does not plan to have any profits in the first place, so that is a non-issue.

While a UK CIC is not a charity and can trade freely, by law it still has to strictly act for public benefit and, for this reason, its assets and any trading surplus are locked. This means that assets (e.g. trademarks, money) coming into the CIC are not allowed to be spent or used otherwise than in the interests of the public community declared at incorporation. For Public Software, this means the publicly open communities using and/or developing free and open-source software (i.e. public software). Compliance with the public interest for a CIC also involves approval and monitoring by the Commissioner for Community Interest Companies, who is a UK government official.

The core services Public Software CIC provides to its member projects are:

• accounting, including invoicing and purchasing
• tax compliance and reporting
• meeting legal compliance
• legal, technical, and governance advice

These are covered by the base fee — 10% of project's income. This percentage seems to have become the norm (e.g. Software Freedom Conservancy charges the same). Public Software will also offer additional services (e.g. registering and holding a trademark or domain name), but for these there will be additional fees to cover costs.

On the panel at QtCon, Phipps mentioned that it would also handle grants, including coordinating and reminding its member projects of deadlines to meet. But it would not write reports for the grants nor would it give loans against future payments from grants. Because many (especially EU) grants only pay out after the sponsored project comes to fruition, a new project that is seeking these grants should take this restriction into consideration.

Public Software CIC already hosts a project called Travel Spirit as a member and has a few projects waiting in the pipeline. While its focus is mainly on newly starting projects, it remains open to any project that would prefer a CIC. At QtCon, Phipps said that he feels it would be the best fit for smaller-scale projects that need help with setting up governance and other internal project rules. My personal (and potentially seriously wrong) prediction is that Public Software CIC would be a great fit for newly-established projects where a complex mishmash of stake holders would have to be coordinated — for example public-private collaborations.

A distinct feature of Public Software CIC is that it distinguishes between different intangible assets/rights and has different rules for them. The basic premise for all asset types is that no other single organization should own anything from the member project; Public Software is not interested in being a "front" for corporate open source. But then the differences begin. Public Software CIC is perfectly happy and fit to hold trademarks, domain names, and such for its member projects (in fact, if a project holds a trademark, Public Software would require a transfer). But on the other hand, it holds a firm belief that copyright should not be aggregated by default and that every developer should hold the rights to their own contribution if they are willing.

Apart from FOSS, the Public Software CIC is also open to open-source hardware or any free-culture projects joining. The ownership constraint might in practice prove troublesome for hardware projects, though.

Public Software CIC does not want to actively police license/copyright enforcement, but would try to assist a member project if it became necessary, as far as funds allowed. In fact when a project signs the memorandum of understanding to join the Public Software CIC, the responsibility for copyright enforcement explicitly stays with the project and is not transferred to the CIC. On the other hand, it would, of course, protect the other assets that it holds for a project (e.g. trademarks).

If a project wants to leave at some point, all the assets that the CIC held for it have to go to another asset-locked organization approved by the UK's Commissioner of CICs. That could include another UK CIC or charity, or an equivalent entity elsewhere such as a US 501(c)(3).

If all goes wrong with the CIC — due to a huge judgment against one of its member projects or any other reason — the CIC would be wound down and all the remaining member projects would be spun out into other asset-locked organization(s). Any remaining assets would be transferred to the FSFE, which is also a backer of the CIC.

[The Commons Conservancy]

[The Commons Conservancy] (TCC) incorporated in October 2016 and is an Amsterdam-based Stichting, which is a foundation under Dutch law. TCC was set up by a group of technology veterans from the FOSS, e-science, internet-community, and digital-heritage fields. Its design and philosophy reflects lessons learned in over two decades of supporting FOSS efforts of all sizes in the realm of networking and information technology. It is supported by a number of experienced organizations such as NLnet Foundation (a grant-making organization set up in the 1980s by pioneers of the European internet) and GÉANT (the European association of national education and research networks).

As TCC's chairman Michiel Leenaars pointed out in the QtCon panel, the main goal behind TCC is to create a no-cost, legally sound mechanism to share responsibility for intangible assets among developers and organizations, to provide flexible fundraising capabilities, and to ensure that the projects that join it will forever remain free and open. For that purpose it has invented some rather ingenious methods.

TCC concentrates on a limited list of services it offers, but wants to perfect those. It also aims at being lightweight and modular. As such, the basic services it offers are:

• assurance that the intangible assets will forever remain free and open
• governance rules with sane defaults (and optional additions)
• status to receive charitable donations (to an account at a different organization)

TCC requires from its member projects only that their governance and decision-making processes are open and verifiable, and that they act in the public benefit. For the rest, it allows the member projects much freedom and offers modules and templates for governance and legal documents solely as an option. The organization strongly believes that decisions regarding assets and money should lie with the project, relieving the pressure and dependency on individuals. It promotes best practices but tries to keep out of the project's decisions as much as possible.

TCC does not require that it hold intangible assets (e.g. copyrights, trademarks, patents, design rights) of projects, but still encourages that the projects transfer them to TCC if they want to make use of the more advanced governance modules. The organization even allows the project to release binaries under a proprietary license, if needed, but under the strict condition that a full copy of the source code must forever remain FOSS.

Two of the advanced modules allow for frictionless sharing of intangible assets between member projects regardless whether the outbound licenses of these projects are compatible or not. The "Asset Sharing DRACC" (TCC calls its documents "Directives and Regulatory Archive of [The Commons Conservancy]" or DRACC) enables developers to dedicate their contributions to several (or all) member projects at the same time. The "Programme Forking DRACC" enables easy sharing of assets between projects when a project forks, even though the forks might have different goals and/or outbound licenses.

As further example, the "Hibernation of assets DRACC" solves another common issue — namely how to ensure a project can flourish even after the initial mastermind behind it is gone. There are countless projects out there that stagnated because their main developer lost interest, moved on, or even died. In this module there are special rules in place to handle a project that has fallen dormant and how the community can revive a project afterward to simply continue the development. There are more such optional rule sets available for projects to adopt; including rules how to leave TCC and join a different organization.

This flexibility is furthered by the fact that by design TCC does not tie the project to any money-related services. To minimize risks, [The Commons Conservancy] does not handle money at all — its statutes literally even forbid it to open a bank account. Instead, it is setting up agreements with established charitable entities that are specialized in handling funds. The easiest option would be to simply use one of these charities to handle the project's financial back-end (e.g. GÉANT has opted for NLnet Foundation), but projects are free to use any other financial back-end if they so desire.

Not only is the service TCC offers compatible with other services, it is also free as in beer, so using TCC's services in parallel with some other organization to handle the project's finances does not increase a project's costs.

TCC is able to handle projects that receive grants, but will not manage grants itself. There are plans to set up a separate legal entity to handle grants and other activities such as support contracts, but nothing is set in stone yet. For at least a subset of projects it would also be possible to apply for loans in anticipation of post-paid (e.g. EU) grants through NLnet.

A project may easily leave TCC whenever it wants, but there are checks and balances set in place to ensure that the project remains free and open even if it spins out to a new legal entity. An example is that a spun out (or "Graduated" as it is called in TCC) project leaves a snapshot of itself with TCC as a backup. Should the new entity fail, the hibernated snapshot can then be revived by the community.

TCC is not limited to software — it is very much open to hosting also open hardware and other "commons" efforts such as open educational resources.

TCC does not plan to be involved in legal proceedings — whether filing or defending lawsuits. Nor is it an interesting target, simply because it does not take in or manage any money. If anything goes wrong with a member project, the plan is to isolate that project into a separate legal entity and keep a (licensed) clone of the assets in order to continue development afterward if possible.

Given the background of some of the founders of TCC (with deep roots in the beginnings of the internet itself), and the memorandum of understanding with GÉANT, it is not surprising that some of the first projects to join are linked to research and core network systems (e.g. eduVPN and FileSender). Its offering seems to be an interesting framework for already existing projects that want to ensure they will remain free and open forever; especially if they have or anticipate a wider community of interconnected projects that would benefit from the flexibility that TCC offers.

The Center for the Cultivation of Technology

The Center for the Cultivation of Technology (CCT) also incorporated in October 2016, as a German gGmbH, which is a non-profit limited-liability corporation. Further, the CCT is fully owned by the Renewable Freedom Foundation.

This is an interesting set-up, as it is effectively a company that has to act in public interest and can handle tax-deductible donations. It is also able to deal with for-profit/commercial work, as long as the profit is reinvested into its activities that are in public benefit. Regarding any activities that are not in the public interest, CCT would have to pay taxes. Of course, activities in the public interest have to represent the lion's share in CCT.

Its owner, the Renewable Freedom Foundation, in turn is a German Stiftung (i.e. foundation) whose mission is to "protect and preserve civil liberties, especially in the digital landscape" and has already helped fund projects such as Tor, GNUnet, and La Quadrature du Net.

While a UK CIC and a German gGmbH are both limited-liability corporations that have to act in the public interest, they have somewhat different legal and tax obligations and each has its own specifics. CCT's purpose is "the research and development of free and open technologies". For the sake of public authorities it defines "free and open technologies" as developments with results that are made transparent and that, including design and construction plans, source code, and documentation, are made available free and without licensing costs to the general public. Applying this definition, the CCT is inclusive of open-source hardware and potentially other technological fields.

Similar to the TCC, the CCT aims to be as lightweight by default as possible. The biggest difference, though, is that the Center for the Cultivation of Technology is first and foremost about handling money — as such its services are:

• accounting and budgeting
• financial, tax and donor reporting
• setting up and managing of donations (including crowd-funding)
• grant management and reporting
• managing contracts, employment and merchandise

The business model is similar to that of PS CIC in that, for basic services, CCT will be taking 10% from incoming donations and that more costly tasks would have to be paid separately. There are plans to eventually offer some services for free, which would be covered by grants that CCT would apply for itself. In effect, it wants to take over the whole administrative and financial overhead from the project in order to allow the projects to concentrate on writing code and managing themselves.

Further still, the CCT has taken upon itself automation, as much as possible, both through processes and software. If viable FOSS solutions are missing, it would write them itself and release the software under a FOSS license for the benefit of other FOSS legal entities as well.

As Stephan Urbach, its CEO, mentioned on the panel at QtCon, the CCT is not just able to handle grants for projects, but is also willing to take over reporting for them. Anyone who has ever partaken in an EU (or other) grant probably agrees that reporting is often the most painful part of the grant process. The raw data for the reports would, of course, still have to be provided by the project itself. But the CCT would then take care of relevant logistics, administration, and writing of the grant reports. The company is even considering offering loans for some grants, as soon as enough projects join to make the operations sustainable.

In addition, the Center for the Cultivation of Technology has a co-working office in Berlin, where member projects are welcome to work if they need office space. The CCT is also willing to facilitate in-person meetings or hackathons. Like the other two organizations, it has access to a network of experts and potential mentors, which it could resort to if one of its projects needed such advice.

Regarding whether it should hold copyright or not, the Center for the Cultivation of Technology is flexible, but at the very beginning it would primarily offer holding other intangible assets, such as domain names and trademarks. That being said, at least in the early phase of its existence, holding and managing copyright is not the top priority. Therefore the CCT has for now deferred the decision regarding its position on license enforcement and potential lawsuit strategy. Accounting, budgeting, and handling administrative tasks, as well as automation of them all, are clearly where its strengths lie and this is where it initially wants to pour most effort into.

Upon a dissolution of the company, its assets would fall to Renewable Freedom Foundation.

Since the founders of CCT have deep roots in anonymity and privacy solutions such as Tor, I imagine that from those corners the first wave of projects will join. As for the second wave, it seems to me that CCT would be a great choice for projects that want to offload as much of financial overhead as possible, especially if they plan to apply for grants and would like help with applying and reporting.

Conclusion

2016 may not have been the year of the Linux desktop, but it surely is the year of FOSS umbrella organizations. It is an odd coincidence that at the same time three so different organizations have popped up in Europe — initially oblivious of each other — to provide much-needed services to FOSS projects.

Not only are FOSS projects spoiled for choice regarding such service providers in Europe, now, but it is refreshing to see that these organizations get along so well from the start. For example, Simon Phipps is also an adviser at CCT and I help with both CCT and TCC.

In fact, I would not be surprised to see, instead of bitter competition, greater collaboration between them, allowing each to specialize in what it does best and allowing the projects to mix-and-match services between them. For example, I can see how a project might want to pick TCC to handle its intangible assets, and at the same time use CCT to handle its finances. All three organization have also stated that, should a project contact them that they feel would be better handled by one of the others, they would refer it to that organization instead.

Since at least the legal and governance documents for CCT and TCC will be available online under a free license (CC0-1.0 and CC-By-4.0 respectively), cross-pollination of ideas and even setting up of new organizations would hereby be made easier. It may be early days for these three umbrella organizations, but I am quite optimistic about their usefulness and that they will fill in the gaps left open by the older US siblings and single-project organizations.

If a project comes to the conclusion that it might need a legal entity, now is a great time to think about it. At FOSDEM 2017 there will be another panel with CCT, TCC, PS CIC, and SFC that will be a perfect opportunity to pose any and all questions and comments you may have in person.

Comments (5 posted)

The Internet of scary things

Are you ready for the coming toaster apocalypse? Christopher Biggs started his 2017 linux.conf.au talk on "the Internet of scary things" by noting that a lot of "Internet of things" (IoT) devices are easily broken into and turned toward evil tasks. The result can be seen in the recent attack against DNS provider Dyn that used an array of compromised video cameras. But, he said, there are things that an aware user can do to mitigate the risk that don't require giving up on connected devices in general and that, with luck, the situation is getting better.

The risks associated with insecure IoT devices are serious and come in many forms. Compromised devices can be used for unauthorized information retrieval, for example. The paparazzi of the world will certainly appreciate the opportunity to look through a celebrity's camera, but stalkers, blackmailers, and nosy neighbors are also a threat. There's the threat of mass data collection that is not specifically targeted at anybody. Unauthorized control of devices is an obvious problem; pranksters have fun playing with lighting systems now, but the problem gets more severe when your front door is involved. With control systems and medical devices, the possibility of loss of life is real. It would not be funny if all the traffic lights in a city turned green at once, he said.

When identical devices are manufactured and sold in huge quantities, the possibility for mass takeover of those devices is real. The Mirai botnet is just one example of what can happen. These networks can be used for denial-of-service attacks, spamming, bitcoin mining, extortion, and more. There is also the problem of "plain old network intrusion". Networks are set up to deal with threats from the outside; IoT devices bring that threat to the inside. Firewalls are not always effective at preventing devices from tunneling out of the local network. The monsters, he said, are in the room with us.

For extra fun, these devices are finicky to set up, difficult to manage, and generally without any provision for updates. Their security is criminally bad, to the point that he has sometimes wondered if they are deliberately malicious. Hanlon's razor suggests that the state of IoT devices can be easily attributed to stupidity instead. Laziness is also part of the problem: devices ship with debug access enabled, with hard-coded passwords, and more. All of this failure is far from new: the Morris worm in 1988 used a vector quite similar to that employed by the Mirai botnet.

Part of the problem can also be attributed to fragmentation. Each device has its own cloud service, with different apps for each device. There are lots of little walled gardens out there. This problem could be fixed within the industry and, he said, there is actually a glimmer of hope that things are moving in that direction.

Why, he asked, does everything suck? Sturgeon's law is sufficient to explain much of the problem on its own, but there is more to it than that. IoT devices are created in short product cycles using software that is not necessarily up to the task — the industry is simply not sufficiently mature yet. Fragmentation is a big problem, with each vendor wanting to lock in customers. And security is simply hard. It's easy enough to scan for vulnerable devices that nobody can rely on obscurity as a way of staying safe. A test involving putting a Mirai-vulnerable device onto the net saw the first attack arrive within 70 seconds. The threat surface is too large, especially when vendors are lazy and don't strip out unneeded software; this leads him to believe that, for many of these devices, there may be better operating systems out there than Linux. Finally, the fact that users may not even notice a compromise factors into the problem; if the buyer of a device doesn't care, the vendor won't care either.

Staying safe

The nature of IoT devices is thus pretty clear. What is less clear is how to protect oneself from the threats posed by these devices without just tossing them all into the ocean. To that end, Biggs offered a few pieces of advice for worried IoT users.

The first suggestion is to simply accept that some IoT devices will not be fit for purpose. It may be a pain to return such items, but that should be done anyway in the hope of pushing the market toward better security. It is a good idea to regularly look for unexpected devices on one's WiFi network. LG has recently announced that it will be including WiFi in every device it sells; soon one might plug in a new toaster and not realize that it has just jumped onto the local net — or established a new, open WiFi network of its own. Running port scans on devices to see what services are running also makes sense.

Do not keep devices that ask you to do unacceptable things like running untrusted software. Users will also typically have better luck if they stick to devices running on one of the "big 3" frameworks managed by Apple, Google, and Amazon. These devices should have a common management interface, minimizing the number of holes being poked in the firewall. Support for open protocols should be demanded, he said; in general, interoperability demonstrates a certain level of competence.

Even better, of course, is a device that allows the firmware to be flashed with something of the owner's choosing. He cited the Sonoff series of power-control devices as being good in this regard. Isolating devices from the network and building your own control system can prevent a lot of mischief; projects like Homebridge and Node-RED can be helpful in this regard. Checking reviews can be helpful. In general, he said, positive reviews are meaningless, but negative reviews are often valid.

Once a device has been purchased, it should be deployed safely. IoT devices should, in general, be put on their own WiFi network whenever possible. OpenWRT makes it easy to create a separate network with its own filters. Even on a poor router with factory firmware, there is usually a guest network that can be used for IoT devices. Universal plug-and-play (UPnP) can be used to automatically poke holes in the firewall; it should be turned off if possible.

One should simply plan for breaches and think about what will happen when a device goes rogue. The network used for IoT devices should have a strict deny-by-default policy. Imposing rate limiting as well can help to limit the damage a device can do. Installed devices should be checked up on occasionally; if they show a traffic spike, something unwanted may be happening.

And, again, setting up your own "cloud" can offer some advantages; this is most easily done with devices that use one of the big frameworks. Homebridge can be used to make older devices available on the Apple control network, for example. Users of Amazon's Alexa protocol may want to look into Node-RED, which can bring hundreds of devices into the Alexa sphere. Surveillance cameras, in particular, should be managed with ZoneMinder or Motion; these can replace the higher-level functions of the firmware in the camera itself, reducing the camera to a dumb peripheral.

Building your own

What if, instead, you want to develop your own IoT device? The best advice is "get someone else to do the hard parts". One choice is Apple's HomeKit API; getting approval for new devices is hard, but success means that your product is better than most. If you're not going to get official approval, consider creating a Homebridge module to serve as a backdoor into the Apple protocol. In general, Apple has taken the approach of minimizing the intelligence in the devices themselves, allowing that logic to be placed in the higher-level control software.

Working with Amazon is easier, in that Amazon doesn't require certification, but the hub hardware is only available in the US and UK currently. He is impressed with the level of security built into these products. They are built on the MQTT protocol, making it relatively easy to make your own devices that can talk to Amazon's cloud services.

In the open-source world, there has been a lot of consolidation as a number of projects have joined together into the Open Connectivity Foundation. This group is designing a set of device profiles that describe the capabilities of individual devices and let devices discover each other. This builds on "the good parts" of UPnP and the Service Location Protocol.

IoT devices should not rely on a mobile app for setup. People installing thousands of devices in a new building will thank you. Devices should support open protocols like MQTT; they are the glue that holds the IoT together. Speaking MQTT allows interoperation with a number of home-automation frameworks. MQTT can be thought of as a sort of IRC for robots, he said.

Do not forget long-term support. Everybody will lose the instructions, so devices should be self-documenting. The device should have a well-defined support life, with updates provided regularly. Finally, IoT developers need to recognize that these devices are not just miniaturized Unix PCs; they should be carefully stripped down to be sure they are not running any software that is not absolutely necessary.

Things may be getting better

There is, he said, some light at the end of the tunnel; various groups are realizing that they need to get serious about this problem. BITAG is a group founded by Google, Intel, Microsoft, and others to put together a set of recommendations on best practices. Its advice can be boiled down to "don't be lazy and stupid". The Open Connectivity Foundation is also doing good work. Bruce Schneier has been advocating for more regulation, but Biggs said that could go badly wrong. He could support regulations analogous to radio emissions testing, though.

Recently, Google shipped a developer's preview of its Android Things toolkit. It's not ready for prime time; its device profile support is limited currently. But the technology looks promising. He likes the standard camera interface in Apple's HomeKit, which allows bypassing most of the bundled firmware in such devices. Amazon's Alexa is looking good, though, he said, there is some concern about how much it listens to. The Open Connectivity Foundation has a reference framework implementation called IoTivity. It is, he said, one to watch, though he expressed concerns about the use of C as its implementation language.

One other framework worth considering is resin.io. It's open source, and has some good tools. It is based on Linux and Docker; the project can handle the containerization of an IoT application and send it out to the devices. These devices maintain a connection back to the cloud allowing for remote management and updates. The number of systems supported is relatively small at the moment, though. The project's focus is more in enterprise devices than consumer devices, but it is still worth checking out.

One app that is useful for consumers is Fing; it can be used to scan your local network. Fing is working on a small hardware device that can sit on, and monitor, a network; it will serve as a sort of intrusion detection system for networks without their own administrator. [Editor's note: potential Fing users may want to look at its privacy policy before installing the app.]

What's missing? We need to move beyond allowing devices to connect to anything they want; device profiles should be extended to describe their connectivity requirements. There is also a need to make vulnerability alerting and patch distribution work. He suspects that few members of his family are going to subscribe to Bugtraq for that purpose. Frameworks like resin.io are good for patch distribution, but it's still a centralized service; what is really needed is a common standard.

In summary, things are awful, but that's not unexpected in a "baby industry" like IoT. If buyers choose and deploy devices with care, and if builders focus on doing the job right, the worst should be avoidable. The job will get easier over the next year as the frameworks mature.

The video of this talk is available on YouTube.

[Your editor would like to thank linux.conf.au and the Linux Foundation for assisting with his travel to the event.]

Comments (18 posted)

Security quotes of the week

— Mike Specter (Thanks to Paul Wise.)

— Bruce Schneier

Comments (none posted)

389-ds-base: denial of service

Package(s):	389-ds-base	CVE #(s):	CVE-2017-2591
Created:	January 30, 2017	Updated:	February 1, 2017
Description:	From the Mageia advisory: The "attribute uniqueness" plugin did not properly NULL-terminate an array when building up its configuration if a so called 'old-style' configuration was being used. An attacker, authenticated, but possibly also unauthenticated, could possibly force the plugin to read beyond allocated memory and trigger a segfault. The crash could also possibly be triggered accidentally.
Alerts:	Mageia MGASA-2017-0028 389-ds-base 2017-01-27

Comments (none posted)

ansible: password change botch

Package(s):	ansible	CVE #(s):	CVE-2016-8647
Created:	January 26, 2017	Updated:	February 1, 2017
Description:	From the Red Hat bugzilla entry: It is reported that in Ansible, under some circumstances the mysql_user module may fail to correctly change a password. Thus an old password may still be active when it should have been changed.
Alerts:	Fedora FEDORA-2017-418398ce60 ansible 2017-01-25 Fedora FEDORA-2017-cb88734094 ansible 2017-01-25

Comments (none posted)

ansible: code execution

Package(s):	ansible	CVE #(s):	CVE-2016-9587
Created:	January 26, 2017	Updated:	February 1, 2017
Description:	From the Red Hat advisory: An input validation vulnerability was found in Ansible's handling of data sent from client systems. An attacker with control over a client system being managed by Ansible and the ability to send facts back to the Ansible server could use this flaw to execute arbitrary code on the Ansible server using the Ansible-server privileges. (CVE-2016-9587) This LWN article has additional details.
Alerts:	Gentoo 201701-77 ansible 2017-01-31 Fedora FEDORA-2017-418398ce60 ansible 2017-01-25 Fedora FEDORA-2017-cb88734094 ansible 2017-01-25 Red Hat RHSA-2017:0195-01 ansible 2017-01-25

Comments (none posted)

chromium-browser: multiple vulnerabilities

Package(s):	chromium-browser	CVE #(s):	CVE-2017-5006 CVE-2017-5007 CVE-2017-5008 CVE-2017-5009 CVE-2017-5010 CVE-2017-5011 CVE-2017-5012 CVE-2017-5013 CVE-2017-5014 CVE-2017-5015 CVE-2017-5016 CVE-2017-5017 CVE-2017-5018 CVE-2017-5019 CVE-2017-5020 CVE-2017-5021 CVE-2017-5022 CVE-2017-5023 CVE-2017-5024 CVE-2017-5025 CVE-2017-5026
Created:	January 27, 2017	Updated:	February 20, 2017
Description:	From the Red Hat advisory: CVE-2017-5007 chromium-browser: universal xss in blink CVE-2017-5006 chromium-browser: universal xss in blink CVE-2017-5008 chromium-browser: universal xss in blink CVE-2017-5010 chromium-browser: universal xss in blink CVE-2017-5011 chromium-browser: unauthorised file access in devtools CVE-2017-5009 chromium-browser: out of bounds memory access in webrtc CVE-2017-5012 chromium-browser: heap overflow in v8 CVE-2017-5013 chromium-browser: address spoofing in omnibox CVE-2017-5014 chromium-browser: heap overflow in skia CVE-2017-5015 chromium-browser: address spoofing in omnibox CVE-2017-5018 chromium-browser: universal xss in chrome://apps CVE-2017-5020 chromium-browser: universal xss in chrome://downloads CVE-2017-5021 chromium-browser: use after free in extensions CVE-2017-5022 chromium-browser: bypass of content security policy in blink CVE-2017-5023 chromium-browser: type confusion in metrics CVE-2017-5024 chromium-browser: heap overflow in ffmpeg CVE-2017-5025 chromium-browser: heap overflow in ffmpeg CVE-2017-5026 chromium-browser: ui spoofing
Alerts:	openSUSE openSUSE-SU-2017:0499-1 chromium 2017-02-18 Arch Linux ASA-201702-10 ffmpeg 2017-02-12 Ubuntu USN-3180-1 oxide-qt 2017-02-08 Debian DSA-3776-1 chromium-browser 2017-01-31 Gentoo 201701-66 chromium 2017-01-29 Arch Linux ASA-201701-33 chromium 2017-01-27 Red Hat RHSA-2017:0206-01 chromium-browser 2017-01-26

Comments (none posted)

ffmpeg: two vulnerabilities

Package(s):	ffmpeg	CVE #(s):	CVE-2016-7122 CVE-2016-7450
Created:	January 30, 2017	Updated:	February 1, 2017
Description:	From the CVE entries: The avi_read_nikon function in libavformat/avidec.c in FFmpeg before 3.1.4 is vulnerable to infinite loop when it decodes an AVI file that has a crafted 'nctg' structure. (CVE-2016-7122) The ff_log2_16bit_c function in libavutil/intmath.h in FFmpeg before 3.1.4 is vulnerable to reading out-of-bounds memory when it decodes a malformed AIFF file. (CVE-2016-7450)
Alerts:	Gentoo 201701-71 ffmpeg 2017-01-29

Comments (none posted)

flatpak: sandbox escape

Package(s):	flatpak	CVE #(s):
Created:	January 30, 2017	Updated:	February 1, 2017
Description:	From the Fedora advisory: flatpak 0.8.2 release, fixing a security issue that could lead to sandbox escaping. For details, see https://github.com/flatpak/flatpak/releases/tag/0.8.2
Alerts:	Fedora FEDORA-2017-484fae685d flatpak 2017-01-30 Fedora FEDORA-2017-05e456028b flatpak 2017-01-29

Comments (none posted)

ghostscript: denial of service

Package(s):	ghostscript	CVE #(s):	CVE-2016-9601
Created:	January 30, 2017	Updated:	February 1, 2017
Description:	From the Red Hat bugzilla: A heap-buffer overflow caused by integer overflow was found in ghostscript's jbig2dec-0.13 (a decoder implementation of the JBIG2 image compression format). The vulnerability is caused by an Addition-1 integer overflow. The overflowed value is passed to function ‘malloc’ as the SIZE parameter and a buffer with zero size is allocated. Later, out-of-bound read/write can happen when accessing the buffer. Whether it’s an out-of-bound read vulnerability or out-of-bound write can be controlled by crafting the input .jb2 file. The vulnerability can cause Denial-of-Service or possibly corrupt some memory data.
Alerts:	Fedora FEDORA-2017-5136456ce3 ghostscript 2017-01-29 Fedora FEDORA-2017-15f85f1cf1 ghostscript 2017-01-29

Comments (none posted)

imagemagick: multiple vulnerabilities

Package(s):	imagemagick	CVE #(s):	CVE-2016-10144 CVE-2016-10145 CVE-2016-10146 CVE-2017-5506 CVE-2017-5507 CVE-2017-5508 CVE-2017-5510 CVE-2017-5511
Created:	January 30, 2017	Updated:	February 17, 2017
Description:	From the Debian LTS advisory: Numerous vulnerabilities were discovered in ImageMagick, an image manipulation program. Issues include memory leaks, out of bound reads and missing checks.
Alerts:	Gentoo 201702-09 imagemagick 2017-02-17 openSUSE openSUSE-SU-2017:0391-1 GraphicsMagick 2017-02-06 openSUSE openSUSE-SU-2017:0399-1 GraphicsMagick 2017-02-06 Debian-LTS DLA-807-1 imagemagick 2017-01-30

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2017-5577 CVE-2017-5576 CVE-2017-5551 CVE-2017-5548 CVE-2016-10153 CVE-2017-5547
Created:	January 31, 2017	Updated:	February 1, 2017
Description:	From the Fedora advisory: Bug #1416437 - CVE-2017-5577 kernel: vc4: Heap-buffer overflow due to failing checks. Bug #1416436 - CVE-2017-5576 kernel: vc4: Integer overflow in temporary allocation layout. Bug #1416126 - CVE-2017-5551 kernel: S_ISGD is not cleared when setting posix ACLs in tmpfs (CVE-2016-7097 incomplete fix). Bug #1416110 - CVE-2017-5548 kernel: Using stack for buffers in ieee802154. Bug #1416101 - CVE-2016-10153 kernel: introduce ceph_crypt() for in-place en/decryption. Bug #1416096 - CVE-2017-5547 kernel: DMA buffers on stack.
Alerts:	SUSE SUSE-SU-2017:0494-1 the Linux Kernel 2017-02-17 SUSE SUSE-SU-2017:0471-1 kernel 2017-02-15 SUSE SUSE-SU-2017:0464-1 kernel 2017-02-15 openSUSE openSUSE-SU-2017:0458-1 kernel 2017-02-13 openSUSE openSUSE-SU-2017:0456-1 kernel 2017-02-13 SUSE SUSE-SU-2017:0437-1 the Linux Kernel 2017-02-09 SUSE SUSE-SU-2017:0407-1 kernel 2017-02-06 SUSE SUSE-SU-2017:0333-1 kernel 2017-01-30 Fedora FEDORA-2017-6cc158c193 kernel 2017-01-30 Fedora FEDORA-2017-81fbd592d4 kernel 2017-01-30

Comments (none posted)

kernel: two vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2004-0230 CVE-2016-9685
Created:	January 31, 2017	Updated:	February 1, 2017
Description:	From the CVE entries: TCP, when using a large Window Size, makes it easier for remote attackers to guess sequence numbers and cause a denial of service (connection loss) to persistent TCP connections by repeatedly injecting a TCP RST packet, especially in protocols that use long-lived connections, such as BGP. (CVE-2004-0230) Multiple memory leaks in error paths in fs/xfs/xfs_attr_list.c in the Linux kernel before 4.5.1 allow local users to cause a denial of service (memory consumption) via crafted XFS filesystem operations. (CVE-2016-9685)
Alerts:	SUSE SUSE-SU-2017:0494-1 the Linux Kernel 2017-02-17 Ubuntu USN-3187-2 linux-ti-omap4 2017-02-09 SUSE SUSE-SU-2017:0437-1 the Linux Kernel 2017-02-09 Ubuntu USN-3187-1 kernel 2017-02-03 SUSE SUSE-SU-2017:0333-1 kernel 2017-01-30

Comments (none posted)

lib32-openssl: three vulnerabilities

Package(s):	lib32-openssl openssl	CVE #(s):	CVE-2016-7055 CVE-2017-3731 CVE-2017-3732
Created:	January 30, 2017	Updated:	February 21, 2017
Description:	From the Arch Linux advisory: - CVE-2016-7055 (incorrect calculation): There is a carry propagating bug in the Broadwell-specific Montgomery multiplication procedure that handles input lengths divisible by, but longer than 256 bits. Analysis suggests that attacks against RSA, DSA and DH private keys are impossible. This is because the subroutine in question is not used in operations with the private key itself and an input of the attacker's direct choice. Otherwise the bug can manifest itself as transient authentication and key negotiation failures or reproducible erroneous outcome of public-key operations with specially crafted input. Among EC algorithms only Brainpool P-512 curves are affected and one presumably can attack ECDH key negotiation. Impact was not analyzed in detail, because pre-requisites for attack are considered unlikely. Namely multiple clients have to choose the curve in question and the server has to share the private key among them, neither of which is default behavior. Even then only clients that chose the curve will be affected. - CVE-2017-3731 (denial of service): If an SSL/TLS server or client is running on a 32-bit host, and a specific cipher is being used, then a truncated packet can cause that server or client to perform an out-of-bounds read, usually resulting in a crash. For OpenSSL 1.1.0, the crash can be triggered when using CHACHA20/POLY1305; users should upgrade to 1.1.0d. For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users who have not disabled that algorithm should update to 1.0.2k. - CVE-2017-3732 (information disclosure): There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very similar to CVE-2015-3193 but must be treated as a separate problem.
Alerts:	Oracle ELSA-2017-0286 openssl 2017-02-20 Oracle ELSA-2017-0286 openssl 2017-02-20 openSUSE openSUSE-SU-2017:0527-1 nodejs 2017-02-21 CentOS CESA-2017:0286 openssl 2017-02-21 CentOS CESA-2017:0286 openssl 2017-02-21 Scientific Linux SLSA-2017:0286-1 openssl 2017-02-20 Red Hat RHSA-2017:0286-01 openssl 2017-02-20 openSUSE openSUSE-SU-2017:0481-1 openssl 2017-02-17 openSUSE openSUSE-SU-2017:0487-1 openssl 2017-02-17 Gentoo 201702-07 openssl 2017-02-14 Slackware SSA:2017-041-02 openssl 2017-02-10 Fedora FEDORA-2017-e853b4144f openssl 2017-02-09 Fedora FEDORA-2017-3451dbec48 openssl 2017-02-08 Mageia MGASA-2017-0042 openssl 2017-02-05 Debian-LTS DLA-814-1 openssl 2017-02-02 Ubuntu USN-3181-1 openssl 2017-01-31 Debian DSA-3773-1 openssl 2017-01-27 Arch Linux ASA-201701-37 openssl 2017-01-29 Arch Linux ASA-201701-36 lib32-openssl 2017-01-29

Comments (none posted)

libarchive: denial of service

Package(s):	libarchive	CVE #(s):	CVE-2017-5601
Created:	January 31, 2017	Updated:	February 20, 2017
Description:	From the CVE entry: An error in the lha_read_file_header_1() function (archive_read_support_format_lha.c) in libarchive 3.2.2 allows remote attackers to trigger an out-of-bounds read memory access and subsequently cause a crash via a specially crafted archive.
Alerts:	Mageia MGASA-2017-0056 libarchive 2017-02-20 Debian-LTS DLA-810-1 libarchive 2017-01-31

Comments (none posted)

libgd2: two vulnerabilities

Package(s):	libgd2	CVE #(s):	CVE-2016-10167 CVE-2016-10168
Created:	January 30, 2017	Updated:	February 1, 2017
Description:	From the Debian LTS advisory: CVE-2016-10167: Improper handling of issing image data can cause crash CVE-2016-10168: GD2 stores the number of horizontal and vertical chunks as words (i.e. 2 byte unsigned). These values are multiplied and assigned to an int when reading the image, what can cause integer overflows.
Alerts:	SUSE SUSE-SU-2017:0534-1 php7 2017-02-22 Mageia MGASA-2017-0055 libgd 2017-02-20 Slackware SSA:2017-041-03 php 2017-02-10 Fedora FEDORA-2017-f787c35494 libwmf 2017-02-10 Debian DSA-3777-1 libgd2 2017-01-31 Debian-LTS DLA-804-1 libgd2 2017-01-29

Comments (none posted)

libgd2: two vulnerabilities

Package(s):	libgd2	CVE #(s):	CVE-2016-6906 CVE-2016-10166
Created:	February 1, 2017	Updated:	February 1, 2017
Description:	From the Debian advisory: Multiple vulnerabilities have been discovered in libgd2, a library for programmatic graphics creation and manipulation, which may result in denial of service or potentially the execution of arbitrary code if a malformed file is processed.
Alerts:	SUSE SUSE-SU-2017:0534-1 php7 2017-02-22 Mageia MGASA-2017-0055 libgd 2017-02-20 Fedora FEDORA-2017-f787c35494 libwmf 2017-02-10 Debian DSA-3777-1 libgd2 2017-01-31

Comments (none posted)

libplist: two vulnerabilities

Package(s):	libplist	CVE #(s):	CVE-2017-5209 CVE-2017-5545
Created:	February 1, 2017	Updated:	February 21, 2017
Description:	From the CVE entries: The base64decode function in base64.c in libimobiledevice libplist through 1.12 allows attackers to obtain sensitive information from process memory or cause a denial of service (buffer over-read) via split encoded Apple Property List data. (CVE-2017-5209) The main function in plistutil.c in libimobiledevice libplist through 1.12 allows attackers to obtain sensitive information from process memory or cause a denial of service (buffer over-read) via Apple Property List data that is too short. (CVE-2017-5545)
Alerts:	openSUSE openSUSE-SU-2017:0528-1 libplist 2017-02-21 openSUSE openSUSE-SU-2017:0428-1 libplist 2017-02-09 Debian-LTS DLA-811-1 libplist 2017-01-31

Comments (none posted)

libtiff: information leak

Package(s):	libtiff	CVE #(s):	CVE-2015-8870
Created:	February 1, 2017	Updated:	February 1, 2017
Description:	From the CVE entry: Integer overflow in tools/bmp2tiff.c in LibTIFF before 4.0.4 allows remote attackers to cause a denial of service (heap-based buffer over-read), or possibly obtain sensitive information from process memory, via crafted width and length values in RLE4 or RLE8 data in a BMP file.
Alerts:	Scientific Linux SLSA-2017:0225-1 libtiff 2017-02-02 Oracle ELSA-2017-0225 libtiff 2017-02-01 CentOS CESA-2017:0225 libtiff 2017-02-01 CentOS CESA-2017:0225 libtiff 2017-02-01 Red Hat RHSA-2017:0225-01 libtiff 2017-02-01

Comments (none posted)

libxpm: code execution

Package(s):	libxpm	CVE #(s):	CVE-2016-10164
Created:	January 27, 2017	Updated:	February 2, 2017
Description:	From the Debian advisory: Tobias Stoeckmann discovered that the libXpm library contained two integer overflow flaws, leading to a heap out-of-bounds write, while parsing XPM extensions in a file. An attacker can provide a specially crafted XPM file that, when processed by an application using the libXpm library, would cause a denial-of-service against the application, or potentially, the execution of arbitrary code with the privileges of the user running the application.
Alerts:	Ubuntu USN-3185-1 libxpm 2017-02-01 Mageia MGASA-2017-0035 libxpm 2017-02-02 Gentoo 201701-72 libXpm 2017-01-29 Fedora FEDORA-2017-6d6e2bfd1a libXpm 2017-01-29 Debian-LTS DLA-801-1 libxpm 2017-01-26 Debian DSA-3772-1 libxpm 2017-01-26

Comments (none posted)

mbedtls: two vulnerabilities

Package(s):	mbedtls	CVE #(s):
Created:	January 30, 2017	Updated:	February 1, 2017
Description:	From the Mageia advisory: The mbedtls package has been updated to version 1.3.18, which removes a non-default configuration option that could lead to session key recovery in very long TLS sessions and fixes a potential stack corruption that cannot be triggered remotely. See the mbed TLS release announcement for details.
Alerts:	Mageia MGASA-2017-0030 mbedtls 2017-01-29

Comments (none posted)

ming: multiple vulnerabilities

Package(s):	ming	CVE #(s):	CVE-2016-9264 CVE-2016-9265 CVE-2016-9266 CVE-2016-9827 CVE-2016-9828 CVE-2016-9829 CVE-2016-9831
Created:	January 26, 2017	Updated:	February 1, 2017
Description:	From the Debian-LTS advisory: Multiple security issues have been found in Ming. They may lead to the execution of arbitrary code or causing application crash. CVE-2016-9264: global-buffer-overflow in printMP3Headers CVE-2016-9265: divide-by-zero in printMP3Headers CVE-2016-9266: left shift in listmp3.c CVE-2016-9827: listswf: heap-based buffer overflow in _iprintf CVE-2016-9828: listswf: heap-based buffer overflow in _iprintf CVE-2016-9829: listswf: NULL pointer dereference in dumpBuffer CVE-2016-9831: listswf: heap-based buffer overflow in parseSWF_RGBA
Alerts:	Debian-LTS DLA-799-1 ming 2017-01-26

Comments (none posted)

mozilla: multiple vulnerabilities

Package(s):	firefox thunderbird seamonkey	CVE #(s):	CVE-2017-5374 CVE-2017-5377 CVE-2017-5379 CVE-2017-5381 CVE-2017-5382 CVE-2017-5384 CVE-2017-5385 CVE-2017-5387 CVE-2017-5388 CVE-2017-5389 CVE-2017-5391 CVE-2017-5393
Created:	January 30, 2017	Updated:	February 1, 2017
Description:	From the Arch Linux advisory: - CVE-2017-5374 (arbitrary code execution): Several memory safety bugs have been found in Firefox < 51. Some of these bugs showed evidence of memory corruption and we presume that with enough effort that some of these could be exploited to run arbitrary code. - CVE-2017-5377 (arbitrary code execution): A memory corruption vulnerability in Skia that can occur when using transforms to make gradients, resulting in a potentially exploitable crash. - CVE-2017-5379 (arbitrary code execution): A use-after-free vulnerability has been found in Firefox < 51, in Web Animations, when interacting with cycle collection. - CVE-2017-5381 (arbitrary file overwrite): The "export" function in the Firefox < 51 Certificate Viewer can force local filesystem navigation when the "common name" in a certificate contains slashes, allowing certificate content to be saved in unsafe locations with an arbitrary filename. - CVE-2017-5382 (information disclosure): Feed preview for RSS feeds in Firefox < 51 can be used to capture errors and exceptions generated by privileged content, allowing for the exposure of internal information not meant to be seen by web content. - CVE-2017-5384 (information disclosure): Proxy Auto-Config (PAC) files in Firefox < 51 can specify a JavaScript function called for all URL requests with the full URL path which exposes more information than would be sent to the proxy itself in the case of HTTPS. Normally the Proxy Auto-Config file is specified by the user or machine owner and presumed to be non-malicious, but if a user has enabled Web Proxy Auto Detect (WPAD) this file can be served remotely. - CVE-2017-5385 (information disclosure): In Firefox < 51, data sent with in multipart channels, such as the multipart/x-mixed-replace MIME type, will ignore the referrer-policy response header, leading to potential information disclosure for sites using this header. - CVE-2017-5387 (information disclosure) The existence of a specifically requested local file can be found in Firefox < 51 due to the double firing of the onerror when the source attribute on a <track> tag refers to a file that does not exist if the source page is loaded locally. - CVE-2017-5388 (denial of service): In Firefox < 51, a STUN server in conjunction with a large number of webkitRTCPeerConnection objects can be used to send large STUN packets in a short period of time due to a lack of rate limiting being applied on e10s systems, allowing for a denial of service attack. - CVE-2017-5389 (access restriction bypass): WebExtensions in Firefox < 51 could use the mozAddonManager API by modifying the CSP headers on sites with the appropriate permissions and then using host requests to redirect script loads to a malicious site. This allows a malicious extension to then install additional extensions without explicit user permission. - CVE-2017-5391 (privilege escalation): In Firefox < 51, special about: pages used by web content, such as RSS feeds, can load privileged about: pages in an iframe. If a content- injection bug were found in one of those pages this could allow for potential privilege escalation. - CVE-2017-5393 (access restriction bypass): The mozAddonManager in Firefox < 51 allows for the installation of extensions from the CDN for addons.mozilla.org, a publicly accessible site. This could allow malicious extensions to install additional extensions from the CDN in combination with an XSS attack on Mozilla AMO sites.
Alerts:	Ubuntu USN-3175-2 firefox 2017-02-06 openSUSE openSUSE-SU-2017:0358-1 firefox 2017-02-02 Ubuntu USN-3175-1 firefox 2017-01-27 Fedora FEDORA-2017-12c3b2fec3 firefox 2017-01-29 Arch Linux ASA-201701-39 firefox 2017-01-30

Comments (none posted)

nagios: command execution

Package(s):	nagios	CVE #(s):	CVE-2014-5009
Created:	January 31, 2017	Updated:	February 1, 2017
Description:	A command-execution flaw was found in the Snoopy library included with Nagios. This flaw allowed remote attackers to execute arbitrary commands by manipulating Nagios HTTP headers.
Alerts:	Red Hat RHSA-2017:0211-01 nagios 2017-01-31 Red Hat RHSA-2017:0212-01 nagios 2017-01-31 Red Hat RHSA-2017:0213-01 nagios 2017-01-31 Red Hat RHSA-2017:0214-01 nagios 2017-01-31

Comments (none posted)

openssh: denial of service

Package(s):	openssh	CVE #(s):	CVE-2016-8858
Created:	February 1, 2017	Updated:	February 1, 2017
Description:	From the openSUSE advisory: The kex_input_kexinit function in kex.c allowed remote attackers to cause a denial of service (memory consumption) by sending many duplicate KEXINIT requests.
Alerts:	openSUSE openSUSE-SU-2017:0344-1 openssh 2017-01-31

Comments (none posted)

openssl: two vulnerabilities

Package(s):	openssl	CVE #(s):	CVE-2016-7056 CVE-2016-8610
Created:	January 30, 2017	Updated:	February 7, 2017
Description:	From the Debian advisory: CVE-2016-7056: A local timing attack was discovered against ECDSA P-256. CVE-2016-8610: It was discovered that no limit was imposed on alert packets during an SSL handshake.
Alerts:	Oracle ELSA-2017-0286 openssl 2017-02-20 Oracle ELSA-2017-0286 openssl 2017-02-20 CentOS CESA-2017:0286 openssl 2017-02-21 CentOS CESA-2017:0286 openssl 2017-02-21 Scientific Linux SLSA-2017:0286-1 openssl 2017-02-20 Mageia MGASA-2017-0053 gnutls 2017-02-20 Red Hat RHSA-2017:0286-01 openssl 2017-02-20 openSUSE openSUSE-SU-2017:0487-1 openssl 2017-02-17 Fedora FEDORA-2017-e853b4144f openssl 2017-02-09 Fedora FEDORA-2017-3451dbec48 openssl 2017-02-08 openSUSE openSUSE-SU-2017:0409-1 libressl 2017-02-07 openSUSE openSUSE-SU-2017:0386-1 gnutls 2017-02-04 Ubuntu USN-3183-1 gnutls26, gnutls28 2017-02-01 Debian-LTS DLA-814-1 openssl 2017-02-02 Ubuntu USN-3181-1 openssl 2017-01-31 SUSE SUSE-SU-2017:0348-1 gnutls 2017-02-01 SUSE SUSE-SU-2017:0304-1 gnutls 2017-01-27 Debian DSA-3773-1 openssl 2017-01-27

Comments (none posted)

puppet-swift: information disclosure

Package(s):	puppet-swift	CVE #(s):	CVE-2016-9590
Created:	January 27, 2017	Updated:	February 1, 2017
Description:	From the Red Hat advisory: An information-disclosure flaw was discovered in Red Hat OpenStack Platform director's installation of Object Storage (swift). During installation, the Puppet script responsible for deploying the service incorrectly removes and recreates the proxy-server.conf file with world-readable permissions. (CVE-2016-9590)
Alerts:	Red Hat RHSA-2017:0200-01 puppet-swift 2017-01-26

Comments (none posted)

ruby-archive-tar-minitar: file overwrites

Package(s):	ruby-archive-tar-minitar	CVE #(s):	CVE-2016-10173
Created:	January 31, 2017	Updated:	February 22, 2017
Description:	From the Debian LTS advisory: It has been found that rubygem archive-tar-minitar allows attackers to overwrite arbitrary files during archive extraction via a .. (dot dot) in an extracted filename.
Alerts:	Gentoo 201702-32 archive-tar-minitar 2017-02-22 Mageia MGASA-2017-0060 ruby-archive-tar-minitar 2017-02-20 openSUSE openSUSE-SU-2017:0429-1 rubygem-minitar 2017-02-09 Debian DSA-3778-1 ruby-archive-tar-minitar 2017-01-31 Debian-LTS DLA-808-1 ruby-archive-tar-minitar 2017-01-30

Comments (none posted)

salt: two vulnerabilities

Package(s):	salt	CVE #(s):	CVE-2017-5192 CVE-2017-5200
Created:	February 1, 2017	Updated:	February 1, 2017
Description:	From the Arch Linux advisory: - CVE-2017-5192 (arbitrary code execution): The `LocalClient.cmd_batch()` method client does not accept `external_auth` credentials and so access to it from salt-api has been removed for now. This vulnerability allows code execution for already- authenticated users and is only in effect when running salt-api as the `root` user. - CVE-2017-5200 (arbitrary command execution): Salt-api allows arbitrary command execution on a salt-master via Salt's ssh_client. Users of Salt-API and salt-ssh could execute a command on the salt master via a hole when both systems were enabled.
Alerts:	Arch Linux ASA-201701-41 salt 2017-02-01

Comments (none posted)

shadow-utils: two vulnerabilities

Package(s):	shadow-utils	CVE #(s):	CVE-2016-6251 CVE-2016-6252
Created:	January 30, 2017	Updated:	February 1, 2017
Description:	From the Mageia advisory: It was found that shadow-utils-4.2.1 had a potentially unsafe use of getlogin with the concern that the utmp entry might have a spoofed username associated with a correct uid (CVE-2016-6251). It was found that shadow-utils-4.2.1 had an incorrect integer handling problem where it looks like the int wrap is exploitable as a LPE, as the kernel is using 32bit uid's that are truncated from unsigned longs (64bit on x64) as returned by simple_strtoul() [map_write()]. (CVE-2016-6252).
Alerts:	Mageia MGASA-2017-0024 shadow-utils 2017-01-27

Comments (none posted)

tcpdump: multiple vulnerabilities

Package(s):	tcpdump	CVE #(s):	CVE-2016-7922 CVE-2016-7923 CVE-2016-7924 CVE-2016-7925 CVE-2016-7926 CVE-2016-7927 CVE-2016-7928 CVE-2016-7929 CVE-2016-7930 CVE-2016-7931 CVE-2016-7932 CVE-2016-7933 CVE-2016-7934 CVE-2016-7935 CVE-2016-7936 CVE-2016-7937 CVE-2016-7938 CVE-2016-7939 CVE-2016-7940 CVE-2016-7973 CVE-2016-7974 CVE-2016-7975 CVE-2016-7983 CVE-2016-7984 CVE-2016-7985 CVE-2016-7986 CVE-2016-7992 CVE-2016-7993 CVE-2016-8574 CVE-2016-8575 CVE-2017-5202 CVE-2017-5203 CVE-2017-5204 CVE-2017-5205 CVE-2017-5341 CVE-2017-5342 CVE-2017-5482 CVE-2017-5483 CVE-2017-5484 CVE-2017-5485 CVE-2017-5486
Created:	January 30, 2017	Updated:	February 22, 2017
Description:	From the Debian advisory: Multiple vulnerabilities have been discovered in tcpdump, a command-line network traffic analyzer. These vulnerabilities might result in denial of service or the execution of arbitrary code.
Alerts:	Ubuntu USN-3205-1 tcpdump 2017-02-21 Gentoo 201702-30 tcpdump 2017-02-21 Fedora FEDORA-2017-7ecbc90157 tcpdump 2017-02-14 Slackware SSA:2017-041-04 tcpdump 2017-02-10 Arch Linux ASA-201702-1 tcpdump 2017-02-02 Debian-LTS DLA-809-1 tcpdump 2017-01-30 Debian DSA-3775-1 tcpdump 2017-01-29

Comments (none posted)

tiff3: invalid tiff files

Package(s):	tiff3	CVE #(s):
Created:	January 30, 2017	Updated:	February 1, 2017
Description:	From the Debian LTS advisory: Version 3.9.6-11+deb7u1 and 3.9.6-11+deb7u2 introduced changes that resulted in libtiff writing out invalid tiff files when the compression scheme in use relies on codec-specific TIFF tags embedded in the image.
Alerts:	Debian-LTS DLA-610-2 tiff3 2017-01-30

Comments (none posted)

tigervnc: code execution

Package(s):	tigervnc	CVE #(s):	CVE-2017-5581
Created:	January 26, 2017	Updated:	February 21, 2017
Description:	From the openSUSE advisory: Prevent the server from overflowing a buffer in the client, causing DoS or potentially code execution.
Alerts:	Gentoo 201702-19 tigervnc 2017-02-21 openSUSE openSUSE-SU-2017:0290-1 tigervnc 2017-01-26

Comments (none posted)

virtualbox: multiple vulnerabilities

Package(s):	virtualbox	CVE #(s):	CVE-2016-5545 CVE-2017-3290 CVE-2017-3316 CVE-2017-3332
Created:	January 31, 2017	Updated:	February 14, 2017
Description:	From the CVE entries: Vulnerability in the Oracle VM VirtualBox component of Oracle Virtualization (subcomponent: GUI). Supported versions that are affected are VirtualBox prior to 5.0.32 and prior to 5.1.14. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle VM VirtualBox. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle VM VirtualBox accessible data as well as unauthorized read access to a subset of Oracle VM VirtualBox accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle VM VirtualBox. CVSS v3.0 Base Score 6.3 (Confidentiality, Integrity and Availability impacts). (CVE-2016-5545) Vulnerability in the Oracle VM VirtualBox component of Oracle Virtualization (subcomponent: Shared Folder). Supported versions that are affected are VirtualBox prior to 5.0.32 and prior to 5.1.14. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle VM VirtualBox accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox. CVSS v3.0 Base Score 7.9 (Integrity and Availability impacts). (CVE-2017-3290) Vulnerability in the Oracle VM VirtualBox component of Oracle Virtualization (subcomponent: GUI). Supported versions that are affected are VirtualBox prior to 5.0.32 and prior to 5.1.14. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise Oracle VM VirtualBox. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS v3.0 Base Score 8.4 (Confidentiality, Integrity and Availability impacts). (CVE-2017-3316) Vulnerability in the Oracle VM VirtualBox component of Oracle Virtualization (subcomponent: VirtualBox SVGA Emulation). Supported versions that are affected are VirtualBox prior to 5.0.32 and prior to 5.1.14. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle VM VirtualBox accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox. CVSS v3.0 Base Score 8.4 (Integrity and Availability impacts). (CVE-2017-3332)
Alerts:	Gentoo 201702-08 virtualbox 2017-02-14 openSUSE openSUSE-SU-2017:0382-1 virtualbox 2017-02-04 openSUSE openSUSE-SU-2017:0332-1 virtualbox 2017-01-30

Comments (none posted)

wordpress: multiple vulnerabilities

Package(s):	wordpress	CVE #(s):	CVE-2017-5610 CVE-2017-5611 CVE-2017-5612
Created:	February 1, 2017	Updated:	February 1, 2017
Description:	From the CVE entries: wp-admin/includes/class-wp-press-this.php in Press This in WordPress before 4.7.2 does not properly restrict visibility of a taxonomy-assignment user interface, which allows remote attackers to bypass intended access restrictions by reading terms. (CVE-2017-5610) SQL injection vulnerability in wp-includes/class-wp-query.php in WP_Query in WordPress before 4.7.2 allows remote attackers to execute arbitrary SQL commands by leveraging the presence of an affected plugin or theme that mishandles a crafted post type name. (CVE-2017-5611) Cross-site scripting (XSS) vulnerability in wp-admin/includes/class-wp-posts-list-table.php in the posts list table in WordPress before 4.7.2 allows remote attackers to inject arbitrary web script or HTML via a crafted excerpt. (CVE-2017-5612)
Alerts:	Debian-LTS DLA-813-1 wordpress 2017-02-01 Debian DSA-3779-1 wordpress 2017-02-01

Comments (none posted)

zoneminder: information leak, authentication bypass

Package(s):	zoneminder	CVE #(s):	CVE-2016-10140
Created:	January 30, 2017	Updated:	February 1, 2017
Description:	From the CVE entry: Information disclosure and authentication bypass vulnerability exists in the Apache HTTP Server configuration bundled with ZoneMinder v1.30.0, which allows a remote unauthenticated attacker to browse all directories in the web root, e.g., a remote unauthenticated attacker can view all CCTV images on the server.
Alerts:	Debian-LTS DLA-806-1 zoneminder 2017-01-29

Comments (none posted)

Kernel release status

The current development kernel is 4.10-rc6, released on January 29. Linus is worried that the patch activity has increased this time around. "It's still not all that big by historical standards, since 4.10 has generally been pretty calm, but it's a bit distressing. I was hoping to do the usual 'rc7 is the last rc' release schedule for once (with both 4.8 and 4.9 pushing out to rc8), and I really want things to calm down for that to happen." The codename has changed again, now it's "Fearless Coyote".

Stable updates: 4.9.6 and 4.4.45 were released on January 26. The 4.9.7 and 4.4.46 updates are in the review process as of this writing; they can be expected on or after February 2.

Comments (none posted)

Quotes of the week

— Konstantin Ryabitsev

— Ingo Molnar

Comments (none posted)

Shutting down FTP services (kernel.org)

Kernel.org has announced that it will be shutting down FTP access to its archives in two stages: March 1 will see the end of ftp.kernel.org, while December 1 is the termination date for mirrors.kernel.org.

Comments (72 posted)

Making sense of GFP_TEMPORARY

This is the season where potential topics for the upcoming Linux Storage, Filesystem, and Memory Management Summit are discussed; often that discussion resolves the relevant issues before the actual event. That would appear to be the case with the mysterious GFP_TEMPORARY memory-allocation flag. The development community now know whats it does, but now it seems that the flag itself may turn out to be a temporary thing.

Matthew Wilcox started the discussion by listing no less than nine different topics that he would like to see addressed at the summit. One of those (#8) was "nailing down exactly what GFP_TEMPORARY means". This flag was added to the 2.6.24 kernel by Mel Gorman in 2007; since then, it has picked up a few dozen users throughout the kernel. But, it seems, nobody has ever documented what the flag's effects are or when it should be used.

What the flag actually does is relatively straightforward, though it took a while for the discussion to make it clear. Vlastimil Babka described it this way:

All of this is driven by the need to defragment memory so that multiple-page allocations can be made when needed. Pages that are allocated for user-space memory are relatively easy to manage in this regard since they can be relocated elsewhere in physical memory; as long as the page-table entries are updated accordingly, the application(s) using those pages won't even be aware that they have moved. The kernel groups such pages together into regions of memory marked MIGRATE_MOVABLE in the hopes of being able to clear large contiguous areas of memory when the need arises. Keeping non-movable pages out of that area minimizes the risk of a single nailed-down page thwarting an effort to clear a range of memory.

Memory allocated for the kernel is not so easy to relocate, though, since the memory-management subsystem has no way to know where the references to any given page of memory might be or even how many of them exist. Thus, as a general rule, kernel-space memory allocations must be assumed to be eternally fixed in place; they cannot be put into the MIGRATE_MOVABLE regions. That said, some kernel-space memory has at least the possibility of being freed when memory gets tight. Memory allocated from a slab allocator with an associated shrinker callback falls into this category, for example. If this "reclaimable" memory is grouped together and kept separate from the completely unmovable memory, then there is at least a chance of freeing some usable blocks of pages when the shrinkers are run. The __GFP_RECLAIMABLE flag indicates memory that can (maybe) be reclaimed by the kernel in this way.

So GFP_TEMPORARY sets the __GFP_RECLAIMABLE flag, causing allocations to be taken from the MIGRATE_RECLAIMABLE block. That describes what the flag does, but not how it is meant to be used. After some discussion, it became evident that, in fact, nobody really seemed to know what the intended use case for GFP_TEMPORARY is.

For example, one might imagine that, from its name, GFP_TEMPORARY is intended for short-lived allocations — those that will be freed in the near future. But, Wilcox asked, what does short-lived mean in this context? Is it permissible for kernel code to block while holding a GFP_TEMPORARY allocation, for example? Or, instead, should preemption be disabled while holding that allocation? Would allocating data structures for I/O operations (which could take 30 seconds to time out) as GFP_TEMPORARY be acceptable? In other words, what are the promises that a kernel developer needs to make to perform a GFP_TEMPORARY allocation, and what benefits come from making those promises?

With regard to the acceptable time period, it turns out there is no clear answer. In the above-linked message, Babka said: "There's no simple connection to time, it depends on the larger picture". This led to complaints from developers like Neil Brown, who, understandably, thought that a name involving "temporary" would be somehow related to time. He also suggested that the whole idea is somewhat shaky, and that, if it works at all to reduce fragmentation, that is more a matter of luck. His suggestion was to look, instead, at mechanisms to render kernel-allocated objects movable so that active defragmentation could be performed. This is an interesting idea, but it is also less than trivial to implement and beyond the scope of the current discussion.

Wilcox, meanwhile, continued trying to determine the situations in which GFP_TEMPORARY should be used. It seems that it should not be used with kmalloc() calls, since the slab allocators ignore it. It is possible to hold these allocations for a considerable period of time. He suggested that there might be two possible benefits from using GFP_TEMPORARY: a higher chance of successfully allocating the memory, and making larger allocations more likely to succeed in general. Babka responded that nothing in the memory-management code makes GFP_TEMPORARY allocations more likely to succeed, but that the general benefit for larger allocations might exist.

In the end, nobody was able to come up with a simple answer to the question of when GFP_TEMPORARY should be used. So Michal Hocko concluded that perhaps it shouldn't exist at all:

Subsystems like memory management are full of heuristics intended to improve the behavior of the system. The nature of heuristics, though, tends to make their use and benefits a bit fuzzy at times, especially in the absence of focused testing (as appears to be the case here). But even ineffective heuristics can end up wired into the system to the point where nobody questions their existence. One of the good things about free-software development is that it makes it easy for fresh eyes to come in and generate awkward questions.

Comments (8 posted)

LZ4: vendoring in the kernel

In his 2017 linux.conf.au talk, Robert Lefkowitz talked about the process of "vendoring" — the copying of code from other projects into one's own repository rather than accepting a dependency on those projects. Vendoring is common in commercial projects; Android does a lot of it, for example, and Lefkowitz suggested that the practice should become more common elsewhere as well. Vendoring is not unknown elsewhere and is even done in the kernel, as a current patch set shows.

The LZ4 compression algorithm claims to be "extremely fast", especially on the decompression side. The project claims benchmark results showing LZ4 beating LZO decompression by a factor of four and zlib by nearly an order of magnitude. It is a lossless algorithm, so it is suitable for compressing data that must be recoverable in exactly its original form. Recent releases have added a "fast" mode that allows callers to control the trade-off between speed and the amount of compression applied.

One can imagine how this kind of fast compression would be useful to have in the kernel. And indeed, the kernel has had LZ4 capability since the 3.11 release in 2013. It was added by Chanho Min, who grabbed the r90 release from the LZ4 repository and stuffed it into the kernel under lib/lz4. A quick grep shows that it is currently used in the crypto layer, in the pstore subsystem, and in the squashfs filesystem. There are other places in the kernel that use compression, but they are not using LZ4 currently.

One of the advantages of copying the code into your own repository is that you are no longer dependent on an external dependency. Lefkowitz thought that independence was so valuable that he recommended copying for any dependency with less than about 35 million lines. In the kernel's case, there is an especially strong case against external dependencies: the kernel must be built as a standalone program using its complicated set of linker rules. It is probably possible to tweak the kernel's build system to allow it to link against externally supplied libraries, but one can imagine that there would be a fair amount of opposition to any such move. Kernel developers want to know exactly what is going into the end product.

The downside of vendoring, of course, is that you then lose out on all of the enhancements made in the original project. The LZ4 developers have made a number of releases since 2013; these have added numerous features, including the "LZ4 fast" mode. Some of the changes may have fixed bugs that, in the kernel, would constitute security vulnerabilities. None of those changes are in current kernels.

Toward the beginning of the year, Sven Schmidt posted a patch set updating LZ4 to the project's 1.7.2 release. The motivation was a desire to use the LZ4 fast mode in the Lustre filesystem, but he made the reasonable assumption that other parts of the kernel might want to take advantage of the fast mode as well. The patches are a wholesale replacement of the existing LZ4 code; the work initially done by Min to turn the LZ4 library into a kernel module has been replicated.

There do not appear to be any objections to upgrading the kernel's LZ4 implementation, but Greg Kroah-Hartman did note one potential problem and, in the process, highlighted one of the other hazards that go with vendoring. The existing in-kernel LZ4 implementation has not sat still since 2013; it has had a number of patches applied to it. Some of those were security fixes. When Schmidt replaced the LZ4 implementation, he replaced those fixes as well, potentially reintroducing problems that had already been fixed once.

Once his attention was called to the issue, Schmidt agreed to look at the patches and make sure that his replacement does not bring the old bugs back. With luck, he will also get any relevant changes merged back upstream, though Willy Tarreau suggested that some of the fixes, at least, were specific to the kernel. If such changes exist, they are unlikely to make it upstream and will thus be something the kernel has to carry indefinitely.

Making sure that the new LZ4 maintains the fixes applied to the old one is not a huge job; the number of patches is small. Happily, they exist as separate patches, rather than having been quietly folded into the source when LZ4 was initially added to the kernel. But it is a job that has to be remembered every time that somebody decides to update the kernel's LZ4 implementation. In this case, Kroah-Hartman noticed the problem, but the project cannot always count on his attentiveness to avoid regressions with future upgrades.

Such upgrades will almost certainly happen sooner or later. The upstream LZ4 project is already up to 1.7.6 as of this writing; it has added a new high-compression mode and fixed some bugs since 1.7.2 was released. At some point, somebody working in the kernel space will want the enhancements being made upstream.

The kernel has other copied subsystems like LZ4; they are mostly low-level compression and cryptographic code. Each one of these represents a sort of disconnect from the upstream project (in cases where there is still a functioning upstream project, at least). One could regard the highly modified kernels shipped in the mobile and embedded areas as being another example of the same thing; rather than upstream their code, these vendors simply copy it from one kernel to the next.

There are solid reasons for vendoring, but also real costs associated with it. The prevalence of vendoring throughout our community suggests that we are still struggling to find the best ways to integrate software that is created by independent groups of developers, especially as the scale of our projects continues to increase. For now, we will just have to hope that, the next time somebody decides to update a library like LZ4 in the kernel, they will remember what the old fixes are and make sure they carry over to the new version.

Comments (10 posted)

New online man pages for Debian

The announcement of a modernized version of the online Debian man pages was met with well-deserved acclaim, but also with some concerns about the development tools being used. The man pages themselves are handy and are organized by Debian release; each page provides navigation links to pages for each release and in languages other than what is set in the browser. But the use of GitHub for development and bug tracking was questioned by some.

Michael Stapelberg posted the announcement of the updated service in mid-January to the debian-devel mailing list. Instead of a CGI script, the man pages are statically generated "and therefore blazingly fast". Stapelberg implemented the debiman tool that is used to create the static web pages from the man pages in Debian packages. He also worked with the Debian system administrators to deploy the service. As described on the About page, others were instrumental in getting the service up and running as well.

The CGI-based version ran aground in August 2016 due to excessive load that was at least partly caused by traffic from robots and web spiders. Default Apache installs on Debian linked to manpages.debian.org, which apparently exacerbated the problem. That led to the creation of debiman and the new site, which can withstand much more traffic because of its static nature.

The debiman program runs regularly to pick up new packages or changes to the man pages. It takes less than ten minutes for debiman to create the whole set of pages for Debian unstable and less than fifteen seconds to do an incremental update, according to the project page. It tracks multiple Debian repositories; as Stapelberg put it:

The debiman page notes that the crontab(5) man page (seen at right) is a particularly good test case because it "is present in multiple Debian versions, multiple languages, multiple sections and multiple conflicting packages". The page for the "Jessie" (Debian 8.x) version has links to man pages for three different packages (cron, bcron-run, and systemd-cron), several different versions ("Wheezy", testing, unstable, and experimental), the crontab(1) man page, and the page in five different languages.

The response was generally quite positive. Various folks replied to offer congratulations and thanks. There were, of course, some bug reports and feature requests as well. Henrique de Moraes Holschuh asked that man pages from the contrib repository be added, since those are all freely licensed (unlike non-free). Stapelberg added an issue to the GitHub tracker, which was closed as fixed shortly thereafter.

Paul Wise posted a laundry list of suggestions and bugs, most of which were either already addressed or had new GitHub issues opened for them. But Debian has its own bug tracker, of course. Ian Jackson was concerned about the use of GitHub both for hosting the code and for bug tracking. He suggested creating a pseudopackage in the Debian bug tracker so that users can report bugs that way. He also would like to see a way to automatically get the source code from the debiman program:

Stapelberg pointed out that each of the pages has the Git revision used to generate it in the page footer ("debiman c17f615, see github.com/Debian/debiman"). That should allow anyone to check out the exact code that was run to create the page. There are some other ancillary files that need to be checked into Git, but that was already on his to-do list. He said that while he agreed with Jackson's concerns about using a proprietary service like GitHub, he was being pragmatic about it:

Even though the commit ID is available on each page, Jackson said, he would "like to be able to check out the running version without interacting with a proprietary online service". To that end, Stapelberg created a mirror of the GitHub repository for debiman and a repository for the Debian-specific pieces on Debian's infrastructure. That way, anyone who wants the source, but doesn't want to deal with GitHub, can get it.

Creating a pseudopackage for the Debian bug tracker would allow users to report bugs in debiman using that system. Stapelberg is not entirely happy with that plan, but is willing to go along:

The underlying problem is that there is no free alternative to GitHub that is as full-featured. Various posters in the thread noted that problem (including Jackson in his original response). The ease of use of GitHub, along with its widespread adoption, simply makes it far easier for new contributors to get involved. It is not at all surprising that Debian developers, in particular, would be disinclined toward GitHub, but alternatives need to arise. As Alec Leamas put it:

There was a suggestion to look at using a free version of GitLab for hosting Debian projects. The fact that there is a free version may be a sticking point, however. GitLab the company has two separate versions of its code, a community edition and closed-source enterprise edition, which is the classic "open core" model. Lars Wirzenius was not particularly interested in using GitLab because of that:

So it would seem that things have worked out amicably at this point, though it is unlikely that the GitHub question has gone away. But there are much nicer, faster man pages online and Debian users can get the source and file bugs using Debian infrastructure. The "move" to GitHub is one we are seeing recur with some frequency (e.g. for Python) and will likely see more of in the coming years. A free alternative that eventually attracts a large following is what is needed, but nothing has really reared its head at this point.

Comments (13 posted)

Distribution quote of the week

— Tails drops support i686 in the upcoming 3.0 release.

Comments (none posted)

Release for CentOS AltArch 7 (1611) on i386 Architecture

The CentOS AltArch SIG has released the latest CentOS version 7 (1611) for the i386 architecture. This release includes all packages that build on x86 32-bit processors.

Full Story (comments: none)

LEDE v17.01.0-rc1 released

The LEDE project, working on a fork of the OpenWrt router distribution, has announced its first release candidate. "With this release, the LEDE development team closes out an intense effort to modernize many parts of OpenWrt and incorporate many new modules, packages, and technologies." Click below for a terse list of changes; they include the significant WiFi performance improvements described in this article.

Full Story (comments: none)

Scientific Linux 7.3

Scientific Linux 7.3 has been released. "SL 7.3 includes updated support for Scientific Linux Contexts which should allow for ease of creating local customization for specific computing needs. Anaconda integration should be less intrusive for non-context users For more information on Scientific Linux Contexts: http://ftp.scientificlinux.org/linux/scientific/7/conte..." See the release notes for details.

Comments (none posted)

Debian BSP in Berlin

There will be a Bug Squashing Party at Endocode AG in Berlin, Germany February 25-26.

Full Story (comments: none)

Ubuntu Zesty Zapus Alpha 2 Released

Several flavors of Ubuntu have released an alpha version of Zesty Zapus (17.04), including Lubuntu, Kubuntu, Ubuntu MATE, Ubuntu Kylin, Ubuntu GNOME, and Ubuntu Budgie.

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly (January 30)
• Lunar Linux weekly news (January 27)
• openSUSE news (January 26)
• openSUSE news (February 1)
• openSUSE Tumbleweed – Review of the Week (January 27)
• Puppy Linux Newsletter (February)
• Sparky news (January 30)
• Ubuntu Weekly Newsletter (January 29)

Comments (none posted)

Best Lightweight Linux Distros for 2017 (Linux.com)

Swapnil Bhartiya picks a few lightweight distributions for a mini-review. He includes Knoppix, Lubuntu, PIXEL, Arch Linux, Remix OS, Debian, and Puppy Linux. "Debian, the mother of many popular distributions is by default a lightweight distro, as it’s system requirements are relatively low and you still get the most stable distribution on the planet. Debian uses Gnome as the default desktop environment, which can be resource hungry on some machines, but I suggest the LXDE version of Debian which brings the best of both worlds: lightweight, without compromising on quality and stability." Knoppix, Lubuntu and PIXEL are based on Debian.

Comments (none posted)

Vim's 25th anniversary and the release of Vim 8

2016 was a big year for project anniversaries. The Linux kernel, of course, turned 25. And Vim, that other iconic text editor, also celebrated its 25th anniversary. Bram Moolenaar, Vim's benevolent dictator for life, marked the occasion at the end of last year with a short note on the project's web site:

Vim's ancestry goes back even further. Vim, or "Vi IMproved", was started as a clone of the venerable vi editor, which was created by Bill Joy in 1976. Vi has its own complicated lineage: vi was the visual mode of Joy's own ex editor, which in turn can be traced back to Ken Thompson's ed editor from Bell Labs. O'Reilly's Learning the vi and Vim Editors has a complete family tree of the vi editors. Vim's 25th anniversary also coincides with the official release of version 8 on September 12, 2016. Vim 8 is the first major release since the appearance of version 7 in May 2006. Even the last point release, 7.4, was released back in August 2013.

Moolenaar happened to mark the occasion with a presentation [YouTube] at Google's Zurich office in December. He talked about the project's history as well as some of the decisions that went into the latest release. Moolenaar acknowledged he's been slow making new releases, but he believes the deliberate pace has been good for the project: "In the beginning it was easier to add new features," he said. "The further you get the harder it is to add a feature that's actually adding something... I always hesitate to add new features unless it's clear that it's good."

At last, Vim 8 has arrived. The release contains several new features, including some functionality that users have been waiting to see appear in Vim.

Packages

Managing Vim extensions used to require a separate plugin (such as pathogen) to be able to load other plugins automatically when the editor starts. Vim can now do this on its own. Users just need to move their plugins into a directory with their other configuration files. Vim 8 defines a new variable packpath, which points to $HOME/.vim/pack/*/start. This is now the default plugin directory for Vim. Plugins that use this directory structure will automatically be loaded at startup.

The introduction of packpath also includes new commands to activate plugins manually after Vim starts:

• :packadd will add a plugin from packpath
• :packloadall will load all packages under packpath

Vim 8 mirrors the directory structure many Vim users are already accustomed to. Vim 8 does not offer a package manager, but only provides the built-in framework for users to drop in their own plugins. Extensions added to the packpath folder can be managed with version control alongside the rest of a user's configuration files.

Asynchronous plugins

Vim has always been a single-threaded application, which meant that calling an external command from within Vim would block the editor for the duration of the command. While the core editor remains single-threaded, some changes have been made to allow the editor to proceed while external commands are running. Vim 8 introduces changes to its scripting language that enable communication between the core editor and other processes along with changes to start and stop those processes. Although these features are primarily of interest to plugin developers, the addition of interprocess communication and job control will have direct benefits for Vim's end users.

For example, Vim already has a built-in make command. And it's also possible to call the operating system's external make command. But both of these uses block the editor until the command finishes.

Vim 8 allows plugin developers to asynchronously execute commands in a separate process and pass the results back to Vim upon completion. Plugins that make use of the new API will no longer block Vim during long computations. For example, this means that end users can now run make or grep commands from within Vim and still be able to continue using the editor while the background job runs.

Two new additions to Vimscript make this possible. Channels allow the editor to exchange messages with other processes running in the background. Messages passed over the channels are encoded in JSON. And the job control addition can be used to start and stop background processes and communicate with running processes through channels.

Existing plugins will need to be patched to take advantage of the new features. One way to try out the new API in Vim 8 is with the new AsyncRun plugin. Just drop it into your packpath directory and you can run any shell command as a background job and still capture the output within Vim.

With Vim 8, there are now three ways to run make as an external command:

• :make

  Run Vim's built-in make. This will block the editor.

• :!make

  Run the operating system's make command. Prepending ! to a command tells Vim to run a shell command. Even though make is running in a separate process, Vim is still blocked while it waits for make to return.

• :AsyncRun make

  Use the AsyncRun external plugin to run the operating system's make command. This is new in Vim 8 and requires a plugin that takes advantage of the job control API. This is just like :!make, but now Vim doesn't have to wait for the result of make to return.

The asynchronous features are only available to plugins and do not change the core editor. Adding thread support to Vim is challenging for historical reasons, Moolenaar said in his presentation at Google: "Vim is really single threaded. Nearly all the code depends on that. Making it multi-threaded would be a really big, difficult thing with a lot of bugs. It's a lot easier if you run something in a different process and then add interprocess communication."

User demand for a multi-threaded Vim (e.g. a patch for supporting multiple threads) and its rejection is what prompted the Neovim fork in January 2014. In his presentation, Moolenaar concedes that Neovim did create some pressure to add a way to handle asynchronous jobs. Ultimately, the new feature was a compromise to give plugin authors the features they wanted without having to change Vim's fundamental design.

"Did they [Neovim] influence Vim development? A little bit. They found some bugs and fixed them and then gave them back to me," Moolenaar said in the presentation. "Of course jobs and channels are one thing where plugin authors told me 'hey this thing is something Neovim is working on and we should really have it'. I didn't take the Neovim implementation because I didn't like it that much."

A few sundry additions

Users who are new to Vim will have a better out of box experience with Vim 8. If no configuration file is present, Vim now loads a default configuration with some friendlier settings. Vim 8 now starts with vi compatibility disabled. This ensures new users will have access to Vim's extended feature set and can start using plugins right out of the box.

The default settings also include:

• Command history and auto-completion
• Enabling syntax highlighting
• Automatic file-type detection
• Saving the file position on exit

In addition to asynchronous support, Vim 8 also introduces a few other additions to the Vimscript language. Vimscript already has references to functions. Vim extends this with partials, which allow a calling function to bind the arguments for a referenced function. This can be useful for callbacks on channels, for example. Vim also introduces lambdas to allow defining anonymous functions to pass as arguments. In addition, closures are now available so that lambda functions can use the variables in the scope in which they are defined.

Users who work inside Vim with split windows can now rely on window identifiers remaining consistent when new splits are added. In Vim 8, split windows now have a unique ID separate from their window number. The graphical version of Vim now supports GTK+ 3. Users in older desktop environments should not be impacted: Vim 8 will still fallback to GTK+ 2. And Windows users have gained support for DirectX.

Anyone who has waited too long to update their computer should be aware that Vim 8 removes support for several old platforms, including MS-DOS, Windows 95, and OS/2.

Don't forget to smile

Finally, users who are burned out after a long day of hacking should try out Vim's new :smile command. (Technically, this feature was added to Vim 7.4 on the last day of 2015.) The changelog for this feature simply states that "Vim users are not always happy.", so this patch was added as a solution to that problem.

More details can be found in the full list of changes for Vim 8. Vim's built in documentation includes more detailed instructions on how to use the new features, as well as lots of information for plugin authors on changes to the scripting language. You can get Vim directly from the project web site, although the latest version has already started appearing in the package managers of many distributions.

Comments (2 posted)

Development quotes of the week

— Ben Simon

— Peter Hutterer

Comments (4 posted)

KDE Plasma 5.9 released

The KDE project has announced the release of the Plasma 5.9 desktop environment with a number of new features. "Global Menus have returned. KDE's pioneering feature to separate the menu bar from the application window allows for new user interface paradigm with either a Plasma Widget showing the menu or neatly tucked away in the window bar."

Comments (22 posted)

KDE and Slimbook Release a Laptop for KDE Fans (KDE.News)

KDE has announced a partnership with Slimbook, a Spanish laptop retailer, to create the KDE Slimbook. "The KDE Slimbook allows KDE to offer our users a laptop which has been tested directly by KDE developers, on the exact same hardware and software configuration that the users get, and where any potential hardware-related issues have already been ironed out before a new version of our software is shipped to them. This gives our users the best possible way to experience our software, as well as increasing our reach: The easier it is to get our software into users' hands, the more it will be used." The laptop is available for pre-order with systems shipping mid-March.

Comments (18 posted)

Krita 3.1.2 released

Version 3.1.2 of the Krita painting application has been released. This version features audio support for animations along with other improvements and bug fixes. "Audio is not yet available in the Linux appimages. It is an experimental feature, with no guarantee that it works correctly yet — we need your feedback!"

Comments (none posted)

LibreOffice 5.3 released

Version 5.3 of the LibreOffice office suite is out. "LibreOffice 5.3 represents a significant step forward in the evolution of the software: it offers an introduction to new features such as online with collaborative editing, which increase the competitive positioning of the application, and at the same time provides incremental improvements, to make the program more reliable, interoperable and user friendly."

Full Story (comments: 5)

Time To Upgrade Your Python: TLS v1.2 Will Soon Be Mandatory

The Python Software Foundation has announced that python.org and related sites will begin disabling the old TLS versions 1.0 and 1.1. "This change was imposed on us by our content delivery network, Fastly, in response to a change imposed on them by the Payment Card Industry Security Standards Council. In order to continue serving websites that take credit card payments, Fastly is required to disable the old, insecure versions of TLS. Since the PSF's servers, including PyPI, use Fastly, the old versions of TLS will be disabled as well."

Comments (12 posted)

Xpra 1.0

Xpra has reached its 1.0 milestone release. "Xpra used to be "just" an X11 proxy, mostly used for (re)connecting to seamless X11 sessions running on remote hosts with good compression. Since then, the project has grown a lot and it supports new modes of operations like shadowing and full desktop (VNC like). Xpra is now used by many projects for securing / segregating applications on the same host using containers or VMs." The 1.0.x branch will be supported for a minimum of 2 years.

Full Story (comments: none)

Development newsletters

• Emacs News (January 30)
• These Weeks in Firefox (January 31)
• What's cooking in git.git (January 26)
• What's cooking in git.git (January 31)
• Koha Community Newsletter (January)
• OCaml Weekly News (January 31)
• OpenStack Developer Mailing List Digest (January 27)
• Perl Weekly (January 30)
• PostgreSQL Weekly News (January 29)
• Python Weekly (January 26)
• Ruby Weekly (January 26)
• This Week in Rust (January 31)
• Wikimedia Tech News (January 30)

Comments (none posted)

How to get up and running with sweet Orange Pi (Opensource.com)

David Egts reviews the Orange Pi at Opensource.com. "Compared to a $5 Raspberry Pi Zero, the Orange Pi Zero is only a few dollars more expensive, but it is much more useful out of the box because it has onboard Internet connectivity and four CPU cores instead of one. This onboard networking capability also makes the Orange Pi Zero a better gift than a Raspberry Pi Zero because the Raspberry Pi Zero needs Micro-USB-to-USB adapters and a Wi-Fi USB adapter to connect to the Internet. When giving IoT devices as gifts, you want the recipient to enjoy the product as quickly and easily as possible, instead of giving something incomplete that will just end up on a shelf."

Comments (11 posted)

The state of Jupyter (O'Reilly)

Here's an O'Reilly article describing the Jupyter project and what it has accomplished. "Project Jupyter aims to create an ecosystem of open source tools for interactive computation and data analysis, where the direct participation of humans in the computational loop—executing code to understand a problem and iteratively refine their approach—is the primary consideration."

Comments (37 posted)

An Interview with Krita Maintainer Boudewijn Rempt (Renderosity)

Renderosity Magazine talks with Boudewijn Rempt about the Krita painting application. "Well, we make Krita for artists who want to create images. It's not an image editor with a brush engine, it's really meant for sketching, painting, illustrating. So that is what we optimize the workflow for. And people tell us that that works very well for them!"

Comments (7 posted)

Open-Sourcing Google Earth Enterprise

Google has announced that Google Earth Enterprise (GEE) will be published on GitHub under the Apache2 license in March. GEE is an enterprise product that allows developers to build and host their own private maps and 3D globes. This release includes GEE Fusion, GEE Server, and GEE Portable Server source code. "Feedback is important to us and we’ve heard from our customers that GEE remains in-use in mission-critical applications. Many customers have not transitioned to other technologies. Open-sourcing GEE allows our customer community to continue to improve and evolve the project in perpetuity. Note that the Google Earth Enterprise Client, Google Maps JavaScript® API V3 and Google Earth API will not be open sourced. The Enterprise Client will continue to be made available and updated. However, since GEE Fusion and GEE Server are being open-sourced, the imagery and terrain quadtree implementations used in these products will allow third-party developers to build viewers that can consume GEE Server Databases." (Thanks to Paul Wise)

Comments (none posted)

G.729 Consortium patents expired

Sipro reports that the patents on the G.729 audio data compression algorithm expired January 1, 2017. (Thanks to Paul Wise)

Comments (2 posted)

FSFE Newsletter - February 2017

This month the Free Software Foundation Europe newsletter covers why Open Science matters and the FSFE's position on Horizon 2020, the annual report, FSFE joins TDF, FSFE summit, and several other topics.

Full Story (comments: none)

Netdev 2.1 update

Netdev 2.1 will take place April 6-8 in Montreal, Canada. The call for papers is open until February 20. The first talk has been accepted: "Evaluating and improving kernel stack performance for datagram sockets from the perspective of RDBMS applications" by Varadhan Sowmini and Dave Tushar.

Full Story (comments: none)

Announcing JupyterCon

JupyterCon will take place August 22-25 in New York, NY. The call for speakers ends March 7. ""Project Jupyter is an effort over 15 years in the making. What began as IPython while I was a student has evolved into a cross-language platform for data science, research, and education, thanks to the tireless work of an incredible community. JupyterCon will be our first conference, an opportunity for this community to come together to learn from each other, spur new ideas and set directions for the project's future evolution. I can't wait to see what new and unexpected things are being done with these tools, and where we will go from here," says Fernando Perez, who chairs JupyterCon with Andrew Odewahn, O'Reilly's CTO."

Full Story (comments: none)

CFP Deadlines: February 2, 2017 to April 3, 2017

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

Deadline	Event Dates	Event	Location
February 6	May 8 May 11	OpenStack Summit	Boston, MA, USA
February 12	June 9 June 10	Hong Kong Open Source Conference 2017	Hong Kong, Hong Kong
February 18	March 18	Open Source Days Copenhagen	Copenhagen, Denmark
February 24	June 26 June 29	Postgres Vision	Boston, MA, USA
February 26	April 3 April 4	Power Management and Scheduling in the Linux Kernel Summit	Pisa, Italy
February 27	April 6 April 8	Netdev 2.1	Montreal, Canada
February 28	May 18 May 20	Linux Audio Conference	Saint-Etienne, France
February 28	May 2 May 4	samba eXPerience 2017	Goettingen, Germany
March 1	May 6 May 7	LinuxFest Northwest	Bellingham, WA, USA
March 4	May 31 June 2	Open Source Summit Japan	Tokyo, Japan
March 6	June 18 June 23	The Perl Conference	Washington, DC, USA
March 7	August 23 August 25	JupyterCon	New York, NY, USA
March 12	April 26	foss-north	Gothenburg, Sweden
March 15	May 13 May 14	Open Source Conference Albania 2017	Tirana, Albania
March 18	June 19 June 20	LinuxCon + ContainerCon + CloudOpen China	Beijing, China
March 20	May 4 May 6	Linuxwochen Wien 2017	Wien, Austria
March 27	July 10 July 16	SciPy 2017	Austin, TX, USA
March 28	October 23 October 24	All Things Open	Raleigh, NC, USA
March 31	June 26 June 28	Deutsche Openstack Tage 2017	München, Germany
April 1	April 22	16. Augsburger Linux-Infotag 2017	Augsburg, Germany
April 2	August 18 August 20	State of the Map	Aizuwakamatsu, Fukushima, Japan

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

Vault Linux Storage & Filesystems Conference speakers announced

The Linux Foundation has announced the speaker lineup for the Vault Linux Storage & Filesystems Conference, taking place March 22-23 in Cambridge, MA. "Facebook’s Josef Bacik, Oracle’s Martin Petersen, and Red Hat’s Rik van Riel will also give a keynote recap of the invitation-only Linux Storage, Filesystem & Memory Management Summit, which will be held directly preceding Vault in the same venue. The summit gathers foremost development and research experts and kernel subsystem maintainers to map out and implement improvements to the Linux filesystem, storage and memory management subsystems that will make their way into the mainline kernel in the coming years."

Comments (none posted)

Sumana Harihareswara's keynote will close LibrePlanet 2017

The Free Software Foundation announced that Sumana Harihareswara will be a keynote speaker at LibrePlanet (March 25-26 in Cambridge, MA). "Sumana Harihareswara first started using GNU/Linux in the late 1990s. Since then, she has contributed to a number of projects (including GNOME, MediaWiki, Zulip, and GNU Mailman), and become a leader, speaker, and advocate for free software and communities. From 2014-2015, she served as a member of the Ada Initiative Board of Directors. Within the software industry, she has been a community manager, writer, and project manager, working with Collabora, GNOME, QuestionCopyright.org, Fog Creek Software, Behavior, and Salon.com."

Comments (none posted)

Events: February 2, 2017 to April 3, 2017

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

Date(s)	Event	Location
February 2 February 3	Git Merge 2017	Brussels, Belgium
February 4 February 5	FOSDEM 2017	Brussels, Belgium
February 7 February 9	AnacondaCON	Austin, TX, USA
February 14 February 16	Open Source Leadership Summit	Lake Tahoe, CA, USA
February 15 February 16	Prague PostgreSQL Developer Day 2017	Prague, Czech Republic
February 17	Swiss Python Summit	Rapperswil, Switzerland
February 18 February 19	PyCaribbean	Bayamón, Puerto Rico, USA
February 20 February 24	OpenStack Project Teams Gathering	Atlanta, GA, USA
February 21 February 23	Embedded Linux Conference	Portland, OR, USA
February 21 February 23	OpenIoT Summit	Portland, OR, USA
March 2 March 3	PGConf India 2017	Bengaluru, India
March 2 March 5	Southern California Linux Expo	Pasadena, CA, USA
March 6 March 10	Linaro Connect	Budapest, Hungary
March 7	Icinga Camp Berlin 2017	Berlin, Germany
March 10 March 12	conf.kde.in 2017	Guwahati, Assam, India
March 11 March 12	Chemnitzer Linux-Tage	Chemnitz, Germany
March 16 March 17	IoT Summit	Santa Clara, CA, USA
March 17 March 19	MiniDebConf Curitiba 2017	Curitiba, Brazil
March 17 March 19	FOSS Asia	Singapore, Singapore
March 18	Open Source Days Copenhagen	Copenhagen, Denmark
March 18 March 19	curl up - curl meeting 2017	Nuremberg, Germany
March 20 March 21	Linux Storage, Filesystem & Memory Management Summit	Cambridge, MA, USA
March 22 March 23	Vault	Cambridge, MA, USA
March 25 March 26	LibrePlanet 2017	Cambridge, MA, USA
March 28 March 31	PGConf US 2017	Jersey City, NJ, USA

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