The foundations behind Rust, Python, Apache, Eclipse, PHP, OpenSSL, and Blender announced plans to create "common specifications for secure software development," based on "existing open source best practices."

From the Eclipse Foundation: This collaborative effort will be hosted at the Brussels-based Eclipse Foundation [an international non-profit association] under the auspices of the Eclipse Foundation Specification Process and a new working group... Other code-hosting open source foundations, SMEs, industry players, and researchers are invited to join in as well.

The starting point for this highly technical standardisation effort will be today's existing security policies and procedures of the respective open source foundations, and similar documents describing best practices.

The governance of the working group will follow the Eclipse Foundation's usual member-led model but will be augmented by explicit representation from the open source community to ensure diversity and balance in decision-making. The deliverables will consist of one or more process specifications made available under a liberal specification copyright licence and a royalty-free patent licence... While open source communities and foundations generally adhere to and have historically established industry best practices around security, their approaches often lack alignment and comprehensive documentation.

The open source community and the broader software industry now share a common challenge: legislation has introduced an urgent need for cybersecurity process standards.
The Apache Foundation notes the working group is forming partly "to demonstrate our commitment to cooperation with and implementation of" the EU's Cyber Resilience Act. But the Eclipse Foundation adds that even before it goes into effect in 2027, they're recognizing open source software's "increasingly vital role in modern society" and an increasing need for reliability, safety, and security, so new regulations like the CRA "underscore the urgency for secure by design and robust supply chain security standards."

Their announcement adds that "It is also important to note that it is similarly necessary that these standards be developed in a manner that also includes the requirements of proprietary software development, large enterprises, vertical industries, and small and medium enterprises." But at the same time, "Today's global software infrastructure is over 80% open source... [W]hen we discuss the 'software supply chain,' we are primarily, but not exclusively, referring to open source."

"We invite you to join our collaborative effort to create specifications for secure open source development," their announcement concludes," promising initiative updates on a new mailing list. "Contribute your ideas and participate in the magic that unfolds when open source foundations, SMEs, industry leaders, and researchers combine forces to tackle big challenges."

The Python Foundation's announcement calls it a "community-driven initiative" that will have "a lasting impact on the future of cybersecurity and our shared open source communities."

Michael Larabel reports via Phoronix: With Valve's release today of the Steam Audio SDK 4.5.2 they have made the software development kit fully open-source under an Apache 2.0 license. Steam Audio 4.5.2 may not sound exciting in the context of a version number but as described in the release announcement is now "the first open source release of the Steam Audio SDK source code." The rest of this work in this Steam Audio SDK release amounts to bug fixes and other standard changes.

In a SteamCommunity.com announcement posted today entitled "Steam Audio Open Source Release," it notes: "The entire Steam Audio codebase, including both the SDK and all plugins, is now released under the Apache 2.0 license. This allows developers to use Steam Audio in commercial products, and to modify or redistribute it under their own licensing terms without having to include source code. We welcome contributions from developers who would like to fix bugs or add features to Steam Audio." You can learn more about Steam Audio via the project site.

Natives in Tech, a US-based non-profit organization, has called upon the Apache Software Foundation (ASF) to change its name, out of respect for indigenous American peoples and to live up to its own code of conduct. The Register reports: In a blog post, Natives in Tech members Adam Recvlohe, Holly Grimm, and Desiree Kane have accused the ASF of appropriating Indigenous culture for branding purposes. Citing ASF founding member Brian Behlendorf's description in the documentary "Trillions and Trillions Served" of how he wanted something more romantic than a tech term like "spider" and came up with "Apache" after seeing a documentary about Geronimo, the group said: "This frankly outdated spaghetti-Western 'romantic' presentation of a living and vibrant community as dead and gone in order to build a technology company 'for the greater good' is as ignorant as it is offensive."

And the aggrieved trio challenged the ASF to make good on its code of conduct commitment to "be careful in the words that [they] choose" by choosing a new name. The group took issue with what they said was the suggestion that the Apache tribe exists only in a past historical context, citing eight federally recognized Native American tribes that bear the name. In a statement emailed to The Register, an ASF spokesperson said, "We hear the concerns from the Native American people and are listening. As a non-profit run by volunteers, changes will need time to be carefully weighed with members, the board, and our legal team. Our members are exploring alternative ways to address it, but we don't have anything to share at this time."

