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.

Remember that developer who intentionally corrupted his two libraries which collectively had over 20 million weekly downloads and thousands of dependent projects? In the immediate aftermath he'd complained on Twitter that NPM "has reverted to a previous version of the faker.js package and Github has suspended my access to all public and private projects. I have 100s of projects. #AaronSwartz."

That was January 6th, and within about a week GitHub had restored his access, while one of his two libraries (faker-js) was forked by its community to create a community-driven project. But Thursday the developer announced on his Twitter account: What's up @Github? Ten days since you removed my ability to publish to NPM and fix the Infinity Zalgo bug in colors.js

Never responded to my support emails.

I have 100s of packages I need to maintain.

Everyone makes programming mistakes from time to time. Nobody is perfect.
It hasn't been confirmed that NPM has actually blocked his ability to publish — but the tweet already appears to be attracting reactions from other developers on social media.

Owen Williams, writing for TechCrunch: [...] As a result, it shouldn't be a surprise that some open source developers are beginning to realize they wield outsized power, despite the lack of compensation they receive for their work, because their projects are used by some of the largest, most profitable companies in the world. In early January, for example, Marak Squires, the developer of two popular NPM packages, 'colors' and 'faker,' intentionally introduced changes to their code that broke their functionality for anyone using them, outputting "LIBERTY LIBERTY LIBERTY" followed by gibberish and an infinite loop when used. While Squires didn't comment on the reason for making the changes, he had previously said on GitHub that "I am no longer going to support Fortune 500s ( and other smaller sized companies ) with my free work." Squires' changes broke other popular projects, including Amazon's Cloud Development Kit, as his libraries were installed almost 20 million times per week on npm, with thousands of projects directly depending on them. Within a few hours, NPM had rolled back the rogue release and GitHub suspended the developer's account in response.

While NPM's response was to be expected after previous incidents in which malicious code was added to libraries and was ultimately rolled back to limit damage, GitHub's was a new one: the code hosting platform took down Squires' entire account, even though he was the owner of the code and was his rights to change it as he pleased. This isn't the first time a developer has pulled their code in protest, either. The developer of 'left-pad' pulled his code from NPM in 2016, breaking tens of thousands of websites that depended on it following a fight with the Kik messenger over the naming of another open source project he owned. What's astonishing is that despite the occasional high-profile libraries protesting the way the industry works, these types of incidents aren't all that common: open source developers continue to work for free, maintaining their projects as best they can, even though multi-million dollar products being created off of the back of their work.

Last weekend a developer intentionally corrupted two of his libraries which collectively had more than 20 million weekly downloads and thousands of dependent projects.

Eight days later, one of those libraries has become a community controlled project.

Some highlights from the announcement at fakerjs.dev: We're a group of engineers who were using Faker in prod when the main package was deleted. We have eight maintainers currently....

What has the team done so far?

1. Created a GitHub org [repository] for the new Faker package under @faker-js/faker.
2. Put together a team of eight maintainers.
3. Released all previous versions of Faker at @faker-js/faker on npm.
4. Released the Version 6 Alpha
5. Almost completed migrating to TypeScript so that DefinitelyTyped no longer needs to maintain its external @types/faker package.
6. Created a public Twitter account for communicating with the community.
7. Released the first official Faker documentation website....

Faker has never had an official docs website and the awesome Jeff Beltran has been maintaining a project called "Un-Official faker.js Documentation" for the last 3 years.

He gave us permission to re-use his work to create fakerjs.dev

8. Cleaned up tooling like Prettier, CI, Netlify Deploy Previews, and GitHub Actions.
9. Done a TON of issue triage and many, many PR reviews.
10. We've gotten in contact with the Open Collective and discussed a transition plan for the project.

We fully intend to extend Faker, continuously develop it, and make it even better.

As such, we will work on a roadmap after we release 6.x and merge all of the TypeScript Pull Requests in the next week....

We're now turning Faker into a community-controlled project currently maintained by eight engineers from various backgrounds and companies....

We're excited to give new life to this idea and project.

This project can have a fresh start and it will become even cooler.

We felt we needed to do a public announcement because of all of the attention the project received in the media and from the community.

We believe that we have acted in the way that is best for the community.
According to the announcement, they've now also forked the funding so the project's original sponsors can continue to support the community-driven development in the future, while the original developers Marak and Brian "were able to retain the $11,652.69 USD previously donated to the project."

