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

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

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

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

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

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

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

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

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

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

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

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

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

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

GitHub issued a security alert Friday.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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