The Apache Software Foundation has released a security patch to address a vulnerability in its HTTP Web Server project that has been actively exploited in the wild. From a report: Tracked as CVE-2021-41773, the vulnerability affects only Apache web servers running version 2.4.49 and occurs because of a bug in how the Apache server converts between different URL path schemes (a process called path or URI normalization). "An attacker could use a path traversal attack to map URLs to files outside the expected document root," the ASF team said in the Apache HTTP Server 2.4.50 changelog. "If files outside of the document root are not protected by 'require all denied' these requests can succeed. Additionally this flaw could leak the source of interpreted files like CGI scripts," Apache engineers added. More than 120,000 servers currently exposed online to attacks.

Frosty P writes: The Apache Software Foundation (ASF) has removed Marko Rodriguez from the TinkerPop project he co-founded because his provocative Twitter posts were said to have violated the ASF Code of Conduct. "I was removed from the project I started 11 years ago for 'publishing offensive humor that borders on hate speech,'" Rodriguez explained in an email to The Register. "However, now that Big Tech has secured the ASF board, it is a way to 'shut me up' about the monopolistic practices of Big Tech." Rodriguez argues that "woke culture" is a creation of "Big Tech," and that it serves to protect the industry's economic monopoly "by monopolizing the ideology of the people." Asked whether he sees the problem in light of the content-moderation challenge faced by social media services, which police speech without clear, consistent rules or due process, he said not at all. "I like to tweet, so I tweet. If Apache likes to police tweets, then may they police tweets," Rodriguez replied. "The question becomes: do they really like to police tweets? Are they finding as much joy in policing tweets as I find in tweeting tweets? If so, then we are both happy and the world rejoices. If not, then how can we help Apache find joy ... For joyless people ultimately impede those that do find joy in what they do." In a subsequent message he noted he has received death threats demanding he apologize for his thoughts, and that those people always assume he's a Trump supporter. "I've never voted," he said. "I simply don't care."

GitHub issued a security alert Thursday warning about new malware spreading on its site via boobytrapped Java projects, ZDNet reports: The malware, which GitHub's security team has named Octopus Scanner, has been found in projects managed using the Apache NetBeans IDE (integrated development environment), a tool used to write and compile Java applications. GitHub said it found 26 repositories uploaded on its site that contained the Octopus Scanner malware, following a tip it received from a security researcher on March 9.
But the article adds GitHub "believes that many more projects have been infected during the past two years." GitHub says that when other users would download any of the 26 projects, the malware would behave like a self-spreading virus and infect their local computers. It would scan the victim's workstation for a local NetBeans IDE installation, and proceed to burrow into the developer's other Java projects. The malware, which can run on Windows, macOS, and Linux, would then download a remote access trojan (RAT) as the final step of its infection, allowing the Octopus Scanner operator to rummage through an infected victim's computer, looking for sensitive information.

GitHub says the Octopus Scanner campaign has been going on for years, with the oldest sample of the malware being uploaded on the VirusTotal web scanner in August 2018, time during which the malware operated unimpeded.

Apache Tomcat servers released in the last 13 years are vulnerable to a bug named Ghostcat that can allow hackers to take over unpatched systems. From a report: Discovered by Chinese cybersecurity firm Chaitin Tech, Ghostcat is a flaw in the Tomcat AJP protocol. AJP stands for Apache JServ Protocol and is a performance-optimized version of the HTTP protocol in binary format. Tomcat uses AJP to exchange data with nearby Apache HTTPD web servers or other Tomcat instances. Tomcat's AJP connector is enabled by default on all Tomcat servers and listens on the server's port 8009. Chaitin researchers say they discovered a bug in AJP that can be exploited to either read or write files to a Tomcat server.

Long-time Slashdot reader Qbertino is your typical Linux/Apache/MySQL/PHP (LAMP) developer, and writes that "in recent years Docker has been the hottest thing since sliced bread." You are expected to "dockerize" your setups and be able to launch a whole string of processes to boot up various containers with databases and your primary PHP monolith with the launch of a single script. All fine and dandy this far.

However, I can't shake the notion that much of this -- especially in the context of LAMP -- seems overkill. If Apache, MariaDB/MySQL and PHP are running, getting your project or multiple projects to run is trivial. The benefits of having Docker seem negilible, especially having each project lug its own setup along. Yes, you can have your entire compiler and Continuous Integration stack with SASS, Gulp, Babel, Webpack and whatnot in one neat bundle, but that doesn't seem to dimish the usual problems with the recent bloat in frontend tooling, to the contrary....

