Tag Archives: Open

GNU Linux-libre 5.2-gnu Blesses Sound Open Firmware, Cleans Other Drivers


GNU --

Following last night’s Linux 5.2 kernel release, the GNU folks maintaining their GNU Linux-libre off-shoot that de-blobs the kernel of being able to load binary-only firmware/microcode files or the ability to load binary-only kernel modules is out with their re-based kernel.

GNU Linux-libre 5.2-gnu was another busy release for them with having to keep up in cleaning the new/extended drivers that get added and working around or disabling any binary blobs they may optionally support or require. In the case of Linux 5.2, they’ve had to do some cleaning around Realtek’s new RTW88 WiFi driver that is replacing the RTLWIFI driver. They’ve also had to make changes to a number of other Realtek and Mediatek drivers among others along with adjustments for AMDGPU and Nouveau GPU binary firmware along with the Goya accelerator.

Up to now they’ve also been blocking the Sound Open Firmware (SoF) support only now to realize that in fact Intel’s open-source DSP/sound platform does meet their requirements. Sound Open Firmware was announced last year for providing more open-source firmware and is being used by all new/future Google Chromebooks. With Linux 5.2 there was a big SoF addition and now that’s cleared for working in the GNU Linux-libre 5.2 kernel.

From the Linux-libre 5.2 release announcement, “The most relevant change in this release is Sound Open Firmware support: I had not realized the SOF files were Free Software in recent earlier releases, so the requests for these files were disabled in them. Only while cleaning up the new kernel module specifically devoted to SOF-supporting devices did I realize my mistake. I look forward to the day when assuming a firmware name is a blob is no longer a safe bet.

Linux 5.2 does bring many new/improved features most of which should work in the Linux-libre spin.


GitHub Opens New Door to Financial Support for Open Source Devs | Developers


By Jack M. Germain

May 29, 2019 10:29 AM PT

GitHub has made it easier for open source developers to garner financial support as recipients of paid sponsorships.

GitHub Opens New Door to Financial Support for Open Source Devs

GitHub Sponsors, launched in beta last week, is a new funding mechanism that enables open source users to make recurring payments, much like crowdfunding services such as
Patreon and managed open source subscription services backed by creators and maintainers, like
Tidelift.

GitHub also launched the GitHub Sponsors Matching Fund to boost community funding efforts. Under this companion program, GitHub will match all contributions up to US$5,000 during a developer’s first year in GitHub Sponsors.

Microsoft last year bought GitHub for $7.5 billion. GitHub is the online home of thousands of open source software projects that power apps and sites ranging from Facebook to Walmart.com.

Both open source maintainers and enterprise development teams will benefit from the new funding initiatives, according to Donald Fischer, CEO of Tidelift.

“Open source maintainers will be clear and deserving beneficiaries of [these] initiatives,” he told LinuxInsider. “Enterprise development teams, which use open source packages in well over 90 percent of their new applications today, also win because they’ll save time and be exposed to less risk when packages are secured and licensed to professional standards.”

Perhaps less obvious — and more broadly relevant — is that all technology users will benefit, since the entire digital infrastructure now runs on open source, Fischer added.
“We will ALL benefit when maintainers are getting paid for keeping their projects secure and well maintained.”

How Sponsoring Devs Works

The beta test for the sponsorship program is open to anyone, including people who work on documentation or other nontechnical aspects of software projects. The new program allows the developer community to provide financial support directly to GitHub people who design, build and maintain the open source projects most important to them.

Developers will be able to set up multiple sponsorship tiers with benefits they can set, according to GitHub. This process is similar to sponsorships available elsewhere, with monthly payments and special benefits depending on how much sponsors pay, including projects that already integrate with GitHub, like
Beerpay.

Payouts will be available in every country where GitHub does business. The core mission for GitHub is to expand opportunities to participate in supporting open source developers, the company said.

Details about how to become a sponsor are
available here.

