Why developers sabotage their own code – MovieUpdates

When attacks are fought and hijackings of legitimate software on open source registries such as npm were not challenging enough, app makers are increasingly experiencing the consequences of software self-sabotage. A developer can change their mind on a whim and do whatever they want with their open source code that usually comes “as is” with no warranty whatsoever. Or, as evidenced by a growing trend this year, developers are deliberately sabotaging their own software libraries as a means of protest – turning software into “protestware.”

In July, the developer of the widely used atomic writes Python library Markus Unterwaditzer has temporarily removed its code from the popular code registry PyPI after the site said it would require two-factor authentication for administrators of “critical projects” – projects that fell in the top 1% of all downloads in the registry. Unterwaditzer’s atomic writes project met the criteria and his account had to be enrolled for two-factor authentication, something he described in a post as “an annoying and rightful move to ensure SOC2 compliance for a handful of companies (at the expense of my free time)” who are at his trust code.

Some compared this to the 2016 Left Path incident that briefly broke much of the internet after the project’s developer removed its widely used code in protest. Developer Azer Koçulu faced a trademark dispute with messaging app Kik because his npm package was called ‘kik’. After npm sided with Kik in the dispute, Koçulu withdrew all of its code – a total of 273 modules, including the hugely popular left path library — from the npm registry. It was completely in his power to do, but it immediately caused problems. At the time, the hugely popular left path package had garnered more than 15 million downloads, and even today the library is still downloaded millions of times a week. As such, in March 2016, developers around the world were confused — and appalled — when their projects broke as the… left path component that their applications relied on could no longer be found.

What may have seemed an isolated protest years ago was revived in 2022 by developers sabotaging their own libraries — sometimes to speak out against big business, but more recently to protest Russia’s invasion of Ukraine.

The recent rise of protestware

One week in 2022, thousands of applications that depend on the widely used npm projects colors and fake broke and started printing nonsensical text on users’ screens. It was not a malicious actor who hacked and modified these legitimate libraries. It turned out that the developer of the project, Mark Squires, had deliberately corrupted his own work in order to send a message of protest to major corporations.

Squires’ protest was prompted by the Log4Shell security flaw that burdened Log4j project managers, mostly open source volunteers, with patching the critical vulnerability over the December holiday. Squires had previously expressed frustration with Fortune 500 companies using his open source code for free without providing financial support or sponsoring their maintenance. The vulnerability of Log4Shell only reinforced that feeling – that the companies that widely rely on Log4j in their applications have not done enough to support the unpaid volunteers who support these critical projects in their spare time.

While the Squires protest only briefly froze projects that depend on the… colors library, followed months later a whole trend of protestware, with developers sabotaging their own projects, which they had spent hundreds of hours on, to object to the Russian war in Ukraine.

In March 2022, weeks after Russian troops entered Ukrainian territory, the popular NPM project began node-ipc – downloaded more than a million times a week – began to wipe the machines of suspected Russian and Belarusian developers. The project’s developer, Brandon Nozaki Miller, allegedly sabotaged the code to damage the computers it was installed on. Needless to say, the sabotaged versions of node-ipc – now basically malware – were removed from the npm registry.

Since then, the theme of the protestware has evolved towards developers indulging in more peaceful protest. Newer versions of open source projects like event-source-polyfill, es5-extand stylized components simply display a message urging Russian-based users to take action against the war. As such, these versions remain at npm as they do not violate registry policies.

Publishing protestware may not be an easy decision for the developer either. It puts extra scrutiny on all versions of the sabotaged project and can damage the community’s trust in the developer. Can the software they create, past or future, ever be trusted?

Evan Jacobsone of the main administrators behind stylized components, told MovieUpdates that his project has a history of activism, “particularly our support for the” [Black Lives Matter] movement and recommendation to our users to consider donations to the Equal Justice Initiative.” He added: “I had heard that the Russian government was beginning to censor Western news websites and realized we had a unique opportunity to deliver a concise, informational message through an atypical channel: our npm package installations.”

A screenshot from the nestjs-pino project on npm, which shows a photo of Ukraine in wartime with the caption: "War in Ukraine Children wait in an air raid shelter in Mariupol, Ukraine."