Friday the official Twitter account for the new community project announced "It's been a week. We've merged all of the active forks. Currently at 1532 stars. Looks like everything is settling." [It's now up to over 1,800 stars.]

One of the new maintainers has posted on Twitter, "I'm just grateful to the faker community that willed itself into existence and stepped up."

What happened after a developer intentionally corrupted two of their libraries which collectively had more than 20 million weekly downloads and thousands of dependent projects?

Mike Melanson's "This Week in Programming" column reports: In response to the corrupted libraries, Microsoft quickly suspended his GitHub access and reverted the projects on npm.... While this might seem like an open and shut case to some — the developer committed malicious code and GitHub and npm did what it had to do to protect its users — a debate broke out around a developer's rights to do what they wish with their code, no matter how many projects and dependencies it may have.

"GitHub suspending someone's account for modifying their own code in a project they own however they want spooks me a lot more than NPM reverting a package," [tweeted one company's Director of Engineering & Technology]. "I kind of love what Marak did to make a point and protest to be honest."

An article on iProgrammer further outlines the dilemma present in what might otherwise seem like a clear-cut case.... "Yes, it is open source in that you can fork it and can contribute to it but does this mean that GitHub is justified in denying you the right to change or even destroy your own code?"

As of last night, however, it would appear that the entire affair is merely one for intellectual debate, as GitHub has indeed lived up to what some might view as its end of the bargain: the developer's account is active, he has been allowed to remove his faker.js library on GitHub (depended upon as it might be), and has since offered an update that he does "not have Donkey Brains".

"Users of popular open-source libraries 'colors' and 'faker' were left stunned after they saw their applications, using these libraries, printing gibberish data and breaking.." reports BleepingComputer.

"The developer of these libraries intentionally introduced an infinite loop that bricked thousands of projects that depend on 'colors and 'faker'." The colors library receives over 20 million weekly downloads on npm alone, and has almost 19,000 projects depending on it. Whereas, faker receives over 2.8 million weekly downloads on npm, and has over 2,500 dependents....

Yesterday, users of popular open-source projects, such as Amazon's Cloud Development Kit were left stunned on seeing their applications print gibberish messages on their console. These messages included the text 'LIBERTY LIBERTY LIBERTY' followed by a sequence of non-ASCII characters... The developer, named Marak Squires added a "new American flag module" to colors.js library yesterday in version v1.4.44-liberty-2 that he then pushed to GitHub and npm. The infinite loop introduced in the code will keep running indefinitely; printing the gibberish non-ASCII character sequence endlessly on the console for any applications that use 'colors.' Likewise, a sabotaged version '6.6.6' of faker was published to GitHub and npm....

The reason behind this mischief on the developer's part appears to be retaliation — against mega-corporations and commercial consumers of open-source projects who extensively rely on cost-free and community-powered software but do not, according to the developer, give back to the community. In November 2020, Marak had warned that he will no longer be supporting the big corporations with his "free work" and that commercial entities should consider either forking the projects or compensating the dev with a yearly "six figure" salary....

Some dubbed this an instance of "yet another OSS developer going rogue," whereas InfoSec expert VessOnSecurity called the action "irresponsible," stating: "If you have problems with business using your free code for free, don't publish free code. By sabotaging your own widely used stuff, you hurt not only big business but anyone using it. This trains people not to update, 'coz stuff might break."

GitHub has reportedly suspended the developer's account. And, that too, has caused mixed reactions... "Removing your own code from [GitHub] is a violation of their Terms of Service? WTF? This is a kidnapping. We need to start decentralizing the hosting of free software source code," responded software engineer Sergio Gómez.
"While it looks like color.js has been updated to a working version, faker.js still appears to be affected, but the issue can be worked around by downgrading to a previous version (5.5.3)," reports the Verge: Even more curiously, the faker.js Readme file has also been changed to "What really happened with Aaron Swartz...?"

Squires' bold move draws attention to the moral — and financial — dilemma of open-source development, which was likely the goal of his actions.

In 2020 Microsoft's GitHub acquired NPM (makers of the default package manager for Node.js). The company's web page boasts that npm "is a critical part of the JavaScript community and helps support one of the largest developer ecosystems in the world."

But now BleepingComputer reports on two security flaws found (and remediated) in its software registry. Names of private npm packages on npmjs.com's 'replica' server (consumed by third-party services) were leaked — but in addition, a second flaw could've allowed attackers "to publish new versions of any existing npm package that they do not own or have rights to, due to improper authorization checks."

In a blog post this week GitHub's chief security officer explained the details: During maintenance on the database that powers the public npm replica at replicate.npmjs.com, records were created that could expose the names of private packages. This briefly allowed consumers of replicate.npmjs.com to potentially identify the names of private packages due to records published in the public changes feed. No other information, including the content of these private packages, was accessible at any time. Package names in the format of @owner/package for private packages created prior to October 20 were exposed between October 21 13:12:10Z UTC and October 29 15:51:00Z UTC. Upon discovery of the issue, we immediately began work on implementing a fix and determining the scope of the exposure. On October 29, all records containing private package names were removed from the replication database. While these records were removed from the replicate.npmjs.com service on this date, the data on this service is consumed by third-parties who may have replicated the data elsewhere. To prevent this issue from occuring again, we have made changes to how we provision this public replication database to ensure records containing private package names are not generated during this process.

Second, on November 2 we received a report to our security bug bounty program of a vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization. We quickly validated the report, began our incident response processes, and patched the vulnerability within six hours of receiving the report.

We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file. This discrepancy provided an avenue by which requests to publish new versions of a package would be authorized for one package but would actually be performed for a different, and potentially unauthorized, package. We mitigated this issue by ensuring consistency across both the publishing service and authorization service to ensure that the same package is being used for both authorization and publishing.

This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously. However, we can say with high confidence that this vulnerability has not been exploited maliciously during the timeframe for which we have available telemetry, which goes back to September 2020.
BleepingComputer adds: Both announcements come not too long after popular npm libraries, 'ua-parser-js,' 'coa,' and 'rc' were hijacked in a series of attacks aimed at infecting open source software consumers with trojans and crypto-miners. These attacks were attributed to the compromise of npm accounts [1, 2] belonging to the maintainers behind these libraries.

None of the maintainers of these popular libraries had two-factor authentication (2FA) enabled on their accounts, according to GitHub. Attackers who can manage to hijack npm accounts of maintainers can trivially publish new versions of these legitimate packages, after contaminating them with malware. As such, to minimize the possibility of such compromises from recurring in near future, GitHub will start requiring npm maintainers to enable 2FA, sometime in the first quarter of 2022.

Microsoft said Wednesday that Nat Friedman, CEO of the company's GitHub subsidiary that provides software for storing source code, is stepping down. Thomas Dohmke, GitHub's product chief will replace him. CNBC reports: "As Chief Product Officer, I'm proud of the work our teams have done to bring new capabilities to GitHub Codespaces, Issues, Copilot, and many of the 20,000 improvements that we shipped last year," Dohmke wrote in a blog post. "Together, we've built a roadmap that will transform the developer experience for open source maintainers and enterprises using GitHub for years to come." Dohmke takes over for Friedman on Nov. 15.

Friedman is "very excited to go back to my startup roots to support and invest in the builders who are creating the world of tomorrow," he wrote in a tweet. He will be an advisor to both GitHub and Microsoft, Scott Guthrie, executive vice president for Microsoft's cloud and artificial intelligence group, wrote in an email to employees. Dohmke first registered as a GitHub user in 2009, not long after its founding in 2008. He was co-founder and CEO of app-testing software start-up HockeyApp, which Microsoft acquired in 2014. He moved to GitHub at the time Microsoft closed the GitHub acquisition in 2018. Dohmke "led the GitHub acquisition process on the Microsoft engineering side from the deal signing to the successful acquisition close," Guthrie wrote in his email. Dohmke later led the acquisitions of Npm, a code-distribution start-up, and Semmle, a start-up whose software helps organizations analyze code to uncover security issues, Guthrie wrote.

Threatpost reports on "another vast software supply-chain attack" that was "found lurking in the npm open-source code repository...a credentials-stealing code bomb" that used the password-recovery tools in Google's Chrome web browser. Researchers caught the malware filching credentials from Chrome on Windows systems. The password-stealer is multifunctional: It also listens for incoming commands from the attacker's command-and-control (C2) server and can upload files, record from a victim's screen and camera, and execute shell commands...

ReversingLabs researchers, who published their findings in a Wednesday post, said that during an analysis of the code repository, they found an interesting embedded Windows executable file: a credential-stealing threat. Labeled "Win32.Infostealer.Heuristics", it showed up in two packages: nodejs_net_server and temptesttempfile. At least for now, the first, main threat is nodejs_net_server. Some details:

nodejs_net_server: A package with 12 published versions and a total of more than 1,300 downloads since it was first published in February 2019...finally upgrading it last December with a script to download the password-stealer, which the developer hosts on a personal website. It was subsequently tweaked to run TeamViewer.exe instead, "probably because the author didn't want to have such an obvious connection between the malware and their website," researchers theorized...

ReversingLabs contacted the npm security team on July 2 to give them a heads-up about the nodejs_net_server and tempdownloadtempfile packages and circled back once again last week, on Thursday, since the team still hadn't removed the packages from the repository. When Threatpost reached out to npm Inc., which maintains the repository, a GitHub spokesperson sent this statement: "Both packages were removed following our investigation...."

From today's edition of Mike Melanson's "This Week in Programming" column: If you've been using open source software for any amount of time, then you're well aware of the tangled web of dependencies often involved in such projects. If not, there's any number of tools out there that explore just how interconnected everything is, and this week Google has jumped into the game with its own offering — an exploratory visualization site called Open Source Insights that gives users an interactive view of dependencies of open source projects.

Now, Google isn't the first to get into the game of trying to uncover and perhaps untangle the dizzying dependency graph of the open source world, but the company argues that it is more so trying to lay everything out in a way that developers can see, visually, just how, well, hopelessly screwed they really are.

"There are tools to help, of course: vulnerability scanners and dependency audits that can help identify when a package is exposed to a vulnerability. But it can still be difficult to visualize the big picture, to understand what you depend on, and what that implies," they write.

The Open Source Insights tool — currently "experimental" — gives users either a table or graphical visualization of how a project is composed, allowing them to explore the dependency graph and examine how using different versions of certain projects might actually affect that dependency graph. One of the benefits, Google notes, is that it allows users to see all this information "without asking you to install the package first. You can see instantly what installing a package — or an updated version — might mean for your project, how popular it is, find links to source code and other information, and then decide whether it should be installed."

Currently, the tool supports npm, Maven, Go modules, and Cargo, with more packaging systems on the way soon...

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