When I started working on Meson I had several goals: portability, performance, usability and so on. I particularly liked the last one of these, but to my surprise this interest was not shared by people at large, especially those who used Autotools. Eventually the discussion always degenerated with them saying some variant of this:
It does not matter that Autotools is implemented as a mixture of five different scripting languages mismashed together. It works, so why replace it with something that is, at best, a tiny bit better?
One person went so far as to ask me (in public in front of a crowd) why making builds faster is even a thing to waste effort on? Said person followed this by saying he began his every working day by starting a build and going to brew some coffee. When he came back to his computer everything was ready to start programming.
It annoyed me to no end that I did not have a good reply to these people at the time. Unfortunately a thing happened last week that changed this.
The XZ malicious code injection incident.
It would be easy to jump on a bandwagon and blame Autotools for the whole issue and demand it to be banned as an unfixable security vulnerability [1] and all that. But let's not do that. Instead let's look at the issue from a slightly wider perspective.
Take any project you are working on currently. It can either be a work project or an open source one. Now think about all the various components it has. Go through them one by one in your mind. Pause at each one. Ponder them. Does any one of them immediately conjure up the following reaction in your mind:
I'm not touching that shit!
If the answer is yes then congratulations, you have found the most likely attack vector against the project. Why? Because that part that is guaranteed to have the absolute worst code reviews for the simple reason that nobody wants to touch it with a ten foot pole [2]. It is the very definition of someone else's problem. In the case of Autotools the problem is even worse, because there are no tools to find bugs automatically. Static analysis? No [3]! Linters? No! Even something simple like compiler warnings? Lol no! The reason they don't exist is exactly the same as above: the whole problem space is so off-putting that even the people who could do something about it prefer to work on something more meaningful instead. Badness begets more badness and apathy. The fact that it does not halt and catch fire most of the time is seen as sufficient quality.
This is even more of a problem for open source projects. Commercial projects pay people a full living salary to deal with necessary non-glamorous work like this. Volunteer based open source projects can not. A major fraction of the motivation for contributing on an open source project is to work on something that is somehow "cool", "fun" or "interesting". Debugging issues caused by incorrect M4 substitutions somewhere in the guts of a ten layer deep sed/awk/grep/Make/xargs/subshell pipeline is not that.
The reports I have read do not state whether XZ's malicious payload was submitted PR or not, but let's do a thought experiment. Assume that you are the overworked maintainer of an open source project that gets a PR that changes a bunch of M4 files with a description "fixes issue X in Y". What would you do? If you are honest with yourself, you'd probably do the same thing I'd do: merge it in while thinking "I'm just glad someone else fixed this so I don't have to touch that shit [4]".
Thus we find that aesthetics and beauty in fact play a vital role in security, because those systems make people want to work on them. They attract eyeballs. There is never a risk of getting stuck maintaining some awful piece of garbage because you touched it last so it's your responsibility now [5]. Beauty truly is the mother of security, or, as the ancient romans used to say:
Pulchritudo mater securitatis! [6]
[1] Which you still might choose to do.
[2] For a more literal example, several "undefeatable" fortresses have been taken over by attackers entering via sewage pipes.
[3] And not only because all the languages in question are dynamic.
[4] Yes, I have done this with Meson. Several times. Every maintainer of even moderately popular open source project has done the same. Trying to deny it is not productive.
[5] This is especially common in corporations with the added limitation that you are not allowed to make any major changes to avoid breaking things. If you ever find yourself in this situation, find employment elsewhere sooner rather than later. Otherwise your career has reached a dead end you can't escape.
[6] At least according to Google translate, which is good enough for our modern post-truth world.
I went to the extent of signing in with Google and even created a blogger account so I can post this!
ReplyDeleteJussi you are on the right path mentally. You are looking to improve on something because it helps the wider community and in turn it will make it easier for others to build on top of that work as it'll be easier to do.
One of the biggest issues on the internet as whole, but especially in the Linux world, are people constantly trying to poo-poo on others, whether its where you spend your energy working on projects, or the choice of tools you use to complete the job. It's easy to take the attitude of trying to belittle other people and their decisions. It takes more effort and a risk to your dignity to actually try listening to someone's idea without judgement and admit they are doing good work. People seem to think that just because it wasn't their choice, what you are doing is wrong.
Stick to the work you are doing, enjoy it, learn from it and don't feel you need to explain yourself to someone. You are a game changer. And yes, Aesthetics matter a lot.
Thank you.
DeleteWhat a true write-up. Thanks for sharing your code. Let us hope many, many developers are going to read it, spread the idea, and act accordingly.
ReplyDelete