“Efforts like Github Sponsors are very complementary to the mission and work of open source foundations like the Fintech Open Source Foundation, and others like Linux Foundation and Apache,” said FINOS Executive Director Gabriele Columbro.

Early stage open source projects need angel and pre-seed money just like startups, he told LinuxInsider, noting that programs like GitHub Sponsors will be a great way to help get maintainers of open source projects the money they need — especially for their initial incubation.

“Of course, this is until they may be ready to take advantage of shared services, cooperative technical and tooling platforms, and types of developer communities that open source foundations provide to projects ready to scale,” said Columbro.

Could Spark Controversy

Some open source developers do not want financial interests to influence what projects developers choose Sponsorship programs such as this one may heighten concerns that open source developers will focus on projects that are more likely to attract financial contributions instead of esoteric projects that are interesting and challenging, but are not likely to find financial backers on GitHub.

“This has traditionally been an issue for charity-based funding approaches, and it is a place where the Tidelift Subscription model really shines and separates itself,” Fischer said.

Rather than limiting funding to popular open source projects, subscription revenue filters down to the maintainers of ALL packages in a subscriber’s dependency graph, he explained.

“So rather than just funding a few well-known maintainers, you fund the maintainers of all of the packages you use,” Fischer said.

GitHub might push companies to support open source projects they’re dependent on, suggested software developer
Miguel Piedrafita.

“One downside I think we should not forget is that GitHub is becoming a monopoly. With private repositories, the new package manager, and now a way to support creators, [GitHub is] trying to become indispensable, and I don’t think that’s a good thing,” he told LinuxInsider.

Hoping for Widespread Appeal

The sponsorship program is only open to open source developers. For the next twelve months, GitHub will waive any payment processing fees.

More is involved than just paying developers to maintain their code. The sponsorship program impacts all open source contributors, including those who write documentation, provide leadership or mentor new developers.

The only requirement to receive support is that the software parties have a GitHub profile.

To make this program work, GitHub also has launched a Community Contributors hovercard to highlight the people who built the code on which applications depend.

This approach will not eliminate a traditional method of getting paid to write open source code. Sponsorship opens another avenue beyond having to find a job at a company that lets an employee contribute to open source projects, either as a full-time or part-time job.

Sponsors will enable code writers to raise money within GitHub. Anyone can apply for sponsorship during the beta period.

Earnings Timeline

Most likely, developers with an existing following or active involvement within their respective communities could see the most benefit within the first 12 months. A developer with visibility who provides quality contributions could see short-term gains more quickly than a developer who contributes only every once in a while, according to Willem Luijt, LEAD backend developer at
Endertech.

“Since GitHub is giving 100 percent of the sponsorship — including covering payment processor fees — during this initial 12-month period, open source developers who choose to promote themselves within their communities could receive slightly more funding before having to account for fees as this program goes on,” he told LinuxInsider. “But as this sponsorship should be considered more of a tip jar than a source of primary income, any little bit helps.”

One downside could be when an individual developer decides not to contribute to another’s project without being sponsored, Luijt cautioned. While that may not be the case for any particular community or specific individuals, there is always the possibility that someone could act singularly to choose this path in the future.

“The nature of open source is sharing,” he pointed out, “and many developers who contribute to open source may care too much about their community and work to go against the good they are doing. So this should be a rare occurrence.”


Jack M. Germain has been an ECT News Network reporter since 2003. His main areas of focus are enterprise IT, Linux and open source technologies. He has written numerous reviews of Linux distros and other open source software.
Email Jack.





Source link

Open Source Flaw Management Shows Signs of Improvement: Report | Software


By Jack M. Germain

Apr 30, 2019 1:16 PM PT

Almost two years after the infamous
Equifax breach, many organizations still struggle to identify and manage open source risk across their application portfolios.

Meanwhile, the latest report tracking open source security shows a 40 percent rise in the average number of open source components detected in each codebase analyzed. The scanned software includes commercial applications.

Black Duck by Synopsys on Tuesday released its annual Open Source Security and Risk Analysis, which examines the open source audit results of scanned codebases to identify insightful trends and patterns in open source usage. The report also looks at the prevalence of insecure open source components and software license risk.

