On Tue, 2008-01-08 at 21:43 -0800, Michael A. Peters wrote:
> <snip>
> I don't know what reasons the wiki gives, but if a bug (security or
> other) exists in a library and you statically link against it, then when
> that bug is fixed - you have to rebuild all apps that linked against
> the static lib or they will continue to contain the bug even, even when
> the library is updated. With shared libraries, that isn't an issue. With
> shared libraries, updating the library is all you need to do.
<disclaimer>
I believe in shared libraries and disavow any proclivity towards static
linking as an SOP. However ...
</disclaimer>
Just to add a little balance to the mix, I want to point out that if a
*really* secure and stable environment is needed and is managed by an
attentive and highly competent administrator, the static link avoids the
pitfall that besets shared libraries. If a shared library with a major
flaw - especially security related - is installed, the potential problem
instantly propagates to every application using that library.
As has been detailed, so do the fixes.
OTH, an application(s) that is(are) statically linked may be re-linked
and used as a test vehicle(s) before general application of the updated
library is begun. Although *not* an assurance of stability and correct
operation, this can permit a *relatively* more secure and stable
environment.
The downsides are obvious. The benefits less so. The environment should
determine the choice, with proper balance of cost vs. benefit.
No discussion of imprecise overhead estimates need be posted here. All
are well known and fall under the category of evaluation in a
cost/benefit scenario.
>
> zlib I believe was a real world example of this - some years ago (red
> hat 5 ??), zlib was found to have a bug that could potentially be
> exploited. A lot of apps linked against the static library. Even after
> zlib had been updated, those apps were still vulnerable until they were
> recompiled.
And of course, the flip side is that if shared libraries had been in
use, all applications that linked to it would have been immediately
vulnerable.
The longer the time from the dissemination of the flaw to the
dissemination of the fix, the greater the window of opportunity for
black hats and/or disastrous corruption.
> <snip sig stuff>
--
Bill
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
