Subject: Re: NetBSD 2.0 release date
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Eric Haszlakiewicz <email@example.com>
Date: 12/06/2003 20:02:38
On Sat, Dec 06, 2003 at 02:45:58PM -0500, Greg A. Woods wrote:
> [ On Friday, December 5, 2003 at 12:55:05 (-0800), Jason Thorpe wrote: ]
> > Subject: Re: NetBSD 2.0 release date
> > In any case, bumping the major version of a library like libc is 100%
> > guaranteed to cause great great great pain
> What kind of pain are you talking about, and what causes it, exactly?
> What breaks, _exactly_, if the old library binaries are left in place?
> Are you really that worried that third party library vendors (if there
> really are any) won't know how to also bump their library versions?
I believe the problem is that (almost) all libraries have an _implicit_
dependency on libc. This means that the particular version of libc that
actually gets loaded at run time is controlled by what the final binary
is linked against. Say you have binary foo, linked against libbar.1.
Both of those were linked against libc.12. Now go rebuild libbar using
libc.13. Since the libbar major version hasn't been bumped the binary
foo will continue to use it, but the wrong version of libc will be used
causing the code in libbar that was compiled against libc.13 to likely
break in various ways. The fact that the old libraries are still installed
actually works against you here: programs will run even though it is
dangerous for them to do so.
If there was an explicit dependency in the library then this could
be caught by ld.so and it could refuse to run the program. Bumping the
major version of all libraries is another way to prevent those programs
from running. (or, rather, to allow them to keep running with a working
version of the library which was linked against an earlier libc)
Adding the explicit dependency might be a good first step to
implementing a libc major version bump. However, you still have to
worry about all the libraries already out there that only have the
implicit dependency. For that, we could have part of the daily
security check find all libraries on a system, and try to link a
minimal program against them (e.g. foo.o containing a dummy _start()
function, and a few other things) to make sure all dependant libraries
are explicitly listed.