Titled “Understanding Open Source Risk and Why It’s So Important to Manage,” the report compiles research backed by the
Synopsys Cybersecurity Research Center (CyRC). It provides an in-depth look at the state of open source security, license compliance and code-quality risk in commercial software.

The CyRC Belfast team examined findings from the anonymized data of more than 1,200 commercial codebases reviewed by the Black Duck Audit Services team in 2018. The 17 industries represented in the report range from aerospace to virtual reality. The audit services team reviewed an average of 71 codebases per industry during 2018.

The continued growth of open source components in commercial codebases is mitigated by the report’s finding that many of open source vulnerabilities detected were first disclosed more than a decade ago.

The percentage of codebases containing vulnerable components has decreased, the report notes. The percentage of codebases containing license conflicts also has decreased.

The least surprising trend identified is that open source adoption has continued to rise, and the majority of codebases contain more open source than proprietary code, according to Tim Mackey, senior technical evangelist at Synopsys.

“One trend that is concerning is that the majority of codebases (60 percent) contain at least one vulnerable open source component, and 40 percent contain at least one high-risk vulnerability. Similarly, open source license compliance continues to be a challenge, with 68 percent of codebases containing some form of open source license conflict,” he told LinuxInsider.

Results Highlights

Audits found open source in more than 96 percent of codebases scanned in 2018. That percentage is similar to the figures from the last two OSSRA reports.

Most of the codebases that contained no open source consisted of fewer than 1,000 files. More than 99 percent of the codebases scanned in 2018 with more than 1,000 files contained open source components.

In most industries, the year-to-year difference in the percentage of codebases containing open source was negligible, according to the report. The audited codebases generally were from companies whose business is building software rather than from enterprises for whom software supports their main business.

The audits found, on average, 298 open source components per codebase in 2018 versus 257 in 2017. Open source represented 60 percent of the code analyzed in 2018, up from 57 percent in 2017.

“The main takeaway from this report is that the security and license compliance risk associated with the use of open source is very real, but it is the risk that can be managed with a proactive open source governance policy, automated tools like software composition analysis and an effective patching strategy,” said Mackey.

Encouraging Indications

This year’s report shows signs of an improving situation. There definitely are encouraging data points suggesting the industry may be turning the corner in terms of organizations’ ability to manage open source risk, noted Mackey.

For example, while 60 percent of codebases contained at least one vulnerable open source component, that number is down significantly from the 78 percent observed in the 2018 OSSRA report, he said. Likewise, the 68 percent of codebases containing some form of open source license conflict is slightly better than the 74 percent seen in last year’s report.

“This is a good thing, as it shows how teams are continuing to leverage open source to accelerate innovation,” Mackey observed, “but more open source also means more open source risk that needs to be managed.”

Enterprise IT and corporate security workers should not be concerned that the rise in open source code may create greater security risks, suggested Tobie Langel, principal at consulting firm
UnlockOpen.

“There is no reason to believe that open source software is inherently less secure than closed source software,” he told LinuxInsider. “However, when a security issue is found in open source software that is used across the industry, the impact can be greater, as it is ubiquitous.”

Sustaining and securing open source is the industry’s biggest challenge right now — but open source also is where the most innovation is happening.

“I am confident we will get there,” Langel said. “Open source is by far the most effective means of building software and innovating at scale, once we find the right set of solutions to provide long term maintenance. It will also be the most secure solution by far.

Common Code Risk Critical

Numerous components were commonly used across different codebases, researchers found. For example, jQuery, open source software using the permissive MIT License, was found in 56 percent of the scanned codebases and in virtually every industry covered in the OSSRA report.

Other notable open source components found in the scans include Bootstrap, an open source front-end Web framework; jQuery UI, a curated set of user interface interactions, effects, widgets and themes built on the jQuery JavaScript Library; and Font Awesome, an open source font and icon toolkit based on CSS and LESS.

