And when you have a security bug in your static library (let's call it "library Z", just for kicks), what do you do? Is it enough to just let the software know? What about big vendors, whose products might have 42 different copies of Z kicking around in the source base.
What if they miss some? Wouldn't an architecture that allows the distribution to define and replace Z on its own be valuable?
> "Wouldn't an architecture that allows the distribution to define and replace Z on its own be valuable?"
In theory, sure. But how many more years of practice do we need before we accept that it doesn't work that way in reality? That any change in Z is as likely to break apps that use it, as save them some hassle?
Clearly I was too subtle. It, uh, wasn't actually a hypothetical: zlib had known exploits that bit Microsoft and others for years because they had cut and pasted the library into a zillion places. Linux distros just updated.
There's no theory at work here. Static linkage of common components is a security vulnerability.
What if they miss some? Wouldn't an architecture that allows the distribution to define and replace Z on its own be valuable?