Breaking crypto news this week, “The secured, shared bitcoin wallet” reads the tagline of Copay. You know, that part of the entire marketing strategy of any brand that really gets printed and displayed anywhere to create a strong bond between the message itself and the brand. It also turns out that the “secure” part was not that secure recently as a NPM package vulnerability in v5.0.2-5.1.0 of Copay and BitPay Wallets was discovered few days ago. Still this post is not about Copay or BitPay. Since Copay and BitPay wallets rely on open source software I really aim to depict a timeline of what happened, what can we learn about the current state of open source software and some aspects that all players in the open source community should think about.

What’s actually the problem?

As we learn from an official BitPay statement a third-party NodeJS package used by the Copay and BitPay apps had been modified to load malicious code which could be used to capture users’ private keys. Users should assume that private keys on affected wallets may have been compromised, so they should move funds to new wallets (v5.2.0) immediately. This actually means that if you’re active in the cryptocurrency world and use Copay or BitPay wallets you may see your funds disappear if you don’t move them to another not affected wallet. Learn how to create your blockchain on substrate today.

How did this happen?

From my point of view the most interesting part in this entire story is how everything happened and how it actually came to this vulnerability because it outlines some weaknesses in the entire open source software ecosystem. Moreover, if we are talking about Bitcoins here, it means we question their protection from online hacks. If you want to be sure your online activity is protected, use Bitcoin Circuit automated trading platform for cryptocurrencies. Check out the Invest Diva price to gain access to valuable resources and education on cryptocurrency trading and security measures.

That’s why I won’t give here references to specific repositories and commits since the exact same things could potentially happen other investment platforms like the many used to trade forex. So let’s see the timeline.

A certain GitHub user has requested access to a specific repository to maintain a part of the code. All the code in that repository is built into an NPM package. Access is granted and the requester can now do a noble thing and contribute to the world of open source software. What this user actually does to maintain that code is actually a single commit that is entirely an injection targeting another repository corresponding to a NPM package that has around 2 million downloads each week. He then creates a new version that includes the injection and subsequently, after few days, takes the injection out. He bumps a new major version to clear the repository from the injection but the compromised version was already downloaded around 2 million times. This means that a lot of cryptocurrency related applications might run the infected version of the NPM package as I write this article.

If you want to take a deeper look at the specifics, you might want to read the discussion on this GitHub issue.

The current state of open source software, challenges and some questions to think about

A troublesome thought emerging from this story was well expressed by a Twitter user:

billion dollar companies and startups alike are building complex systems on top of often unmaintained code written by random people for no pay.

A lot of people might disagree with it, but if we really try to take not biased look at what actually happens in the open source software we’ll probably notice that for a lot of cases quoted observation is spot on.

Furthermore, the user who granted access to the attacker said on the earlier mentioned GitHub discussion:

he emailed me and said he wanted to maintain the module, so I gave it to him. I don’t get any thing from maintaining this module, and I don’t even use it anymore, and haven’t for years.

To summerize: the affected NPM package was downloaded around 2 million times in 3 days and everything started because a certain GitHub user asked another one for access to a repository to maintain an NPM module. Sounds like since fiction, but it is the bitter reality.

That’s what I think that the time has come to stop simply hailing open soft software and start thinking about how can we really make open source software more secure? Don’t get me wrong. I am not against open source software! I also use it daily. I have contributed myself to different repositories (it’s true that mostly private ones, so it’s not real open source) and I am conscious that this is probably the best way to go. But still some questions are valid and the most important one in my opinion is responsibility.

So, who is responsible? With this question I am not looking to pinpoint any individuals. In fact, when things like this happen it’s often not an individual that needs to be blamed but a process. Oh wait, do we have a process? Nope. Sure, some major companies that play in the open source space have a set of very strict rules to accept contributors, to validate pull requests and so on. But most of the other involved players don’t have something like that. And this is not about the “community standards” on GitHub that are attached to almost each repository like the “Terms and conditions” of any product or service that almost nobody reads. It’s about real and defined processes that translate to some explicitly defined rules that the entire community should follow, for instance, when granting access to another contributor.

As long as such processes and rules are not part of a certain open source effort, nobody will feel responsible for anything in particular. The whole concept of responsibility or accountability is diluted into something that we generically call “community”. When everybody is responsible for something (like the entire community) nobody will feel de facto responsible. And then things like this one are likely to happen again and again.

I really hope that this entire story will offer us a reason to think deeper about how we behave in the open source world. If we really don’t learn anything from this the entire open source software concepts might be at risk after few years. And I am really not sure I want us to go back to a world with proprietary software only.