But shouldn't tooling be standardised anyway? And shouldn't Docker then just be an option, who couldn't be bothered to have (L)AMP on their bare metal? I'm still skeptical of this Dockerization fad. I get it makes sense if you need to scale microsevices easy and fast in production, but for 'traditional' development and traditional setups, it just doesn't seem to fit all that well.

What are your experiences with using Docker in a development environment? Is Dockerization a fad or something really useful? And should I put up with the effort to make Docker a standard for my development and deployment setups?
The original submission ends with "Educated Slashdot opinions requested." So leave your best answers in the comments.

Is Dockerization a fad?

Databricks, the company founded by the original developers of the Apache Spark big data analytics engine, today announced that it has open-sourced Delta Lake, a storage layer that makes it easier to ensure data integrity as new data flows into an enterprise's data lake by bringing ACID transactions to these vast data repositories. TechCrunch reports: Delta Lake, which has long been a proprietary part of Databrick's offering, is already in production use by companies like Viacom, Edmunds, Riot Games and McGraw Hill. The tool provides the ability to enforce specific schemas (which can be changed as necessary), to create snapshots and to ingest streaming data or backfill the lake as a batch job. Delta Lake also uses the Spark engine to handle the metadata of the data lake (which by itself is often a big data problem). Over time, Databricks also plans to add an audit trail, among other things.

What's important to note here is that Delta lake runs on top of existing data lakes and is compatible with the Apache spark APIs. The company is still looking at how the project will be governed in the future. "We are still exploring different models of open source project governance, but the GitHub model is well understood and presents a good trade-off between the ability to accept contributions and governance overhead," said Ali Ghodsi, co-founder and CEO at Databricks. "One thing we know for sure is we want to foster a vibrant community, as we see this as a critical piece of technology for increasing data reliability on data lakes. This is why we chose to go with a permissive open source license model: Apache License v2, same license that Apache Spark uses." To invite this community, Databricks plans to take outside contributions, just like the Spark project.

An anonymous reader quotes a report from ZDNet: This week, the Apache Software Foundation has patched a severe vulnerability in the Apache (httpd) web server project that could --under certain circumstances-- allow rogue server scripts to execute code with root privileges and take over the underlying server. The vulnerability, tracked as CVE-2019-0211, affects Apache web server releases for Unix systems only, from 2.4.17 to 2.4.38, and was fixed this week with the release of version 2.4.39. According to the Apache team, less-privileged Apache child processes (such as CGI scripts) can execute malicious code with the privileges of the parent process. Because on most Unix systems Apache httpd runs under the root user, any threat actor who has planted a malicious CGI script on an Apache server can use CVE-2019-0211 to take over the underlying system running the Apache httpd process, and inherently control the entire machine.

"First of all, it is a LOCAL vulnerability, which means you need to have some kind of access to the server," Charles Fol, the security researcher who discovered this vulnerability told ZDNet in an interview yesterday. This means that attackers either have to register accounts with shared hosting providers or compromise existing accounts. Once this happens, the attacker only needs to upload a malicious CGI script through their rented/compromised server's control panel to take control of the hosting provider's server to plant malware or steal data from other customers who have data stored on the same machine. "The web hoster has total access to the server through the 'root' account. If one of the users successfully exploits the vulnerability I reported, he/she will get full access to the server, just like the web hoster," Fol said. "This implies read/write/delete any file/database of the other clients."

British IT news outlet The Register looks at the myriad of challenges Apache OpenOffice faces today. From the report: Last year Brett Porter, then chairman of the Apache Software Foundation, contemplated whether a proposed official blog post on the state of Apache OpenOffice (AOO) might discourage people from downloading the software due to lack of activity in the project. No such post from the software's developers surfaced. The languid pace of development at AOO, though, has been an issue since 2011 after Oracle (then patron of the project) got into a fork-fight with The Document Foundation, which created LibreOffice from the OpenOffice codebase, and asked developers backing the split to resign.

Back in 2015, Red Hat developer Christian Schaller called OpenOffice "all but dead." Assertions to that effect have continued since, alongside claims to the contrary. Almost a year ago, Jim Jagielski, a member of the Apache OpenOffice Project Management Committee, insisted things were going well and claimed there was renewed interest in the project. For all the concern about AOO, no issues have been raised recently before the Apache Foundation board to suggest ongoing difficulties. The project is due to provide an update this month, according to a spokesperson for the foundation.

