A recent security vulnerability — a potential ssh backdoor via the liblzma library in the xz package — is having a lot of analysis done on how the vulnerability was introduced, and [Rob Mensching] felt that it was important to highlight what he saw as step number zero of the whole process: exploit the fact that a stressed package maintainer has burned out. Apply pressure from multiple sources while the attacker is the only one stepping forward to help, then inherit the trust built up by the original maintainer. Sadly, [Rob] sees in these interactions a microcosm of what happens far too frequently in open source.
Maintaining open source projects can be a high stress activity. The pressure and expectations to continually provide timely interaction, support, and updates can easily end up being unhealthy. As [Rob] points out (and other developers have observed in different ways), this kind of behavior just seems more or less normal for some projects.
The xz/liblzma vulnerability itself is a developing story, read about it and find links to the relevant analyses in our earlier coverage here.
“Maintaining open source projects can be a high stress activity. The pressure and expectations to continually provide timely interaction, support, and updates can easily end up being unhealthy.”
Load distribution is usually how one deals with that.
Like distributing the load to a helpful person “Jia Tan” :)
Nobody wants to contribute effort to a package that works and isn’t seen as important, until it becomes a crisis. You can’t load balance if there’s nobody interested in being load-balanced to.
I’m sure xz will now see more support going forward, but how many other unknown but unexpectedly-critical packages languish out there, either supported by a skeleton crew (or maintainers whose oversight is divided among other projects) or outright abandoned?
Distros ship plenty of packages that have no maintainers at all. They probably wouldn’t put a lot of thought into it if someone stepped up with an offer to maintain them, or a fix to a bug. Maybe they will now, for the next year or so, but in 3 years? Five? Ten?
The real problem is that application/package maintainers normally only deal with very negative or time wasting people: complaints – fix your code it does not do what I dreamed it should do, issues with no details explanation exactly how to recreate the fault or people requesting insanely complex new functionality with use cases limited to very few people (noise from empty cans).
Generally when I see a problem I fix the problem, if I can, and push a patch (usually less than 10 lines of code) and in the issue explain the problem, and a quick easy to digest one line summary of how or why my patch fixes the issue. And then it is up the the owner to accept or reject my patch, I’m not bothered either way, either way I will have wasted little of their time. And that is the biggest headache.
This industry in general has worked too much with stress and pressure as a way to reach unproperly planned projects, so I’m afraid this should not surprise us.
“… what happens far too frequently in open source.”
This isn’t an open-source thing. “Provide help, gain trust and exploit” is a classical espionage strategy. I’m pretty sure, this also regularly happens with commercial software, it’s just more visible with open source stuff where you cannot easily sweep it under the carpet.
It regularly happens with *life*, period. The “con” in “con man” stands for confidence, after all.
This reminds me of that developer in Nebraska.
https://html.duckduckgo.com/html?q=xkcd+nebraska
https://xkcd.com/2347/
This is an OpenBSD add?
You choices are ‘latest and greatest’ or ‘rock steady on carefully selected 5 year old hardware.’
Part of the problem is having dozens of third-party dependencies in in even modest packages. It dilutes responsibility, and you also end up with a bunch single-maintainer lead dependencies instead of fewer dependencies with stronger teams. We need to reward working DIRECTLY together more, rather than abstracting everything so deeply that it obscures things.