The npm ecosystem of JavaScript libraries is more interwoven than most developers think, and the entire thing is a gigantic house of cards, being one bad hack away from compromising hundreds of thousands of projects, according to a recent academic study. From a report: The research, carried out by the Department of Computer Science from the Technical University of Darmstadt, in Germany, analyzed the dependency graph of the entire npm ecosystem. Researchers downloaded metadata for all the npm packages published until April 2018 and created a giant graph that included 676,539 nodes and 4,543,473 edges (lines connecting the nodes). In addition, academics also analyzed different versions of the same packages, looking at historical versions (5,386,239 versions for the 676,539 packages), but also at the package maintainers (199,327 npm accounts), and known security flaws impacting the packages (609 public reports). [...]

Their goal was to get an idea of how hacking one or more npm maintainer accounts, or how vulnerabilities in one or more packages, reverberated across the npm ecosystem; along with the critical mass needed to cause security incidents inside tens of thousands of npm projects at a time. [...] But while some npm packages load code from too many packages and from too many developers, there is another dangerous trend forming on the npm package repository -- namely the consolidation of popular npm packages under a few maintainer accounts. "391 highly influential maintainers affect more than 10,000 packages, making them prime targets for attacks," the research team said. "If an attacker manages to compromise the account of any of the 391 most influential maintainers, the community will experience a serious security incident."

intensivevocoder writes: Bryan Bogensberger's exit from npm, inc was quietly announced Friday afternoon in a press release stating that Bogensberger "resigned effective immediately to pursue new opportunities." This marked likely one of the few quiet actions in Bogensberger's tumultuous tenure as CEO of npm, the popular package manager of Node.js. Bogensberger started as CEO on January 9 this year, as part of a move announced by original author and co-founder Isaac Z. Schlueter as part of a plan to commercialize the service. Bogensberger's involvement with the company started in mid-2018, although he was not formally named CEO until 2019 pending the resolution of visa requirements. "Commercializing something like this without ruining it is no small task, and building the team to deliver on npm's promise is a major undertaking. We've sketched out a business plan and strategy for the next year, and will be announcing some other key additions to the team in the coming months," Schlueter wrote in January.

"Given how dependent we've become upon open source software, one would think that we would have a bevy of options for supporting the developers who write the code, but we don't..." writes InfoWorld's Matt Asay, in an essay defending Feross Aboukhadijeh for experimenting with ads in his open source JavaScript style guide library.

"We have some inchoate business and funding models that serve open source companies and open source developers more or less well, and too often less. What we need is more people like Aboukhadijeh earnestly experimenting with ways to make things better, more companies like Tidelift introducing novel ways to fund developers, and more organizations recognizing their own self-interest in employing or otherwise paying the developers who build the software they rely on... [U]ltimately, we need more experimentation, and less criticism." What about donations? As Aboukhadijeh has noted, "Lots of maintainers struggle to reach a barely livable wage via donations...." Linux Foundation Chris Aniszczyk has derisively described the approach [and] goes on to put the onus for paying developers on those companies that most benefit from their work: "[A] big part of innovation comes from developers working at organizations adopting open source software at scale and using it in interesting ways. It's these organizations that should be tasked to sustain open source software versus individuals, especially since they depend on open source software to survive as a business."

Aniszczyk isn't talking about mega-corps throwing money at mega-tip jars. Rather, he's talking about the big beneficiaries employing the developers who build the projects upon which they depend. It's a great idea, and one that has borne fruit in the Linux community and currently in the Kubernetes world. However it's done, there's an underlying principle that is critical to all of this: We need more experimentation.

