The U.S. Cybersecurity and Infrastructure Security Agency (CISA) will start providing more hands-on support to open-source software developers as they work to better secure their projects, the agency said. From a report: CISA hosted a two-day, invite-only summit this week with leaders in the open-source software community and other federal officials. During the private event, the agency also ran what's likely the first tabletop exercise to assess how well the government and the open-source community would respond to a cyberattack targeting one of their projects.

During the summit, CISA and a handful of package repositories unveiled new initiatives to help secure open-source projects. CISA is working on a new communication channel where open-source software developers can share threat intelligence and ask the agency for assistance during an incident. The Rust Foundation is developing new public key infrastructure for its repository, which will help ensure that the code developers are uploading isn't malicious and is coming from legitimate users.

npm, which manages the JavaScript programming language, is requiring project maintainers to enroll in multi-factor authentication and is rolling out a tool to generate "software bills of materials," which provide a recipe list of what code and other elements are in a project. Additional repositories -- including the Python Software Foundation, Packagist, Composer and Maven Central -- are pursuing similar projects and also also rolling out tools to help detect and report malware and other security vulnerabilities.

The cybersecurity site SC Media reports that NPM registry users "download deprecated packages an estimated 2.1 billion times weekly, according to a statistical analysis of the top 50,000 most-downloaded packages in the registry." Deprecated, archived and "orphaned" NPM packages can contain unpatched and/or unreported vulnerabilities that pose a risk to the projects that depend on them, warned the researchers from Aqua Security's Team Nautilus, who published their findings in a blog post on Sunday... In conjunction with their research, Aqua Nautilus has released an open-source tool that can help developers identify deprecated dependencies in their projects.

Open-source software may stop receiving updates for a variety of reasons, and it is up to developers/maintainers to communicate this maintenance status to users. As the researchers pointed out, not all developers are transparent about potential risks to users who download or depend on their outdated NPM packages. Aqua Nautilus researchers kicked off their analysis after finding that one open-source software maintainer responded to a report about a vulnerability Nautilus discovered by archiving the vulnerable repository the same day. By archiving the repository without fixing the security flaw or assigning it a CVE, the owner leaves developers of dependent projects in the dark about the risks, the researchers said...

Taking into consideration both deprecated packages and active packages that have a direct dependency on deprecated projects, the researchers found about 4,100 (8.2%) of the top 50,000 most-downloaded NPM packages fell under the category of "official" deprecation. However, adding archived repositories to the definition of "deprecated" increased the number of packages affected by deprecation and deprecated dependencies to 6,400 (12.8%)... Including packages with linked repositories that are shown as unavailable (404 error) on GitHub increases the deprecation rate to 15% (7,500 packages), according to the Nautilus analysis. Encompassing packages without any linked repository brings the final number of deprecated packages to 10,600, or 21.2% of the top 50,000. Team Nautilus estimated that under this broader understanding of package deprecation, about 2.1 billion downloads of deprecated packages are made on the NPM registry weekly.

"A recent analysis accounting for nearly 1.2 million open source software projects primarily across four major ecosystems found that only about 11% of projects were actively maintained," reports InfoWorld: In its 9th Annual State of the Software Supply Chain report, published October 3, software supply chain management company Sonatype assessed 1,176,407 projects and reported an 18% decline this year in actively maintained projects. Just 11% of projects — 118,028 — were receiving active maintenance.

The report also found some new projects, unmaintained in 2022, now being maintained.

The four ecosystems included JavaScript, via NPM; Java, via the Maven project management tool; Python, via the PyPI package index; and .NET, through the NuGet gallery. Some Go projects also were included. According to the report, 18.6% of Java and JavaScript projects that were being maintained in 2022 are no longer being maintained today.
Other interesting findings:

• Nearly 10% reported security breaches due to open source vulnerabilities in the past 12 months.

• Use of AI and machine learning software components within corporate environments surged 135% over the last year.

On Saturday PyPI, the official third-party registry of open source Python packages, "temporarily suspended new users from signing up, and new projects from being uploaded to the platform" reports BleepingComputer.

"The volume of malicious users and malicious projects being created on the index in the past week has outpaced our ability to respond to it in a timely fashion, especially with multiple PyPI administrators on leave," stated an incident notice posted by PyPI admins Saturday.

