The technology behind elections is hard to get right. Elections require security. They also require transparency: anyone should be able to observe enough of the election process, from distribution of ballots, to the counting and canvassing of votes, to verify that the reported winners really won. But if people vote on computers or votes are tallied by computers, key steps of the election are not transparent and additional measures are needed to confirm the results.

In a New York Times op-ed a couple weeks ago, James Woolsey and Brian Fox proposed using "open-source systems that can guard our votes against manipulation." Their hypothesis is that "open-source software is less vulnerable to hacking" than proprietary voting software because "anyone can see how open-source systems operate. Bugs can be spotted and remedied, deterring those who would attempt attacks. This makes them much more secure than closed-source models." This sounds reasonable, but in fact, open-source systems are only one step towards guarding our votes against manipulationand the hypothesis that using open source software willby itselfimprove security is questionable at best.

First, with the systems in use today, there is no guarantee that the software running on any machine is in fact the software it is supposed to be running, open source or not. And even if we could know with certainty that the installed software matches the software source, the quality of the software is critical. Poorly written software, whether open source or not, creates vulnerabilities, and is thus vulnerable to hacking. Open source software allows anyone to detect vulnerabilities. We do not believe in "security through obscurity"that is, relying on secrecy as a primary security strategybut making source code available to everyone for inspection makes it available to the attackers for inspection. And the attackers are often highly motivated to find vulnerabilities.

Complicating this is the relative ease of identifying one vulnerability and the difficulty of finding them all. Attackers need to find just a single flaw in order to exploit a system. On the other hand, it is very easy for reviewers to miss somethingthe Heartbleed bug that affected millions of websites and devices in 2014 occurred in open source softwareor to make assumptions about the environment in which the source code is executed that turn out to be wrong. Software authors, maintainers, election officials, and other defenders must find every flaw, fix them all, and then distribute the fixed system (or patches) to everyone using the system.

Patch distribution creates its own set of potential problems, as it informs attackers that there was a vulnerability (and where in the code it is), leaving anyone who does not immediately install the patch especially vulnerable. For example, many years ago, a response group announced a patch to a well-known, widely used piece of software. Within thirty minutes, that vulnerability was being exploited around the world. Many sites did not have the time or resources to install the fix. The patch was announced at 5 p.m. East Coast time on a Friday, making things worse.

Open source software is a good thing. Published source, a lower bar, is a useful if less optimal alternative. But visibility of the source is not enough. Security analysts need access to everything that is used to create the system, including operating system source, driver source, compiler source, hardware, and hardware fabrication information, and then directions on how to create the systems used in the voting (such as the voting system, the tally system, and any systems and software used to display the results). Even that isn't enough, as (for example) the fabrication facilities may not follow the directions the analysts are given. The supply chain matters, toomanufacturers or their employees may even be malicious! So the analysts need to monitor the actual system construction to verify everything. Even then, they must be aware that what is done today may not be what is done tomorrow, or what was done yesterday.

Finally, even perfect software does not guarantee trustworthy elections. Trustworthiness is also a product of the way the system, and software, are used. For example, consider a system that uses a difficult-to-guess password, but that password can be found on a website. No amount of scrutiny of the system will reveal this flaw.

So assuming that open source systems are more secure than other systems is a dangerous fallacy, just as assuming closed source systems are more secure than other systems. Properly evaluating security requires more than simply considering the openness of the source.

The question we should be asking is "how can we ensure that election results are accurate when we cannot trust the computers used to run elections?" rather than "how do we make electronic voting secure?" Nothing is ever absolutely secure. But we can often make computers, systems, and processes "secure enough" for their tasks, provided we have an independent way to check the results. One technique is to produce a voter-verified paper trail, ensure that the paper trail is trustworthy, and manually audit the electronically tabulated results against the paper audit trail. Another technique called "end-to-end verifiability" allows individual voters to verify that their vote was recorded and counted correctly. Simply enabling everyone to examine the source is not sufficient, and could even give voters and election officials a belief that the system is secure when it is not.

We believe there are excellent reasons to move to open-source voting systems. For instance, there are good arguments that the public should own the voting system. Open-source systems allow vendor claims about software to be verified. Open-source systems running on commercial, off-the-shelf (COTS) hardware could be far cheaper to acquire and maintain than proprietary voting systems. Adopting open-source systems could promote a competitive market for technical support for local election officials, also decreasing costs. Open-source systems could be designed to facilitate auditing against the paper trail more efficiently than commercial systems permit. And using open-source systems would make it possible for jurisdictions to customize the software to their needs.

All this needs to be considered as we work to improve the security and transparency of our election systems. But adopting open-source systems would not by itself provide any assurance that computers used in voting are doing what they are supposed to do. Nor would it obviate the need to audit the results.

This piece reflects the contributions of the following individuals:

Matt Bishop, University of California, Davis Philip Stark, University of California, Berkeley Josh Benaloh, Microsoft Research Joseph Kiniry, Free and Fair Ron Rivest, MIT Sean Peisert, University of California, Davis Joseph Hall, Center for Democracy and Technology Vanessa Teague, University of Melbourne (Australia)

Read more:
Open-Source Software Won't Ensure Election Security - Lawfare (blog)

On a scale of one to five, how are your open source skills? If you picked a number below four, you might want to do something about it. According to the Linux Foundation's annual Open Source Jobs Report released on Wednesday, employment prospects for open source workers continues to rise.

Consider this: 86 percent of open source professionals believe that just knowing open source has advanced their careers, with 52 percent saying it would be easy to find another job. If that doesn't wet your whistle -- only 27 percent report not receiving a recruiting call in the past six months.