A screenshot from the nestjs-pino project on npm, which prominently features a photo of children waiting in an air raid shelter in Mariupol, Ukraine. Image Credits: MovieUpdates / Screenshot.

Jacobs felt it was crucial that Russians receive accurate news about the war that is free from state interference. He changed stylized componentswhich had more than 15 million monthly downloads in April, to display a bilingual message to Russia-based users summarizing the “many atrocities committed by the Russian military in Ukraine”.

“Has it made an impression? We’ll probably never know,” Jacobs said. “Having said that, I think it was absolutely worth the opportunity to spread the word and hopefully get the attention of software folks in Russia who might not otherwise have seen what was happening.”

Another developer, Mariusz Nowak, creator of the es5-ext project, modified later versions of the library to redirect users in Russia and Belarus to accurate news sources such as the BBC’s Tor service. Nowak told MovieUpdates about the decision to change the code, saying it was because Russians “don’t know exactly what’s going on and they’re under the influence of their propaganda media,” referring to the strict state control over Russian media. . “This message only shows up if you’re installing software in Russia, it’s not really visible to other parts of the world,” Nowak said.

Nowak said using his open source library for activism didn’t affect his credibility with the wider community, but he did get a handful of angry responses at first.

Jacobs and Nowak aren’t the only ones adapting their open source code to protest the war. Software supply chain security startup Socket told MovieUpdates that: nestjs-pino, a popular NPM project with more than 100,000 weekly downloads, has updated its main “readme” file to draw attention to the ongoing crisis in Ukraine. An installation script included with the package also prints a console message once installed.

‘You can’t trust what you can’t verify’

Open source developers are discovering new and creative avenues that no longer limit them to implementing new features for their projects, but to actively voice their opinion on greater social issues by tailoring their projects for a purpose. And, unlike proprietary code that has to function in accordance with a paying customer’s expectations, most open source licenses are quite permissive – for both the consumer and the developer – and offer their code with licenses that do not warrant any guarantees. about what a developer should not expect to do and never will do with their code, making protestware a gray area for defenders.

As a security researcher at Sonatype, I even saw how protestware presented a challenge to us in the early stages and how we would adapt our automated malware detection algorithms to now absorb self-sabotage with projects like colors and fake. Traditionally, the system was designed to recognize typosquatting malware uploaded to open source repositories, but instances such as malicious hijacks or developers modifying their own libraries without warning required a deeper understanding of the intricacies of how protestware works.

The theme has also put major open source registries like npm — owned by GitHub, a Microsoft subsidiary — at a crossroads when dealing with these edge cases.

Socket founder Feross Aboukhadijeh told MovieUpdates that registries like GitHub are in a difficult position. “On the one hand, they want to support administrators’ right to freedom of expression and the ability to use their platform to support the causes they believe in. But on the other hand, GitHub has a responsibility to npm users to ensure that malicious code is not served from npm servers. It is sometimes a difficult balancing act,” says Aboukhadijeh.

An easy solution to make sure you only get controlled versions of a component in your build is to pin your npm dependency versions. That way, even if future versions of a project are sabotaged or hijacked, your build will continue to use the “pinned” version instead of fetching the latest, corrupted version. But this may not always be an effective strategy for all ecosystems, such as PyPI, where existing versions of a component can be republished – as we saw in the case of the hijacking of the ctx PyPI project.

“The conversation around ‘protestware’ is really a conversation about the security of the software supply chain. You can’t trust what you can’t verify,” Dan Lorenc, the co-founder and chief executive of Chainguard, a startup specializing in software supply chain security, told MovieUpdates.

Lorenc’s advice against protestware prevention is to follow good open source security hygiene and best practices that can help developers develop protestware more easily and early. “Knowing and understanding your dependencies, performing regular scans and audits of open source code you use in your environments is a start.”

But Lorenc cautions that the debate over protestware could attract copycats that would contribute to the problem and deter open source software defenders from focusing on tackling what really matters: keeping malicious actors at bay. And with protestware, there remain unknown unknowns. Which problem is too small – or too big – for protestware?

While no one can practically dictate what an open source developer can do with their code, it’s a power developers have always had, but are just now beginning to harness.

Show Love ❤️