Date: Thu, 23 Apr 1998 11:59:07 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking Message-ID: <199804231559.LAA09646@brain.zeus.leitch.com> In-Reply-To: Peter Jeremy's message of "Thu, April 23, 1998 13:45:19 %2B1000" regarding "Re: Static vs. dynamic linking" id <199804230345.NAA20055@gsms01.alcatel.com.au> References: <199804230345.NAA20055@gsms01.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
[ On Thu, April 23, 1998 at 13:45:19 (+1000), Peter Jeremy wrote: ] > Subject: Re: Static vs. dynamic linking > > - Fixing bugs in libraries is much easier - just replace a single > libc.so and the bug is fixed in all the programs that use it. This > mightn't be much of an issue for the hackers amongst us (who > regularly rebuild their entire systems), but will be an issue > as we try to expand our user base to less knowledgable people > (and people who don't want to have to do a `make world' every > time a CERT advisory comes out). That's definitely not as big a benefit as many people think it is, esp. in an "open source" system where it's relativley easy to re-build the whole world with all relevant fixes. The CM complexity issues of trying to fix more than one bug in a given library while still maintaining backwards compatability are often insurmountable. > - Run-time control (and extendability) of configuration. Examples > are Sun's name service switch and volume management, as well as > the idea of plug-in authentication modules for login (where this > thread started). "Security" and "plug-in" don't go together very well. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804231559.LAA09646>