Hours ago they posted a four-word update: "Suspension has been lifted." No details were provided, but The Hacker News writes the incident "comes as software registries such as PyPI have proven time and time again to be a popular target for attackers looking to poison the software supply chain and compromise developer environments." Earlier this week, Israeli cybersecurity startup Phylum uncovered an active malware campaign that leverages OpenAI ChatGPT-themed lures to bait developers into downloading a malicious Python module capable of stealing clipboard content in order to hijack cryptocurrency transactions. ReversingLabs, in a similar discovery, identified multiple npm packages named nodejs-encrypt-agent and nodejs-cookie-proxy-agent in the npm repository that drops a trojan called TurkoRat.

Veteran open source report Steven J. Vaughan-Nichols, writing at The Register: We can all agree that securing our software is a good thing. Thanks to one security fiasco after another -- the SolarWinds software supply chain attack, the perpetual Log4j vulnerability, and the npm maintainer protest code gone wrong -- we know we must secure our code. But the European Union's proposed Cyber Resilience Act (CRA) goes way, way too far in trying to regulate software security. At the top level, it looks good. Brussels states that before "products with digital elements" are allowed on the EU market, manufacturers must follow best practices in four areas. Secure the product over its whole life; follow a coherent cybersecurity framework; show cybersecurity transparency; and ensure customers can use products securely. Sounds great, doesn't it? But the road to hell is paved with good intentions. The devil, as always, is in the details. Some of this has nothing to do with open source software. Good luck creating any program in any way that a clueless user can't screw up.

But the EU commissioners don't have a clue about how open source software works. Or, frankly, what it is. They think that open source is the same as proprietary software with a single company behind it that's responsible for the work and then monetizes it. Nope. Open source, as I've said over and over again, is not a business model. Sure, you can build businesses around it. Who doesn't these days? But just as the AWSes, Googles, and Facebooks of the world depend on open source software, they also use programs written by Tom, Denise, and Harry from around the world. The CRA's underlying assumption is that you can just add security to software, like adding a new color option to your car's paint job. We wish!