The first requirement for ensuring open source sustainability is to allow and encourage experimentation. Concerned at his (and other open source developers') inability to make a comfortable living writing popular open source software, Standard co-founder Aboukhadijeh decided to experiment with an ad-supported model...

A week after a popular JavaScript library started showing full-blown ads in the npm command-line interface, npm, Inc., the company that runs the npm tool and website, has taken a stance and plans to ban such behavior in the future. From a report: "We are always working on improving our policies and expand on our commitments to the community," Ahmad Nassri, npm, Inc. CTO told ZDNet in an email this week. "To that end, we're making updates to our policies to be more explicit about the type of commercial content we do deem not acceptable." According to these upcoming updates, npm will ban:
1. Packages that display ads at runtime, on installation, or at other stages of the software development lifecycle, such as via npm scripts.
2. Packages with code that can be used to display ads are fine. Packages that themselves display ads are not.
3. Packages that themselves function primarily as ads, with only placeholder or negligible code, data, and other technical content.

Standard, a popular Javascript style guide library that is downloaded about three million times each month, is beginning to show ads when installed through npm, a developer announced this week. The move, which has been pegged as an experiment, comes as the developer looks to find sustainable ways to support contributions to the open source development. In a post, Feross Aboukhadijeh, a developer of Standard, said whenever Standard 14 is installed, "we'll display a message from a company that supports open source. The sponsorship pays directly for maintainer time. That is, writing new features, fixing bugs, answering user questions, and improving documentation."

The announcement has sparked a debate in the community with some suggesting that there should be a better way to support the FOSS developers without seeing ads on the terminal.

"If you're a cryptocurrency startup, would you face a huge backlash by hacking your own customers to keep their funds safe if you know that a hacker is about to launch an attack and steal their funds?" asks ZDNet: This is exactly what happened yesterday when the Komodo Platform learned about a backdoor in one of its older wallet apps named Agama. Knowing they had little time to act, the Komodo team said it used the same backdoor to extract users' funds from all impacted wallets and move them to a safe location, out of the hacker's reach.

The tactic paid off, and 8 million Komodo coins and 96 bitcoins, worth nearly $13 million, were taken from users' vulnerable accounts before the hacker could get a chance to abuse the backdoor and steal users' funds... While initially, it did not make any sense for a library with a very limited feature-set to contain such an advanced functionality, after investigating the issue, npm staffers realized they were dealing with a supply-chain attack aimed at another app downstream, which was using the now-backdoored library... The npm team said the malicious code would work as intended and collect Agama wallet app seeds and passphrases, and upload the data to a remote server.
These malicious-payload updates are "becoming more and more popular," according to a post on the official npm blog (a point they later emphasized in a press release).

"After being notified by our internal security tooling of this threat we responded by notifying and coordinating with Komodo to protect their users as well as remove the malware from npm."

"Online marketplace eBay has revealed how it boosted performance of a demanding web app by 50x using WebAssembly," reports TechRepublic: The "astonishing" speed-up after switching from a JavaScript-based to a largely WebAssembly-based web app was detailed by the eBay engineering team, who say the performance boost helped make it possible to build a highly-accurate barcode scanner as a web app... a feature it offers in its Android and iOS apps to allow sellers to scan items they are auctioning. "WebAssembly was different. It has tremendous potential, we just did not have the right use case. Well, that changed recently," write the eBay software engineering team.

One of the advantages of WebAssembly (Wasm) is that it offers code portability for a variety of languages, allowing developers to take code they've written for other platforms and compile to WebAssembly so it can run in major web browsers. Consequently eBay was able to take the existing version of its barcode scanner written in C++ and compile that to Wasm using Emscripten, adopting the Docker and Node.js-based approach outlined here. After a few minor teething problems, the eBay team were able to run the barcode scanner in the browser, using a Worker thread and JavaScript glue code.

The Wasm-based scanner was able to process images of the barcode at 50 Frames per Second (FPS), compared to about 1FPS in an earlier JavaScript-based scanner eBay had tested, a speed-up the team described as "astonishing".
Unfortunately, the Wasm code only successfully completed scans 60% of the time, because it wasn't using the inbuilt APIs available for the C++ code to either autofocus or provide user tap focus for the center of the scanned object. eBay's team ultimately ended up implementing three separate worker threads running the Wasm code, the open-source barcode reader ZBar, and their original JavaScript-based scanner code.

"The winning response (i.e. the first one to send a valid barcode) is sent to the main thread, and all workers are terminated... With three threads racing against each other, the success rate was indeed close to 100%."

ZDNet asked the question -- pointing to a RedMonk survey which found TypeScript jumped in popularity from #16 to #12 over the last six months (based on its usage in GitHub projects and in questions on Stack Overflow). The reason for this rise can be found in the latest survey of 33,000 developers from 156 countries who use npm, a hugely popular Node.js JavaScript package manager that's traditionally used to build website features... As per npm developers, a big surprise in last year's survey was that 46 percent of respondents said they used TypeScript. Today, the proportion of developers who use Microsoft's open-source take on JavaScript has ballooned to 62 percent... "Overall, 36 percent of npm users are writing TypeScript some or most of the time. That a third of the users in the JavaScript community are writing a totally new flavor of JavaScript should make everyone sit up and take notice" [according to npm Inc's report]. In other words, TypeScript should be on the list of languages to understand. As RedMonk noted in March, the growing number of projects helps explain why TypeScript's "trajectory is significant and sustainable" and won't just fade away like many other languages.
The article also argues that Microsoft's hit with TypeScript "comes as its open-source cross-platform code editor Visual Studio Code, or VS Code, finds a sweet spot with developers across the world, rising from being used by 500,000 developers in 2016 to 4.5 million in 2019. "

Meanwhile npm Inc. also points out that Slack's desktop application was written in JavaScript, pointing to this as evidence that JavaScript itself "has broken out of the browser and become a general-purpose programming language, put to all the same uses as other programming languages."

JavaScript library manager NPM on Wednesday apologized for its handling of a contentious round of recent layoffs. The Register reports: The company statement, which comes a week after product manager Rebecca Turner resigned in protest, is co-signed by chief executive officer Bryan Bogensberger, chief product officer Isaac Schlueter and chief data officer Laurie Voss. "Recently, we let go of five people in a company restructuring," the statement says. "The way that we undertook the process, unfortunately, made the terminations more painful than they needed to be, which we deeply regret, and we are sorry." By way of explanation, the statement attributes the changes at the company to shifting the firm's source of financial sustenance from venture funding to product revenue. That requires "new levels of commitment, delivery, and accountability," the implementation of which "has been uncomfortable at times."

In response to a question posed by The Register via Twitter, the company's former CTO CJ Silverio said, "The main thing I want to note is how NPM's statement is not an apology by [Isaac's] own standards. His blog post about apologies is very clear about the three things an apology must contain, and it seems to me that all three items were missing from that statement. It said nothing substantive. It went so far as to blame NPM's users for forcing them into the move."

Microsoft's programming language TypeScript has become one of the most popular languages among developers, at least according to a report published by the analyst firm RedMonk this week. Wired: TypeScript jumped from number 16 to number 12, just behind Apple's programming language Swift in RedMonk's semiannual rankings, which were last published in August. Microsoft unveiled TypeScript in 2012, and while it hasn't grown as quickly as Swift -- which has grown faster than any other language, ever since RedMonk started compiling the rankings in 2011 -- TypeScript's own ascendance is impressive, given the sheer number of available programming languages.

More and more applications these days use TypeScript. Google's programming framework Angular, the second most popular tool of its type according to data released last year by the startup NPM, is written in TypeScript. So is Vue, an increasingly popular framework finding a home both among smaller companies and tech giants like Alibaba. But RedMonk doesn't look at how many jobs are available for people skilled in a particular language, nor how many companies actually use the language. Instead, the firm tries to spot trends in developer interest by looking at how many projects on GitHub use certain languages, and how many questions are asked about those languages on the programmer Q&A site Stack Overflow. The idea is to get a sense of where the software development profession is heading.

"[O]n Nov. 26 it was publicly revealed that a widely deployed open-source Node.js programming language module known as event-stream had been injected with malicious code that looked to steal cryptocurrency wallets," reports eWeek, adding "The event-stream library has over two million downloads."

An anonymous reader quotes Ars Technica: The backdoor came to light [November 20th] with this report from Github user Ayrton Sparling. Officials with the NPM, the open source project manager that hosted event-stream, didn't issue an advisory until six days later.... "This compromise was not targeting module developers in general or really even developers," an NPM official told Ars in an email. "It targeted a select few developers at a company, Copay, that had a very specific development environment set up. Even then, the payload itself didn't run on those developers' computers; rather, it would be packaged into a consumer-facing app when the developers built a release. The goal was to steal Bitcoin from this application's end users...."

According to the Github discussion that exposed the backdoor, the longtime event-stream developer no longer had time to provide updates. So several months ago, he accepted the help of an unknown developer. The new developer took care to keep the backdoor from being discovered. Besides being gradually implemented in stages, it also narrowly targeted only the Copay wallet app. The malicious code was also hard to spot because the flatmap-stream module was encrypted. The attack is the latest to exploit weaknesses in a widely used supply chain to target downstream end users... The supply-chain attacks show one of the weaknesses of open source code. Because of its openness and the lack of funds of many of its hobbyist developers and users, open source code can be subject to malicious modifications that often escape notice.
"The time has come," concludes Ars Technica, "for maintainers and users of open source software to devise new measures to better police the millions of packages being used all around us." Sophos' security blog also asks why so many developers "immediately and blindly trusted the new maintainer," and shared a concerned comment from developer named Chris Northwood.

"Nothing's stopping this happening again, and it's terrifying."

Donald Fischer, who served as a product manager for Red Hat Enterprise Linux during its creation and early years of growth, writes: Red Hat saw, earlier than most, that the ascendance of open source made the need to pay for code go away, but the need for support and maintenance grew larger than ever. Thus Red Hat was never in the business of selling software, rather it was in the business of addressing the practical challenges that have always come along for the ride with software. [...] As an open source developer, you created that software. You can keep your package secure, legally documented, and maintained; who could possibly do it better? So why does Red Hat make the fat profits, and not you? Unfortunately, doing business with large companies requires a lot of bureaucratic toil. That's doubly true for organizations that require security, legal, and operational standards for every product they bring in the door. Working with these organizations requires a sales and marketing team, a customer support organization, a finance back-office, and lots of other "business stuff" in addition to technology. Red Hat has had that stuff, but you haven't.

And just like you don't have time to sell to large companies, they don't have time to buy from you alongside a thousand other open source creators, one at a time. Sure, big companies know how to install and use your software. (And good news! They already do.) But they can't afford to put each of 1100 npm packages through a procurement process that costs $20k per iteration. Red Hat solved this problem for one corner of open source by collecting 2,000+ open source projects together, adding assurances on top, and selling it as one subscription product. That worked for them, to the tune of billions. But did you get paid for your contributions?

Nikita Prokopov, a software programmer and author of Fira Code, a popular programming font, AnyBar, a universal status indicator, and some open-source Clojure libraries, writes: Remember times when an OS, apps and all your data fit on a floppy? Your desktop todo app is probably written in Electron and thus has userland driver for Xbox 360 controller in it, can render 3d graphics and play audio and take photos with your web camera. A simple text chat is notorious for its load speed and memory consumption. Yes, you really have to count Slack in as a resource-heavy application. I mean, chatroom and barebones text editor, those are supposed to be two of the less demanding apps in the whole world. Welcome to 2018.

At least it works, you might say. Well, bigger doesn't imply better. Bigger means someone has lost control. Bigger means we don't know what's going on. Bigger means complexity tax, performance tax, reliability tax. This is not the norm and should not become the norm. Overweight apps should mean a red flag. They should mean run away scared. 16Gb Android phone was perfectly fine 3 years ago. Today with Android 8.1 it's barely usable because each app has become at least twice as big for no apparent reason. There are no additional functions. They are not faster or more optimized. They don't look different. They just...grow?

iPhone 4s was released with iOS 5, but can barely run iOS 9. And it's not because iOS 9 is that much superior -- it's basically the same. But their new hardware is faster, so they made software slower. Don't worry -- you got exciting new capabilities like...running the same apps with the same speed! I dunno. [...] Nobody understands anything at this point. Neither they want to. We just throw barely baked shit out there, hope for the best and call it "startup wisdom." Web pages ask you to refresh if anything goes wrong. Who has time to figure out what happened? Any web app produces a constant stream of "random" JS errors in the wild, even on compatible browsers.

[...] It just seems that nobody is interested in building quality, fast, efficient, lasting, foundational stuff anymore. Even when efficient solutions have been known for ages, we still struggle with the same problems: package management, build systems, compilers, language design, IDEs. Build systems are inherently unreliable and periodically require full clean, even though all info for invalidation is there. Nothing stops us from making build process reliable, predictable and 100% reproducible. Just nobody thinks it's important. NPM has stayed in "sometimes works" state for years.

NPM Inc. added a feature to JavaScript's package manager this spring letting users type npm audit fix to replace old, insecure project modules -- and the Register asked them how it's going? Since April, according to the company, npm users have run 50 million automatic scans and have deliberately invoked the command 3.1 million times. And they're running 3.4 million security audits a week. Across all audits, 51 per cent found at least one vulnerability and 11 per cent identified a critical vulnerability. In a phone interview with The Register, Adam Baldwin, head of security at NPM, said he didn't have data on how many people are choosing to fix flagged flaws. "But what we've seen from pull requests suggests it's gaining traction," he said.

Incidentally, npm's thinking about security is finding similar expression elsewhere in the industry. Earlier this year, GitHub began alerting developers when their code contains insecure libraries. During a recent media briefing, GitHub's head of platform Sam Lambert said he hoped that the process could be made more automated through the mechanized submission of git pull requests that developers could simply accept to replace flawed code.

Baldwin said NPM might implement something similar, an intervention rather than a simple notification. "Currently it's not proactive policy enforcement," he said. "But it's something we're considering." That would appeal to NPM's growing enterprise constituency. "Enterprises for sure want the compliance and control," said Baldwin. "They want that ability to know the open source they're bringing in is safe or meets a certain set of criteria."
Wednesday NPM added "Report a Vulnerability" buttons to every NPM package web page, and also started checking new passwords against the "Have I Been Pwned?" database to spot already-compromised passwords. "The tools for avoiding problems and fixing them are getting better," writes the Register. But it'd be interesting to hear from Slashdot readers.

How do you feel about code repositories automatically offering replacements for insecure libraries?

An anonymous reader shares a report: A hacker gained access to a developer's npm account earlier this week and injected malicious code into a popular JavaScript library, code that was designed to steal the npm credentials of users who utilize the poisoned package inside their projects. The JavaScript (npm) package that got compromised is called eslint-scope, a sub-module of the more famous ESLint, a JavaScript code analysis toolkit. The hack took place on the night between July 11 and 12, according to the results of a preliminary investigation posted on GitHub a few hours ago. "One of our maintainers did observe that a new npm token was generated overnight (said maintainer was asleep)," said Kevin Partington, ESLint project member. Partington believes the hacker used the newly-generated npm token to authenticate and push a new version of the eslint-scope library on the npm repository of JavaScript packages.

An anonymous reader writes: "The Docker team has pulled 17 Docker container images that have been backdoored and used to install reverse shells and cryptocurrency miners on users' servers for the past year," reports Bleeping Computer. "The malicious Docker container images have been uploaded on Docker Hub, the official repository of ready-made Docker images that sysadmins can pull and use on their servers, work, or personal computers." The images, downloaded over 5 million times, helped crooks mine Monero worth over $90,000 at today's exchange rate. Docker Hub is now just the latest package repository to feature backdoored libraries, after npm and PyPl. Docker Hub is now facing criticism for taking months to intervene after user reports, and then going on stage at a developer conference and claiming they care about security.

Catalin Cimpanu, writing for BleepingComputer: Users of the NPM JavaScript package manager were greeted by a weird error yesterday evening, as their consoles and applications spewed a message of "ERR! 418 I'm a teapot" whenever they tried to update or install a new JavaScript/Node.js package. JavaScript developers from all over the world received the error, and not just in certain geographical regions. The bug did not affect all users, but only those behind a proxy server.

Catalin Cimpanu, reporting for BleepingComputer: The Node Package Manager (npm) team avoided a disaster today when it discovered and blocked the distribution of a cleverly hidden backdoor mechanism inside a popular -- albeit deprecated -- JavaScript package. The actual backdoor mechanism was found in "getcookies," a relatively newly created npm package (JavaScript library) for working with browser cookies. The npm team -- which analyzed this package earlier today after reports from the npm community -- says "getcookies" contains a complex system for receiving commands from a remote attacker, who could target any JavaScript app that had incorporated this library.

Catalin Cimpanu, reporting for BleepingComputer: A bug in npm (Node Package Manager), the most widely used JavaScript package manager, will change ownership of crucial Linux system folders, such as /etc, /usr, /boot. Changing ownership of these files either crashes the system, various local apps, or prevents the system from booting, according to reports from users who installed npm v5.7.0. -- the buggy npm update. Users who installed this update -- mostly developers and software engineers -- will likely have to reinstall their system from scratch or restore from a previous system image.

An anonymous reader quotes InfoWorld's report on which JavaScript frameworks are the most widely-used: In a study of 28-day download cycles for front-end JavaScript frameworks, NPM, which oversees the popular JavaScript package registry, found that React has been on a steady upward trajectory; it now accounts for about 0.05 percent of the registry's 13 billion downloads per month as of the fourth quarter of 2017. Web developers as well as desktop and mobile developers are adopting the library and it has spawned an ecosystem of related packages. Preact, a lightweight alternative to React, also has seen growth and could become a force in the future.

On the down side, Backbone, which accounted for almost 0.1 percent of all downloads in 2013, now comprises only about 0.005 percent of downloads (about 750,000 per month). Backbone has declined steeply but is kept afloat by the long shelf life of projects using it, NPM reasoned. The jQuery JavaScript library also remains popular but has experienced decreasing interest. Angular, the Google-developed JavaScript framework, was the second-most-popular framework behind React, when combining the original Angular 1.x with the rewritten Angular 2.x. Version 1.x was at about 0.0125 percent of downloads last month while version 2.x was at about 0.02 percent. Still, Angular as a whole is showing just modest growth.
They also report that the four JavaScript frameworks with the fastest growth rates for 2017 were Preact, Vue, React, and Ember.

But for back end services written in JavaScript, npm reports that Express "is the overwhelmingly dominant solution... The next four biggest frameworks are so small relative to Express that it's hard to even see them."