Many discussions about open source dependencies and maintenance happened in the last month.Two posts caught my eye in the Rust ecosystem: Sudo-rs dependencie...
I’m going to be honest, I’m getting a little tired of hearing everyone’s thoughts on the xz backdoor. It’s discouraging and sucks when every detail of the project which, keep in mind, was maintained by one person who fell victim to a social engineering attack, is scrutinized. It makes me concerned about anyone depending on any of my projects.
Especially the comments on things such as the build scripts, which this kind of article seems to gravitate towards. If the build scripts were tiny and checked then the attack vector would have just been different, I’m not even too sure the language mattered. The attack was social engineering, after that it was pretty much project agnostic. xz was targeted cause the maintainer was done working on it and it was heavily depended on.
I’m not saying incomprehensible build scripts are good here, my mistake for making it seem that way. I’m not confident that hiding it elsewhere would have been strictly more obvious but it absolutely could have been.
I’ve done some pretty complex C projects and haven’t had build scripts nearly that large. This one seems particularly unwieldy and certainly helped the attacker.
I think this article has a more thoughtful take than most I have read on the subject. In particular, I agree that we need to move away from the bazaar model and back towards the cathedral model, at least for critical software (he suggests smaller projects being adopted into larger, better funded and maintained consolidations). Another key observation is that a lack of activity does not mean a project is abandoned - it may just be feature complete. The flip side of that is, I think, that it is okay for projects to say “this is done” and resist the urge to expand into new areas and add endless complexity and dubious features.
I’m going to be honest, I’m getting a little tired of hearing everyone’s thoughts on the xz backdoor. It’s discouraging and sucks when every detail of the project which, keep in mind, was maintained by one person who fell victim to a social engineering attack, is scrutinized. It makes me concerned about anyone depending on any of my projects.
Especially the comments on things such as the build scripts, which this kind of article seems to gravitate towards. If the build scripts were tiny and checked then the attack vector would have just been different, I’m not even too sure the language mattered. The attack was social engineering, after that it was pretty much project agnostic. xz was targeted cause the maintainer was done working on it and it was heavily depended on.
I have to disagree here. Maybe they would have found another way, but it would have been a more obvious way, which is a very good thing.
Yes it would have still been compromised but it may have been detected earlier. So it’s still pretty bad to have these incomprehensible build scripts.
I’m not saying incomprehensible build scripts are good here, my mistake for making it seem that way. I’m not confident that hiding it elsewhere would have been strictly more obvious but it absolutely could have been.
I’ve done some pretty complex C projects and haven’t had build scripts nearly that large. This one seems particularly unwieldy and certainly helped the attacker.
I think this article has a more thoughtful take than most I have read on the subject. In particular, I agree that we need to move away from the bazaar model and back towards the cathedral model, at least for critical software (he suggests smaller projects being adopted into larger, better funded and maintained consolidations). Another key observation is that a lack of activity does not mean a project is abandoned - it may just be feature complete. The flip side of that is, I think, that it is okay for projects to say “this is done” and resist the urge to expand into new areas and add endless complexity and dubious features.