An anonymous reader writes: The late Jim Weirich "was a seminal member of the western world's Ruby community," according to Ruby developer Justin Searls, who at the age of 30 took over Weirich's tools (which are used by huge sites like Hulu, Kickstarter, and Twitter). Soon Searls made a will and a succession plan for his own open-source projects. Wired calls succession "a growing concern in the open-source software community," noting developers have another option: transferring their copyrights to an open source group (for example, the Apache Foundation).

Most package-management systems have "at least an ad-hoc process for transferring control over a library," according to Wired, but they also note that "that usually depends on someone noticing that a project has been orphaned and then volunteering to adopt it." Evan Phoenix of the Ruby Gems project acknowledges that "We don't have an official policy mostly because it hasn't come up all that often. We do have an adviser council that is used to decide these types of things case by case." Searls suggests GitHub and package managers like Ruby Gems add a "dead man's switch" to their platform, which would allow programmers to automatically transfer ownership of a project or an account to someone else if the creator doesn't log in or make changes after a set period of time.
Wired also spoke to Michael Droettboom, who took over the Python library Matplotlib after John Hunter died in 2012. He points out that "Sometimes there are parts of the code that only one person understands," stressing the need for developers to also understand the code they're inheriting.

Equifax's recently departed CEO is blaming the largest data breach in history on a single person who failed to deploy a patch. TechCrunch reports: Hackers exposed the Social Security numbers, drivers licenses and other sensitive info of 143 million Americans earlier this summer by exploiting a vulnerability in Apache's Struts software, according to testimony heard today from former CEO Richard Smith. However, a patch for that vulnerability had been available for months before the breach occurred. Now several top Equifax execs are being taken to task for failing to protect the information of millions of U.S. citizens. In a live stream before the Digital Commerce and Consumer Protection subcommittee of the House Energy and Commerce committee, Smith testified the Struts vulnerability had been discussed when it was first announced by CERT on March 8th.

Smith said when he started with Equifax 12 years ago there was no one in cybersecurity. The company has poured a quarter of a billion dollars into cybersecurity in the last three years and today boasts a 225 person team. However, Smith had an interesting explainer for how this easy fix slipped by 225 people's notice -- one person didn't do their job. "The human error was that the individual who's responsible for communicating in the organization to apply the patch, did not," Smith, who did not name this individual, told the committee.

An anonymous reader writes: InfoWorld announced the winners of this year's "Best of Open Source Software Awards" -- honoring 68 different projects, spread across five categories. Besides the 15 best software development tools, they also recognized the best cloud computing software, machine learning tools, and networking and security software (as well as the best databases and analytics tools).

"Open source software isn't what it used to be," writes Doug Dineley, the site's executive editor. "The term used to conjure images of the lone developer, working into the night and through weekends, banging out line after line of code to scratch a personal itch or realize a personal vision... But as you wend your way through our Bossie winners, you're bound to be struck by the number of projects with heavyweight engineering resources behind them... Elsewhere in the open source landscape, valuable engineering resources come together in a different way -- through the shared interest of commercial software vendors."

More than 10% of the awards went to the Apache Software Foundation -- 7 of the 68 -- though I was surprised to see that five of the best software development tools are languages -- specifically Kotlin, Go, Rust, Clojure, and Typescript. Two more of the best open source software development tools were Microsoft products -- .Net Core and Visual Studio Code. And in the same category was OpenRemote a home automation platform, as well as Ethereum, which "smells and tastes like an open source project that is solving problems and serving developers."

phalse phace quotes MarketWatch: Following on the heels of a story that revealed that Equifax hired a music major with no education related to technology or security as its Chief Security Officer, Equifax announced on Friday afternoon that Chief Security Officer Susan Mauldin has quit the company along with Chief Information Officer David Webb.

Chief Information Officer David Webb and Chief Security Officer Susan Mauldin retired immediately, Equifax said in a news release that did not mention either of those executives by name. Mark Rohrwasser, who had been leading Equifax's international information-technology operations since 2016, will replace Webb and Russ Ayres, a member of Equifax's IT operation, will replace Mauldin.
The company revealed Thursday that the attackers exploited Apache Struts bug CVE-2017-5638 -- "identified and disclosed by U.S. CERT in early March 2017" -- and that they believed the unauthorized access happened from May 13 through July 30, 2017.

Thus, MarketWatch reports, Equifax "admitted that the security hole that attackers used was known in March, about two months before the company believes the breach began." And even then, Equifax didn't notice (and remove the affected web applications) until July 30.