[Cryptography] Are dynamic libs compatible with security? was: Apple and OpenSSL

[Bear]

I have to say the OpenSSL guys really and truly had a point when they 
pointed out that dynamic linking is not fully or easily compatible 
with the goal of security libraries.  

Inconvenient as it was for Apple (and inconvenient as it is for others) 
we really shouldn't be relying on dynamic linking to load security 
modules.  Remember, in security we're in the business of guaranteeing 
that things we haven't quite planned for do *NOT* happen.  Dynamic
linking is a great way to get things to happen even though you haven't
quite planned for them.  In fact that's its main selling point; dynamic
linking means you automatically link to versions of the libraries other
than the ones you had available when you shipped, even if they contain 
code you don't quite know about and haven't quite planned for.  We 
assume this new code is better in the usual case; but in trying to 
secure systems against attacks, we should be regarding that new code 
as an attack vector and assuming that it is written by Shaitan.

The other mindset, where we're busily trying to get good things 
we haven't quite planned for to happen, values the hell out of 
dynamically linking to new bug fixes.  But in security we have to look 
at it from the POV of professionals in the art of being certain that 
bad things (like dynamically linking to new bugs!) do NOT happen, 
and I simply do not see that as being compatible with dynamically 
linking to, and therefore trusting, newly updated code sight unseen.

The other thing about dynamic linking is that from the POV of the 
people who are updating the code that you're linking to, YOUR software
is at least possibly an unknown quantity.  They probably haven't tested 
with it unless yours is one of the four or five best-known applications
that uses their stuff.  Even if the update isn't part of an attack and 
isn't written by Shaitan, it's a bit much to trust that your usage 
pattern which worked with the previous release absolutely is guaranteed
not to expose a flaw in the current release.  Hard linking guarantees 
that *somebody* tests the library together with the product before the 
new behavior created by their combination is unleashed on the public.

Is this something that Apple can explain to its users?  I don't know.
Apple has a history of cultivating a user culture that puts a negative 
value on complex technical explanations, and makes a point of not 
requiring them to sit through those, so it really was sort of between 
a rock and a hard place there.  To some extent though, everybody with 
a modern user community that expects everything to work the same way 
faces the same problem.