Despite using so much open source, few companies accurately track the components they use in their code. Most lack the policies, processes and tools to keep up with the choices made by their developers, according to the report. As a consequence, all the good functionality that comes with open source also brings along a variety of risks.

“Open source libraries are a double-edged sword,” remarked Manish Gupta, CEO of
ShiftLeft.

Widely used open source software tools are generally more stable and more robust than custom code, he told LinuxInsider, because they are deployed in a variety of environments and have been battle-tested.

Bugs and vulnerabilities potentially are reported and fixed much faster than in custom-code that is leveraged by only one organization. However, the documented system of CVEs means that attackers know how your libraries are vulnerable, Gupta cautioned, and they can create an exploit much more easily.

“This means that consumers of OSS must stay on top of patches, which is not always easy to do,” he said. “The security industry hasn’t provided effective solutions to the developers to deal with this dilemma. The tools merely tell developers which OSS libraries being used are vulnerable.”

Clarifying Risk From Use

A key takeaway in the report is the care it takes not to mischaracterize the findings as an attack on the use of open source technology itself. Open source is not less secure than proprietary code. Nor is it more secure.

All software has weaknesses that are potential vulnerabilities, whether the code is proprietary or open source, the report warns. Organizations that use open source must identify and patch.

That management process is challenging, since most organizations have thousands of different pieces of software, ranging from mobile apps to cloud-based systems to legacy systems running on-premises. Software in general is a mix of commercial off-the-shelf packages, open source software and custom-built codebases — and vulnerabilities affect all of them, the report emphasizes.

“The use of any software comes with inherent risks, but open source software presents a few unique challenges,” said Mackey.

The first challenge concerns license obligations that can be opaque and easy to overlook compared to commercial software. The second challenge is the responsibility for identifying and patching open source security vulnerabilities, which falls solely on the organization using the software.

“Commercial software vendors can proactively urge, or in some cases, force their customers to update or apply security patches,” Mackey said. “Managing open source security and license risk should be viewed as an accepted cost of otherwise free open source software.”

Attack Vectors Persistent

An alarming number of companies fail to patch the software they use, whether proprietary or open source, the report said. That makes them targets.

Unpatched software vulnerabilities are one of the biggest cyberthreats organizations face. Unpatched open source components in software add to security risk. Certain characteristics of open source make vulnerabilities in popular components attractive to attackers.

Makers of commercial software can push fixes, patches and updates to users automatically. Open source has a pull support model. That makes the users responsible for keeping track of both vulnerabilities and fixes for the open source software they use.

The pervasiveness and ubiquity of open source pose management tasks that extend far beyond many organizations’ capabilities, as they do not do manual tracking of components, their versions and their vulnerabilities, according to the report.

Assistance Required

Organizations using open source must establish management strategies to identify and patch known vulnerabilities in open source components, notes the report. Vulnerabilities are disclosed through sources such as the National Vulnerability Database (NVD), mailing lists, GitHub issues and project homepages.

The widespread use of open source makes it imperative for organizations to keep accurate, comprehensive and up-to-date inventories of the open source components used in their applications. An incomplete inventory makes it extremely difficult to maintain adequate software asset management procedures, according to the report.

The increase in open source vulnerability age, despite a decrease in the number of codebases containing open source vulnerabilities, is interesting, said Synopsys’ Mackey, “but our audits often reveal that organizations are tracking less than half the open source in use. You can’t patch what you aren’t aware of.”

Sample Solutions

One solution for organizations using open source code is to tap into readily available sources tracking vulnerabilities, suggested Gabriel Bianconi, founder of
Scalar Research.

“Large projects often have mailing lists announcing bug fixes and vulnerabilities,” he told LinuxInsider. “There are several vendors providing software to monitor security risks in open source libraries and dependencies used by your company.”

More often than not, the biggest problem is that the company is using an outdated version of the codebase that does not contain the latest security patches.

“Professionals must ensure that their dependencies are consistently updated,” Bianconi said.

