In the wake of the story “Backdoor in one of the dependencies of the EventStream library” - approx. per.

As a longtime supporter of FOSS, I am extremely depressed by what has happened in the past few years with different FOSS communities (with some exceptions, of course).

Consider one of the latest episodes in the open source industry saga, which has no idea what it does in general:

This is not a unique case. Most likely, in your dependencies there are many other modules abandoned by the authors. I did not write this code for altruism, but for entertainment. I studied, but learning is fun. I published it because it was easy to do and because code sharing also helps to learn. I think most of the small modules on npm are created for the same reasons. However, it was a long time ago. Since then, I have moved from this module to another, and then to another, and now in the process of transition from it. I wrote much better modules than this one, the Internet just didn’t fully catch up.

- @dominictarr, in the backdoor application in the event-stream library

TL; DR: Tarr declined to support his popular node.js package. No normal user wanted to take support, even those who used the library in their projects. Tarr handed the package to a “useful” stranger, who immediately monetized him using the theft of cryptocurrency. Opinions of the public are divided.

Probably, the “useful” stranger had a good day. But for Tarr is not very. On which a lot of shit fell from all over the Internet for transmitting a package to a stranger without checking. It is completely incomprehensible to me how he could make the transfer in a 100% safe way, but let's assume that this is possible.

But this means that the author of any FOSS package or application, after publishing it on the Internet, accepts responsibility for any unauthorized use of the specified software. At least until the author can diligently and solemnly transfer this responsibility to someone else, like a hot potato.

As it is done in the corporate world.

Such logic quickly leads us into a dead end, because the publication of even a small piece of code becomes unprofitable.

Let's conduct a mental experiment. Suppose that Tarr himself decided to add a new “function” of the crypto miner to his own package. Damn, after all, this is just one of many ways to monetize FOSS. I agree that this will not look good in his resume, but the most interesting thing is that such actions are completely legal. It is also possible that if everything is done correctly, no one will notice anything for a long time.

So what does this mean? This means that at any moment in time any FOSS maintainer can replace its code with anything, be it a crypto-miner or console.log("ur mom, lol")make it unavailable permanently or only on Tuesdays and full moons, as well as with any property, transfer it to someone, not asking your opinion.

On the other hand, you, an advanced user of FOSS, endowed with the power of binary copying and the four freedoms of the GPL, say: “Well, not today” and get your own, correct copy of the software, make the necessary changes and then, if you want, publish this modified version of the code.

But no one has time for this, right? We need to release some trendy new web applications. There is no time to read the entire code with 40,000 dependencies, if we don’t have time even for our unit tests. No, these FOSS maintainers must adhere to higher standards in order for us to trust them more! How dare they give a damn about us ?!

That's the problem:

FOSS never talked about trusting maintainers.

For a start it was not necessary to trust them.

The code is the only thing you can trust if you want to know what the program is doing, what is happening with the business, or why your system is not the same one that was originally created.

The code is the only thing you can trust. Without reading it, you have lost the most important advantage of this ecosystem: the ability to distrust the authors in terms of behavior or immutability of the code.

You want to download thousands of lines of useful, but random code from the Internet for free, run it on a production web server or, even worse, on your user's machine, trust the data of your paid users to this code and enjoy the success. We all love that. But you do not want to check the license and understand the software on which you work, and still blame the people who provide your business when mistakes happen without giving them anything in return? This is both incompetence and your right.

But how does this differ from the use of proprietary software? If you are not going to make full use of FOSS, can you better spend your money on support? At the very least, you can complain until blue. Maybe you can even sue someone!

Your system is your responsibility and you owe it to your users, especially if they pay. This responsibility does not change when you decide to take someone’s code in order not to write it yourself, especially free of charge. This does not mean that the FOSS ecosystem does not benefit from a high degree of trust (it does), but it can work and work normally without this new concept of trust, because we are used to doing everything in a difficult way: trust by checking, modifying and then compiling .

I could be wrong, but in millions of event-stream downloads, and these are 1500 dependent packages, there should be at least five companies that could allocate 1 developer hour per week to support event-stream.

De facto proprietary software

That's what upsets me the most.

We may have reached the stage when FOSS is no longer what it used to be, simply because it is too much. Too many lines of code, too many competing solutions, too fast changes. We want security updates to come straight from upstream, but how are we going to audit every week?

In such circumstances, it is not surprising that some accents are shifting towards trust. The FOSS ecosystem greatly benefits from a solid base of trust, because it allows you to distribute work.

But in reality this is not trust. Currently, it is hope and wishful thinking.

I use a lot of Linux distributions. Of course, I cannot single-handedly check the entire kernel, especially the rest of the code, patches and build scripts for all packages for all these distributions. I audit only those parts that interest me the most, and I hope that: 1) distribution maintainers do not act out of malicious conquests; 2) if so, someone else will inspect parts that I have not looked at; 3) if someone is interested in the same parts as me, he will catch the bugs that have escaped me.

This paints a grim picture of the future, when the number of lines of code or patches is far ahead of the growth in the number of developers and maintainers.

How to avoid it?

Arguments for clear software

We have to simplify the software. Make it a lot easier. And companies that offer their services on the basis of open source software should be more involved in maintaining this ecosystem.

Here is another thought experiment: can a new (but experienced) developer understand, within 2 weeks (80 hours), 80% of the code base for which he will be responsible?

If not, then this person is overloaded with work from day one, since he is by definition not able to transfer his duties within the standard US time period. If he leaves, you will not be able to prepare a replacement in due time. As a result, a smooth transition is impossible, and some knowledge of the subject area will inevitably be lost.

You can change the above figures for specific countries, but the basic premise remains the same. In no other industry, people are not allowed to work with things that they do not understand, much less develop them.

Software must be understandable. The essence of FOSS comes down to one fundamental right: the right to refuse to execute code on my machines, which I cannot understand . That's all.

Of course, there are advantages of information security, economic benefits and some others that I can not remember right now. But if you are trying to prove that for my country's online tax return system, it is normal to require Adobe Flash and transfer this overloaded opaque blob to my browser, then you will get the answer “public money, public source code”, with astonishment meaning “mother God, how you breathe. "

I am not fundamentally against closed source software, but only if it is running on someone else’s computer.

However, we see that the availability of source code is not enough to ensure clarity. Therefore, it is imperative that the software industry slow down a little with the fireworks of new functions, and pay more attention to the stability, security, user privacy and understanding of their own systems that underlie everything. This is the absolute minimum that a responsible company can do, especially if it happily takes money from people for its “services”.

And if the “services” mentioned are based on FOSS from individuals, then consider the possibility of supporting these people. In the end, they support you. They can’t complain if you don’t support them, but you can’t complain when something goes wrong.