Disclaimer: The author is completely responsible for the content of this article. The opinions expressed are their own and do not represent IEEE’s position nor that of the Computer Society nor its Leadership.
First of all, I need to preface this article with how much I abhor the current conflict in Ukraine and I wholeheartedly support the sanctions. However, I think the conflict has spilled over into areas of software development that have got some unintended consequences attached.
As part of this post, I’m going to look 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, a change in code/license in a community terraform module to insult Putin.
Want More Tech News? Subscribe to ComputingEdge Newsletter Today!
MongoDB Cutting Off Russian Customers
MongoDB is a company and in order to comply with sanctions, they have decided to cut off Russian customers. I think there’s a bit of inconsistency in the tech sector on whether a SaaS offering and paying a subscription is tantamount to a new sale, but I think that is in the spirit of the sanctions – making it difficult for Russian companies to operate. Mongo is a commercial entity and as such can choose who to sell its wares. I don’t think there are any restrictions on running an instance of Mongo in your own kit.
While I agree with this, it does pose an interesting question. What would happen to your organization if a service provider disappeared?
Note, I do not think that this means that we should all rush to build our own data centers, writing our own databases, and running all our own services. The simplification and optimization of using Software as a Service should not easily be dismissed.
However, it does not hurt to be prudent and do a threat assessment of what would happen if the service disappears. Again, I do not think that this should be taken as an incentive to run everything in multi-cloud, as I happen to think the overall increase in complexity would actually reduce reliability.
Node Library Deleting All Files on Russian IPs
A bit more sinister is this story – under the moniker “protestware,” the peacenotwar dependency was injected into dependencies that affected Vue.js CLI (and Unity by some reports). peacenotwar checks the IP address of the computer it is running on, and if it is deemed to be inside Russia, deletes all files.
Now, supply chain attacks against node modules are nothing new. Not many months go by without a story about a hijacked node module installing backdoors or cryptominers. I think it is safe to say everyone agrees that these attacks are malicious and the actions are those of criminals.
With this idea of “protestware,” it becomes morally a little bit ambiguous. I think this feels a little bit of a problem of recent times where because of Brexit or Trump, political discourse has turned to be very divisive and tribal.
You are either with us or against us.
In my mind, the term “protestware” is attempting to legitimize the malicious actions and very much turns open source libraries into weapons to be aimed and fired at your opponent. I do think that these actions are to be condemned – especially as the “delete files based on geofencing IP addresses” has got the potential of causing collateral damage.
I don’t know how much truth there is in the issue raised on the peacenotwar repository that an American NGO lost 30,000 files documenting Russian war crimes – but it should be remembered that geo-location is not always right.
Anecdotal evidence of misidentification of IP addresses makes this a very indiscriminate weapon. And I have to ponder, if mass-bombing of civilian targets by Russia’s armed forces is to be abhorred, blanket wiping files in the Russia IP range is not exactly a targeted action.
Putin Khuylo
Last but not least, I’d like to look at a story that community terraform modules for AWS have been updated to include political statements.
First, there was a change to the license “Additional terms of use for users from Russia and Belarus.”
By using the code provided in this repository you agree with the following:
- Russia has illegally annexed Crimea in 2014 and brought the war in Donbas followed by a full-scale invasion of Ukraine in 2022.
- Russia has brought sorrow and devastation to millions of Ukrainians, killed hundreds of innocent people, damaged thousands of buildings, and forced several million people to flee.
- Putin khuylo!
In addition, this acceptance was included in the code:
1
2
3
4
5
|
variable "putin_khuylo" {
description = "Do you agree that Putin doesn't respect Ukrainian sovereignty and territorial integrity? More info: https://en.wikipedia.org/wiki/Putin_khuylo!"
type = bool
default = true
}
|
Setting the variable to false means the terraform module will not work.
Now, I think this is problematic on two fronts.
1. I don’t think this can be classed as open source anymore.
The definition of an Open Source License is quite clear:
5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons.
I don’t really want to have to read through each of my dependencies and transitive dependencies licenses to determine whether I am agreeing to discriminatory terms by using a library.
Where does it end?
- What about a license that demands you refrain from/support eating meat?
- What about a license that demands you are pro-life/pro-choice?
- What about a license that demands you vote Democrat/Republican?
It is quite undesirable to politicize and weaponize open source that way. Depending on what kind of organization you work with, it might be completely unacceptable and outside the permission for an engineer to agree to these kinds of contracts.
I can’t imagine that a government agency would want to discover that the software they’re using is mandating some kind of political stance.
2. I don’t think this can be enforced anyway
This article argues that it is not practical to encode morality into licenses, as it would either be ignored or forked anyway.
The JSON license, “The Software shall be used for Good, not Evil,” is unenforceable, and the licenses are designed with clause 6 in mind, “No Discrimination Against Fields of Endeavor,” in order to avoid license traps from downstream dependencies.
In my opinion, the result of the putin_khuylo change is that this terraform AWS module can no longer fulfill either of those clauses and therefore can no longer be classed as open source.
The author of the change discussed this on Hacker News and it has since changed the name of this AWS terraform to be “Additional Information” rather than “Additional Terms and Conditions,” but the putin_khuylo code change remains in the module.
In my opinion that should raise eyebrows, if not red flags, about the “safety” of these components. It looks like these changes were made straight into the master branch without pull requests – that does suggest a lack of review process. These actions have negatively impacted the trust in the maintainers. And that makes me wonder whether using those components is safe.
Furthermore, from a licensing perspective, some organizations have guidelines of what licenses are permitted, so changing a license could be quite risky. In addition, if it can be argued that the code breaks the spirit of the license, would it still be safe to use it? Some war stories about frantically removing “infectious” GPL’d libraries make me think the lawyers might have a field day.
What to Do?
Now, if trust is gone, there are only the following options:
- Find a different library (easier said than done);
- Manually review the code for every commit (that means a lot of work – might not be practical if the license has changed);
- Or, fork the library (maintaining libraries is expensive and a huge commitment).
The problem with dependencies in modern software engineering is that only the biggest organizations have the resources to write all their own libraries (e.g. Google, Goldman Sachs, etc).
Most organizations simply do not have the capacity to write everything from scratch – and for good reason. The whole point of open source is collaboration and re-use, there has to be some trust.
Dependencies and supply chain attacks are a big thing. And yes, some people advocate dependency scanning and version pinning, but I don’t think it is possible to use open source libraries at scale without a certain amount of trust.
I’m working in an organization where there are hundreds of teams and thousands of microservices. I’m trying to think about how we can assess the risk of thousands of dependencies and millions of lines of code.
Without trust, the only way that’s possible is to fork all libraries, prevent open source, and generally kill off any agility and velocity.
My problem is that this weaponization 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 organizations 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 becoming collateral damage.
About Gerald Benischke
Gerald Benischke is a UK-based software engineering consultant, and over the last 20 years has worked in the public, financial, and telecom sectors with clients including Barclays, HMRC, and MBNA. His primary interests include middle-tier services, databases, security, automation, and functional programming.
Do you have another perspective on the topic shared in this article? Let us know by filling out our guest blog form and share a few points you’d like to address. Complete the form here.