Open source skills have been in high demand for a number of years, as open source continues to displace proprietary software in both data centers and in development houses. Salaries for those with open source skills tend to be higher as well. Career website Dice's annual salary survey -- a separate survey from this -- indicates that Linux professionals command an annual salary of over $100,000 while other tech professionals take in an average of $92,000.

For the jobs report, the Linux Foundation and Dice partnered and in July surveyed more than 280 hiring managers from corporations, SMBs, government organizations and staffing agencies, the vast majority representing companies headquartered in North America. In addition, more than 1,800 open source professionals were surveyed, 77 percent of whom indicated three or more years spent working in open source.

According to the report, the positions employers are most seeking to fill are developer (73 percent), DevOps engineer (60 percent), and systems administrator (53 percent). The most in-demand skills are open source cloud (47 percent), application development (44 percent), big data (43 percent), DevOps (42 percent) and security (42 percent). Sixty percent of the companies surveyed said they're looking to take people on full time -- up from 53 percent last year -- and 67 percent of managers say the hiring of open source professionals will increase more than other areas of the business in the next six months.

Three major factors are pushing most companies' IT hiring plans, with company growth heading the list at 60 percent. After that, it's more open source specific, with 42 percent citing an increasing use of open source, followed by 30 percent who said that open source is becoming core to their IT needs. Interestingly, only 43 percent of hiring managers say the economy is encouraging them to take on more help, down from 57 percent in 2016. The report opines the later is potentially being caused by "rising global uncertainty."

The migration to the cloud, along with the rise of cloud-based architectures such as containers and microservices -- all areas dominated by open source -- are also a big part of the current tech job market. "Most enterprises are still in transition, making pros with skills in hybrid environments all the more valuable," the report's authors note. "Meanwhile, container technology is growing exponentially, indicating likely future shortages."

Cloud migration is also behind cloud technologies like OpenStack and Cloud Foundry being ranked as the "most sought-after area of expertise" according to 70 percent of the employers surveyed -- a number that's up from 66 percent last year. In second place is web technologies, with 67 percent of hiring managers expressing a need for those skills -- up from 62 percent last year. Demand for Linux skills is also high but has dropped a bit since last year -- from 71 percent down to 65 percent.

The report notes that among hiring managers the technologies most influencing hiring decisions are cloud (62 percent), application platforms (56 percent), and big data (53 percent); and the most in-demand open source skills are cloud/virtualization (60 percent), application development (59 percent), and DevOps (57 percent).

Employers are also increasingly seeking employees with open source certifications. Fifty percent of hiring managers said finding people with certifications is a priority, and an equal number indicated that a certified candidate has a better chance of getting a job than someone without certification -- a number that's up from 44 percent in 2016.

"And theres been a big jump in companies willing to pay for employees to become certified," the report states. "Nearly half say theyre willing to pay, up from one-third a year ago. Only 21 percent say they definitely would not pay for certifications, down from 30 percent last year."

With data centers increasing their use of open source technologies, it's not surprising that a 77 percent majority of the tech professionals surveyed said the ability to architect solutions based on open source software topped the list of valuable skills. Also important: experience with open source development tools such as GitHub, and knowledge of new tools. The pros also predict that next year, employment opportunities will grow for those with skills in cloud technologies, big data and analytics, containers, and security.

Read the original post:
Demand for Open Source Skills Continues to Grow - Windows IT Pro

The Apache Foundation recently announced that Facebook's BSD+Patents open source license has been disallowed for inclusion with Apache products. The resulting fallout has caused gnashed teeth and much soul searching for React developers and Facebook has so farrefused to reconsider.

According to Facebook, the BSD+Patents license is meant to protect them from patent trolls. Facebook's engineering director Adam Wolff explains that

As our business has become successful, we've become a larger target for meritless patent litigation. We decided to add a clear patent grant when we release software under the 3-clause BSD license, creating what has come to be known as the BSD + Patents license. The patent grant says that if you're going to use the software we've released under it, you lose the patent license from us if you sue us for patent infringement.

Facebook's statement that "if you're going to use the software we've released under it, you lose the patent license from us if you sue us for patent infringement" means that if you sue Facebook for infringement of any patent, you lose the patent grant for React. That said, patent attorney Dennis Walshargues thatthe whole issue is a "paper tiger" because, among other reasons, it's not clear there are any React-related patents or patent applications.

In adding the license to their Category X list, the Apache Foundation says that:

The Facebook BSD+Patents license includes a specification of a PATENTS file that passes along risk to downstream consumers of our software imbalanced in favor of the licensor, not the licensee, thereby violating our Apache legal policy of being a universal donor.

Apache's decision isa problem because Facebook's React library has been widely adopted by projects that also code licensed in ways the foundation approves. Developers are thusfaced with removing React.js from their projectsif they want to stay on the right side of Apache's terms. In a fierce discussion on Hacker News, user kevinflo wrote that developers contributing to React without being paid by Facebook have a "moral obligation to stop", adding that React is a "trojan horse into the open source community" to "deepen their war chest".

Raul Kripalani argues that startups should not use React because the use of React would discourage acquisitions by bigger players who may want to sue Facebook for some unrelated reason. Of course, the world is full of companies and non-profits that exist for myriad reasons and some commenters have pointed out that software patents aren't valid in their countries.

Some developers say the real issue is unethical attitude towards open source software. "This is not how open source should work," says kevinflo. Others, such as Hacker News user chrisco255, think this may all be too much:

Unless you've got millions of dollars to bring a patent suit against Facebook (do you even have any patents to defend?), this should not even be on your radar. You should be focused on building great a product and execution: not patent litigation.

"We recognize that we may lose some React community members because of this decision," Wolff writes.

Originally posted here:
Facebook Refuses to Alter React's Open Source License - InfoQ.com