Securing software is a long, painful process. Many open source developers have neither the revenue nor resources to secure their programs to a government standard. The notional open source developer in Nebraska, thanklessly maintaining a vital small program, may not even know where Brussels is (it's in Belgium). They can't afford to secure their software to meet EU specifications. They often have no revenue. They certainly have no control over who uses their software. It's open source, for pity's sake! As open source developer Thomas Depierre recently blogged: "We are not suppliers. All the people writing and maintaining these projects, we are not suppliers. We do not have a business relationship with all these organizations. We are volunteers, writing code and putting it online under these Licenses." Exactly.

Gabi Dobocan, writing at auditing firm Sandworm: More than half of all new packages that are currently (29 Mar 2023) being submitted to npm are SEO spam. That is - empty packages, with just a single README file that contains links to various malicious websites. Out of the ~320k new npm packages or versions that Sandworm has scanned over the past week, at least ~185k were labeled as SEO spam. Just in the last hour as of writing this article, 1583 new e-book spam packages have been published. All the identified spam packages are currently live on npmjs.com.

An anonymous reader shares a report: Socket has found a way to protect developers from npm, GitHub's insufficiently safe JavaScript package manager, by wrapping it in a security blanket. The npm registry, operated by NPM until the security biz was acquired by Microsoft's GitHub in 2020, hosts software packages for the JavaScript ecosystem. It is, by its own account, "the world's largest software registry." In the past few years, the maliciously inclined have increasingly focused on compromising package registries like npm in what's known as a supply chain attack. Subverting a popular software library has the potential to enable widespread viral distribution. Those running the npm registry have put in place various defenses over the years, such as npm audit, a vulnerability scanning command in the npm command line interface (CLI). But the tool's implementation leaves something to be desired and developers often ignore audit warning messages, particularly if automated resolution doesn't work.

Socket built its own vulnerability scanning system and last year made it available for free (with paid tiers for teams and organizations) for open source projects. Its scanner runs as a GitHub app on code repositories when changes are made. It catches more issues than npm audit -- covering not just supply chain risk but also quality, maintenance, vulnerability, and license concerns. But Socket's scanner is also now available as a CLI that developers can install on their machines. On Thursday, Socket updated its CLI with a safe npm command that defends developers whenever they invoke npm install or npm uninstall, which perversely can install packages amid removing others. "npm creates what is called the 'ideal tree' for a given package.json," explained Feross Aboukhadijeh, told The Register. "So by removing a package you might actually change what the ideal tree is. Removing a package may remove a constraint which is keeping a package on an older version, so then npm may update those packages to a more ideal/recent version."

74.48% of developers use Microsoft's Visual Studio Code, according to one survey conducted by StackOverflow. And besides GitHub Copilot, there's over 40,000 other extensions in the VSCode Marketplace.

Unfortunately, InfoWorld reports, "Researchers at Aqua Nautilus say they have found that attackers could easily impersonate popular extensions and trick unknowing developers into downloading them." It can be challenging to distinguish between malicious and benign extensions, and the lack of sandbox capabilities means that extensions could install ransomware, wipers, and other malicious code, Aqua security researcher Ilay Goldman wrote in a January 6 blog post. ["In fact, it can access and even alter all the code that you have locally and even use your SSH key to change the code in all your organization's repositories."] VS Code extensions, which provide capabilities ranging from Python language support to JSON file editing, can be downloaded from Microsoft's Visual Studio Code Marketplace.

Aqua Nautilus uploaded an extension masquerading as the Prettier code formatter and saw more than 1,000 installs in less than 48 hours, from around the world. The spoof extension has been removed.

Goldman noted that the Visual Studio Code Marketplace runs a virus scan for each new extension and subsequent updates, and removes malicious extensions when it finds them. Users can report suspicious-looking extensions via a Report Abuse link.
"While the media is full of stories about malicious packages that have been uploaded to popular package managers such as NPM and PyPI, there is very little information about malicious VSCode extension," the blog post notes. Yet it points out that a blue checkmark on a VSCode extension "merely means that whoever the publisher is has proven the ownership of a domain. That means any domain."

And even Microsoft acknowledged to InfoWorld that social engineering techniques have been used to persuade victims to download malicious extensions — though they point out that Microsoft confirms that each extension has a Marketplace certificate and verifiable signature before being installed. "To help make informed decisions, we recommend consumers review information, such as domain verification, ratings and feedback to prevent unwanted downloads."

"If combating attacks and hijackings of legitimate software on open source registries like npm weren't challenging enough, app makers are increasingly experiencing the consequences of software self-sabotage," writes security researcher and reporter Ax Sharma via TechCrunch. "A developer can, on a whim, change their mind and do whatever they want with their open source code that, most of the time anyway, comes 'as is' without any warranty. Or, as seen by a growing trend this year, developers deliberately sabotaging their own software libraries as a means of protest -- turning software into 'protestware.'"

One of the many examples Sharma mentions happened during the first week of 2022, when thousands of applications that rely on the heavily used npm projects colors and faker broke and began printing gibberish text on users' screens. "It wasn't a malicious actor hijacking and altering these legitimate libraries," writes Sharma. "It turned out the projects' developer Mark Squires had intentionally corrupted his own work to send a message of protest to big corporations..." An anonymous reader shares an excerpt from his report: Open source developers are discovering new and creative avenues that no longer limit them to implementing new features for their projects, but to actively express their views on larger social matters by modifying their projects for a cause. And, unlike proprietary code that has to function in line with a paying customer's expectations, most open source licenses are quite permissive -- both for the consumer and the developer -- offering their code with licenses that offer no guarantees as to what a developer is not supposed to and will never do with their code, making protestware a gray area for defenders. In fact, as a security researcher at Sonatype, I observed how protestware posed a challenge for us in the early stages and how we would tweak our automated malware detection algorithms to now catch self-sabotages with projects like colors and faker. Traditionally, the system was designed to spot typosquatting malware uploaded to open source repositories, but cases like malicious hijacks or developers modifying their own libraries without warning required a deeper understanding of the intricacies of how protestware works.

The theme has also put major open source registries like npm -- owned by GitHub, a Microsoft subsidiary -- at a crossroads when having to deal with these edge cases. Socket's founder Feross Aboukhadijeh told TechCrunch that registries like GitHub are in a difficult position. "On the one hand, they want to support maintainers' right to freedom of expression and the ability to use their platform to support the causes they believe in. But on the other hand, GitHub has a responsibility to npm users to ensure that malicious code isn't served from npm servers. It's sometimes a difficult balancing act," said Aboukhadijeh. A simple solution to ensuring you are getting only vetted versions of a component in your build is to pin your npm dependency versions. That way, even if future versions of a project are sabotaged or hijacked, your build continues to use the "pinned" version as opposed to fetching the latest, tainted one. But this may not always be an effective strategy for all ecosystems, like PyPI, where existing versions of a component can be republished -- as we saw in the case of the hijacking of the ctx PyPI project.

"The conversation around 'protestware' is really a conversation about software supply chain security. You can't trust what you can't verify," Dan Lorenc, the co-founder and chief executive at Chainguard, a startup that specializes in software supply chain security, told TechCrunch. Lorenc's advice against preventing protestware is to follow good open source security hygiene and best practices that can help developers develop protestware more easily and early on. "Knowing and understanding your dependencies, conducting regular scans and audits of open source code you are using in your environments are a start." But Lorenc warns the debate about protestware could draw in copycats who would contribute to the problem and detract open source software defenders from focusing on tackling what's truly important -- keeping malicious actors at bay. And with protestware there remain unknown unknowns. What issue is too small -- or too big -- for protestware? While no one can practically dictate what an open source developer can do with their code -- it is a power developers have always possessed, but are now just beginning to harness.

Bun is "a modern JavaScript runtime like Node or Deno," according to its newly-launched web site, "built from scratch to focus on three main things."

- Start fast (it has the edge in mind).
- New levels of performance (extending JavaScriptCore, the engine).
- Being a great and complete tool (bundler, transpiler, package manager).

Bun is designed as a drop-in replacement for your current JavaScript & TypeScript apps or scripts — on your local computer, server or on the edge. Bun natively implements hundreds of Node.js and Web APIs, including ~90% of Node-API functions (native modules), fs, path, Buffer and more. [And Bun also implements Node.js' module resolution algorithm, so you can use npm packages in bun.js]

The goal of Bun is to run most of the world's JavaScript outside of browsers, bringing performance and complexity enhancements to your future infrastructure, as well as developer productivity through better, simpler tooling.... Why is Bun fast? An enormous amount of time spent profiling, benchmarking and optimizing things. The answer is different for every part of Bun, but one general theme: [it's written in Zig.] Zig's low-level control over memory and lack of hidden control flow makes it much simpler to write fast software.
An infographic on the site claims its server-side rendering of React is more than three times faster than Node or Deno. And Bun.js can even automatically load environment variables from .env files, according to the site. No more require("dotenv").load()
Hackaday describes it as "a performant all-in-one approach," including "bundling, transpiling, module resolution, and a fantastic foreign-function interface." Many Javascript projects have a bundling and transpiling step that takes the source and packages it together in a more standard format. Typescript needs to be packaged into javascript, and modules need to be resolved. Bun bakes all this in. Typescript and JSX "just work." This dramatically simplifies many projects as much of the build infrastructure is part of Bun itself, lowering cognitive load when trying to understand a project... Some web-specific APIs, such as fetch and Websockets, are also built-in.
"What's even wilder is that Bun is written by one person, Jared Sumner," the article points out — adding that the all the code is available on GitHub under the MIT License ("excluding dependencies which have various licenses.")

Long-time Slashdot reader theodp writes: Back in 1998, Ellen Ullman wrote in Salon about The dumbing-down of programming: "My programming tools were full of wizards. Little dialog boxes waiting for me to click "Next" and "Next" and "Finish." Click and drag and shazzam! — thousands of lines of working code. No need to get into the "hassle" of remembering the language. No need to even learn it. It is a powerful siren-song lure: You can make your program do all these wonderful and complicated things, and you don't really need to understand."

Twenty-four years later, PVS-Studio has published a translation of Ivan Belokamentsev's cautionary tale of how modernizing his interviewing process from coding on paper to a computer led him to inadvertently hire 'Google Programmers', who dazzled him in interviews and initially on the job, but soon reached a plateau in productivity that puzzled him until he had a gobsmacking realization.
From their article: It was like somebody hit me on the head with a sack of flour. It took me about two days to process it. How is it really possible? The beautiful, well-optimized code they showed me at the first interview was from the Internet. The explosive growth of productivity in the first months was due to the solutions that they found on the Internet. Those answers to user questions after the magic "We'll call you back" from these guys — were found on the Internet. They were coding without understanding the basic constructs. No, they didn't write code — they downloaded it. No, that's not it, either. To download the code is like running "npm i", it's ok. They copy-pasted the code. Without knowing how to write it.

That's what angered me — what the...? Well, I understand when you surf the net to figure out how a new technology works. Or when you need to use some exotic feature and not to bloat your head with unnecessary information. But basic things! How can you copy-paste basic things from the Internet?!
The article meditates on the mindset of "Google" programmers. Rather than learning about basic objects, types, and the constructs of a programming language, "Any information is available to them, always and everywhere. They've learned how to find this information quickly — whether it's the address of a store with cookies, pants on sale or generating a query."

But long-time Slashdot reader AmiMoJo now pushes back: This is dumb. Not everyone has a great memory, and these days there are so many different tools and frameworks that nobody can remember them all anyway. Back in the day when it was all C, you could reasonably write useful code on paper. These days most of that code will probably be interacting with libraries that you have not committed to memory.

If your developers are not progressing, help them. Give them training or mentoring. Challenge them.
And there's also this advice from Slashdot reader Iamthecheese: "Stop selecting for low ethics in your hiring process." There is a stupid, stupid idea out there among the pointy hair types that it's possible to hire top tier candidates for peanuts. This idea has been put into their heads by massively over-promising companies selling HR solutions of all shapes... They're actively selecting people with just enough ability to pass these specific tests and who are unwilling to show their true levels of ability by hashing it out on their own. So you have these untrained people who look for easy ways past problems, but you were expecting "rock stars".
Their suggested solution? "Stop looking for easy, cheap, already trained people and start looking for trainable, people." And then, "show them a little loyalty. That way you'll have people to train new hires, who also know what they're doing on the job."

"Security consultant Lance Vick recently acquired the expired domain used by the maintainer of a widely used NPM package," reports the Register, "to remind the JavaScript community that the NPM Registry still hasn't implemented adequate security." "I just noticed 'foreach' on NPM is controlled by a single maintainer," wrote Vick in a Twitter post on Monday. "I also noticed they let their domain expire, so I bought it before someone else did. I now control 'foreach' on npm, and the 36,826 projects that depend on it."

That's not quite the full story — he probably could have taken control but didn't. Vick acquired the lapsed domain that had been used by the maintainer to create an NPM account and is associated with the "foreach" package on NPM. But he said he didn't follow through with resetting the password on the email account tied to the "foreach" package, which is fetched nearly six million times a week. In an email to the Register, Vick explained... "I did not log into the account, as again, that crosses a line. I just sent a password reset email and bailed.

"Regardless of how much control I have over this particular package, which is unclear, NPM admits this particular expired domain problem is a known issue, citing this 2021 [research paper] which says, 'We also found 2,818 maintainer email addresses associated with expired domains, allowing an attacker to hijack 8,494 packages by taking over the NPM accounts.' In other words, anyone poking around is going to find accounts easy to take over in this way. I was not lucky or special." His point, which he has been trying for several years to communicate to those overseeing NPM — a part of GitHub since March 2020 — is that taking over the NPM account of a popular project to conduct a software supply chain attack continues to be too easy.

Part of the problem is that JavaScript developers often use packages that implement simple functions that are either already built into the language, like forEach, or ought to be crafted manually to avoid yet another dependency, like left-pad (now built-in as padStart). These trivial packages get incorporated into other packages, which may in turn become dependencies in different packages, thereby making the compromise of something like "foreach" a potentially far-reaching security incident.
But Vick argues that with so many upstream attack vectors, "We are all just trusting strangers on the internet to give us good candy from their truck," according to the Register. Their article points out that on Tuesday GitHub launched a beta test of improved 2FA security for all its NPM accounts — which Vick calls "a huge win... [T]hat is the best way to protect accounts. We in the security community have been demanding this for years."

But he's still worried about the possibility of email addresses with weak two-factor authentication or compromised NPM employees, and would like to see NPM implement cryptographic signatures for code. "I am talking with a member of their team tomorrow and we will see where this goes."

GitHub issued a security alert Friday.

GitHub's chief security officer wrote that on Tuesday, "GitHub Security began an investigation that uncovered evidence that an attacker abused stolen OAuth user tokens issued to two third-party OAuth integrators, Heroku and Travis-CI, to download data from dozens of organizations, including npm..."

We do not believe the attacker obtained these tokens via a compromise of GitHub or its systems, because the tokens in question are not stored by GitHub in their original, usable formats. Following immediate investigation, we disclosed our findings to Heroku and Travis-CI on April 13 and 14...

Looking across the entire GitHub platform, we have high confidence that compromised OAuth user tokens from Heroku and Travis-CI-maintained OAuth applications were stolen and abused to download private repositories belonging to dozens of victim organizations that were using these apps. Our analysis of other behavior by the threat actor suggests that the actors may be mining the downloaded private repository contents, to which the stolen OAuth token had access, for secrets that could be used to pivot into other infrastructure.

We are sharing this today as we believe the attacks may be ongoing and action is required for customers to protect themselves.

The initial detection related to this campaign occurred on April 12 when GitHub Security identified unauthorized access to our npm production infrastructure using a compromised AWS API key. Based on subsequent analysis, we believe this API key was obtained by the attacker when they downloaded a set of private npm repositories using a stolen OAuth token from one of the two affected third-party OAuth applications described above. Upon discovering the broader theft of third-party OAuth tokens not stored by GitHub or npm on the evening of April 13, we immediately took action to protect GitHub and npm by revoking tokens associated with GitHub and npm's internal use of these compromised applications.

We believe that the two impacts to npm are unauthorized access to, and downloading of, the private repositories in the npm organization on GitHub.com and potential access to the npm packages as they exist in AWS S3 storage.

At this point, we assess that the attacker did not modify any packages or gain access to any user account data or credentials. We are still working to understand whether the attacker viewed or downloaded private packages.

npm uses completely separate infrastructure from GitHub.com; GitHub was not affected in this original attack. Though investigation continues, we have found no evidence that other GitHub-owned private repos were cloned by the attacker using stolen third-party OAuth tokens.

Once GitHub identified stolen third-party OAuth tokens affecting GitHub users, GitHub took immediate steps to respond and protect users. GitHub contacted Heroku and Travis-CI to request that they initiate their own security investigations, revoke all OAuth user tokens associated with the affected applications, and begin work to notify their own users.... GitHub is currently working to identify and notify all of the known-affected victim users and organizations that we discovered through our analysis across GitHub.com. These customers will receive a notification email from GitHub with additional details and next steps to assist in their own response within the next 72 hours. If you do not receive a notification, you and/or your organization have not been identified as affected.

You should, however, periodically review what OAuth applications you've authorized or are authorized to access your organization and prune anything that's no longer needed. You can also review your organization audit logs and user account security logs for unexpected or anomalous activity....

The security and trustworthiness of GitHub, npm, and the broader developer ecosystem is our highest priority. Our investigation is ongoing, and we will update this blog, and our communications with affected customers, as we learn more.

Richard Stallman celebrated his 69th birthday last month. And Wednesday, he gave a 92-minute presentation called "The State of the Free Software Movement."

Stallman began by thanking everyone who's contributed to free software, and encouraged others who want to help to visit gnu.org/help. "The Free Software movement is universal, and morally should not exclude anyone. Because even though there are crimes that should be punished, cutting off someone from contributing to free software punishes the world. Not that person."

And then he began by noting some things that have gotten better in the free software movement, including big improvements in projects like GNU Emacs when displaying external packages. (And in addition, "GNU Health now has a hospital management facility, which should make it applicable to a lot more medical organizations so they can switch to free software. And [Skype alternative] GNU Jami got a big upgrade.")

What's getting worse? Well, the libre-booted machines that we have are getting older and scarcer. Finding a way to support something new is difficult, because Intel and AMD are both designing their hardware to subjugate people. If they were basically haters of the public, it would be hard for them to do it much worse than they're doing.

And Macintoshes are moving towards being jails, like the iMonsters. It's getting harder for users to install even their own programs to run them. And this of course should be illegal. It should be illegal to sell a computer that doesn't let users install software of their own from source code. And probably shouldn't allow the computer to stop you from installing binaries that you get from others either, even though it's true in cases like that, you're doing it at your own risk. But tying people down, strapping them into their chairs so that they can't do anything that hurts themselves -- makes things worse, not better. There are other systems where you can find ways to trust people, that don't depend on being under the power of a giant company.

We've seen problems sometimes where supported old hardware gets de-supported because somebody doesn't think it's important any more — it's so old, how could that matter? But there are reasons...why old hardware sometimes remains very important, and people who aren't thinking about this issue might not realize that...

Stallman also had some advice for students required by their schools to use non-free software like Zoom for their remote learning. "If you have to use a non-free program, there's one last thing... which is to say in each class session, 'I am bitterly ashamed of the fact that I'm using Zoom for this class.' Just that. It's a few seconds. But say it each time.... And over time, the fact that this is really important to you will sink in."

And then halfway through, Stallman began taking questions from the audience...

Read on for Slashdot's report on Stallman's remarks, or jump ahead to...

• How far should copyright law go?
• That NPM package that deleted files in Russia
• Does the free software world need more videogames?
• Stallman's upcoming manual for 'GNU C'
• Free Software's role in protecting our planet's environment

Long-time Slashdot reader theodp writes: In On the Weaponisation of Open Source, software engineering consultant Gerald Benischke examines how the Russian invasion of Ukraine has spilled over into areas of software development, with some unintended consequences. In particular, Benischke looks at the decision by MongoDB to cut off services in Russia, the destructive change in a node library that deleted files on Russian IPs, and even a change in the code/licence in a community terraform module to assert that Putin is a 'dickhead.'

Benischke concludes, "My problem is that this weaponisation is killing off trust. I think the temptation of using open source projects as weapons against Russia should be resisted because it sets a dangerous precedent and may ultimately set back the open source movement and push organisations back into seeking refuge in commercial software with all its opaqueness and obscurity. It's not about sitting on the fence or taking sides in a war. It's about what open source has achieved over the last 30 years and I think that's now at risk of become collateral damage."

Meanwhile, the war is also being fought on the Cloud front, with Microsoft halting all new sales in Russia. In fact, all of the major U.S. cloud providers have stepped back from doing business in Russia. "You basically have Russia becoming a commercial pariah," explained economist Mary Lovely. "Pretty much no company, no multinational, wants to be caught on the wrong side of U.S. and Western sanctions."

The developer behind the popular npm package 'node-ipc' released sabotaged versions of the library in protest of the ongoing Russo-Ukrainian War, BleepingComputer reports. From the article: Newer versions of the 'node-ipc' package began deleting all data and overwriting all files on developer's machines, in addition to creating new text files with "peace" messages. With over a million weekly downloads, 'node-ipc' is a prominent package used by major libraries like Vue.js CLI.

Select versions (10.1.1 and 10.1.2) of the massively popular 'node-ipc' package were caught containing malicious code that would overwrite or delete arbitrary files on a system for users based in Russia and Belarus. These versions are tracked under CVE-2022-23812. On March 8th, developer Brandon Nozaki Miller, aka RIAEvangelist released open source software packages called peacenotwar and oneday-test on both npm and GitHub. The packages appear to have been originally created by the developer as a means of peaceful protest, as they mainly add a "message of peace" on the Desktop of any user installing the packages. "This code serves as a non-destructive example of why controlling your node modules is important," explains RIAEvangelist.

"Much of the most widely used free and open source software is developed by only a handful of contributors," warns the Linux Foundation, in the executive summary for its massive new census of free and open source software application libraries. It was prepared in conjunction with Harvard's Laboratory for Innovation Science — and that's just one of its five high-level findings.

The census also notes "the increasing importance of individual developer account security," but also the persistence of legacy software, the need for a standardized naming schema for software components, and "complexities" around package versions. But there's also just a lot of data about package popularity, writes SD Times: The report, Census II, is a follow-up to Census I, which was conducted in 2015 to identify the packages in Debian Linux that were most critical to the operation and security of the kernel. According to the Linux Foundation, Census II allows for a more "complete picture of free and open source (FOSS) adoption."

"Understanding what FOSS packages are the most critical to society allows us to proactively support projects that warrant operations and security support," said Brian Behlendorf, executive director at Linux Foundation's Open Source Security Foundation (OpenSSF).
The census "aggregates data from over half a million observations of FOSS libraries used in production applications at thousands of companies," according to its executive summary. It argues that preserving FOSS will require this kind of data-sharing (about where and how FOSS packages are being used ) as well as coordination — including standardizing terminology — and of course, investment.

"The motivation behind publishing these findings is to not only inform, but also to inspire action by developers to improve their security practices and by end users to support the FOSS ecosystem and developers who need assistance." (It suggests companies companies could provide not just financial support but also the technical talent and their time.) The results take the form of eight Top 500 lists — four that include version numbers in the analysis and four that are version agnostic. Further, as mentioned above, we present npm and non-npm packages in separate lists... Although these lists provide valuable, important insights into the most widely used FOSS projects, it is important to also consider the level of security related to these projects. Therefore, in each list, we also include the "Tiered %" measure from the OpenSSF Best Practices Badging Program....

From Mike Melanson's "This Week in Programming" column: The 20th anniversary of .NET is upon us this week and with it, Microsoft is pulling out all the stops in celebration of what it says is "the most loved framework by developers for three years in a row now — 2019, 2020, 2021, according to Stack Overflow's developer survey."

First launched in 2002, .NET is, in some ways, something that Microsoft can roll out as evidence of its changed ways over the years. It went from a company embroiled in a monopoly case just a year before this release, to one that later decided to turn around, mend its former ways, and open source .NET Core. "When Microsoft made another major transformation, this time towards open source, .NET was also at the forefront," Microsoft writes in this week's celebratory blog post. "By 2012, we had fully open-sourced the ASP.NET MVC web framework and were accepting contributions. It was one of Microsoft's first major open-source projects at the time. In 2014, we started to build a cross-platform and open-source .NET on GitHub and were floored at the incredible support and contributions from the open-source community...."

Certainly, in comparison to the Microsoft we once knew, there has been a massive shift in its approach to open source software and openness in general. Indeed, these days, Microsoft is also synonymous with another giant in the world of open source, its now-subsidiary GitHub — as well as the npm Registry and countless other projects. Microsoft has transformed from a company that was once led by a man who said that "Linux is a cancer" to one that has more recently welcomed Linux to the Windows desktop, among numerous other open source endeavors.
The column ends by remembering what it calls "Microsoft 'hot reload' drama" last year — Microsoft's removal of the feature from the .NET SDK repo (and its subsequent return, with an apology). "All that's to say, perhaps all's well that ends well, and we should indeed celebrate 20 years of success with a now open source framework. In the same breath, vigilance may be necessary should we want to celebrate another such anniversary in the future."

An academic research project found that thousands of JavaScript developers are using an email address with an expired domain for their npm accounts, leaving their projects exposed to easy hijacks. From a report: The study, performed last year by researchers from Microsoft and North Caroline State University, analyzed the metadata of 1,630,101 libraries uploaded on Node Package Manager (npm), the de-facto repository for JavaScript libraries and the largest package repository on the internet. Researchers said they found that 2,818 project maintainers were still using an email address for their accounts that had an expired domain, some of which they found on sale on sites like GoDaddy. The team argued that attackers could buy these domains, re-register the maintainer's address on their own email servers, and then reset the maintainer's account password and take over his npm packages.

The administrators of the Node Package Manager (npm), the largest package repository of the JavaScript ecosystem, said they enrolled the maintainers of the top 100 most popular libraries (based on the number of dependencies) into their mandatory two-factor authentication (2FA) procedure. From a report: npm, which is owned by GitHub, enforced this new security requirement starting yesterday, February 1, 2022. "Maintainers who do not currently have 2FA enabled will have their web sessions revoked and will need to set up 2FA before they can take specific actions with their accounts, such as changing their email address or adding new maintainers to projects," the GitHub security team said in a blog post. The move represents the second phase of a major push from the npm team to secure developer accounts, which have been getting hijacked in recent years and used to push malware inside legitimate JavaScript libraries. In many cases, the accounts are hacked because project maintainers use simple-to-guess passwords or reused passwords that were previously leaked via breaches at other companies. The first phase of this process took place between December 7, 2021, and January 4, 2022, when the npm team rolled out a new feature called "enhanced login verification" for all npm package maintainers.