Breaking Breaches

“POODLE,” “Heartbleed” and “Spectre” are not just cute monikers for security vulnerabilities. They are very real and potentially dangerous holes, noted Steve Tcherchian, chief product officer at
XYPRO.

When an application vulnerability is identified, it typically is followed by a patch or new version to remediate the vulnerability, he explained, and with the proliferation of free and open source software, this activity becomes critically important.

“Oftentimes procrastination takes over, and the application is not timely patched for a variety of reasons,” Tcherchian told LinuxInsider. “This now leaves the application wide open to a published, and in most cases, publicized vulnerability.”

As for how to change the mentality within a development organization to be more security-focused, education and reinforcement are key, Tcherchian said.

“Security cannot be left for the end. Introduce security into your development processes early and re-introduce them often,” he added.

More Action Needed

The report cites a conclusion by the U.S. Senate Permanent Subcommittee on Investigations declaring that Equifax’s lack of a complete software inventory was a contributing factor to its massive 2017 data breach.

A number of reliable strategies exist to ensure that open source components used in applications are up-to-date with crucial patches applied, noted Matt Wilson, chief information security advisor at
BTB Security.

“The good news is that they aren’t terribly complicated. What is important is that teams are aware of what you run in your environment, which can be hard for less mature organizations,” he told LinuxInsider.

The process involves maintaining awareness of updates to the code you run, applying patches as quickly as possible, and ensuring you conduct regular testing of your application/environment as a catch-all, Wilson explained.

Several industries, such as government, healthcare and automotive, have started to adopt standards that require organizations to inventory and track their use of open source components in a software bill of materials, according to Synopsys’ Mackey.

“This is a good first step,” he said. “After all, you can’t manage risk you don’t know exists.”


Jack M. Germain has been an ECT News Network reporter since 2003. His main areas of focus are enterprise IT, Linux and open source technologies. He has written numerous reviews of Linux distros and other open source software.
Email Jack.





Source link

Black Hole Image Has an Open Source Connection » Linux Magazine


Last week the whole world was stunned by seeing what was unseen – a black hole. Scientists were able to create picture of a black hole named Messier 87 in the Virgo A galaxy. The black hole is more than 55 million light years away.

The first image of a black hole is the outcome of the Event Horizon Telescope (EHT) project, which created a virtual telescope as big as earth by networking 8 ground-based telescopes. The telescopes generated more than five petabyte of data. Collecting data was the first part of the puzzle. The team of scientists used various algorithms to fill gaps in this data to be able to generate an image of the black hole.

TFIR reports that the team of scientists used three imaging algorithm for image processing, and two of these were fully open source Python libraries – Sparselab and ehtim.

Sparselab is a Python Library for Interferometric Imaging using Sparse Modeling.

ehtim is a Python module for simulating and manipulating VLBI data and producing images with regularized maximum likelihood methods.

The source code of these libraries is published on GitHub under GNU GPLv3 licenses.



Source link

Chef Goes All Open Source » Linux Magazine


The Chef automation tool, a popular solution for DevOps IT management scenarios, has announced that it will be become a 100% open source platform. In the past, the basic Chef application was available in open source form, but the company also provided several enhancements and add-on tools with proprietary licenses. Rather than building proprietary tools around an open source core, Chef will now open source all of its software under an Apache 2.0 license.

According to Chef CEO Barry Crist, “Over the years we have experimented with and learned from a variety of different open source, community, and commercial models, in search of the right balance. We believe that this change, and the way we have made it, best aligns the objectives of our communities with our own business objectives. Now we can focus all of our investment and energy on building the best possible products in the best possible way for our community without having to choose between what is “proprietary” and what is “in the commons.”

This move toward free software does not mean that Chef is changing its focus on commercial enterprise customers. Instead, the change underscores the modern reality that the enterprise is more about services than it is about code. The company has also announced a commercial version called Chef Enterprise Automation Stack that will combine the open-source software with enterprise-grade warranties, indemnifications, and support.



Source link