Re: Bits from the Testing Security team
Nico Golde writes ("Re: Bits from the Testing Security team"):
> quoting Adam Heath from #debian-devel:
Thanks for passing that on.
> 2007-10-15 18:07 <eigood> dpkg's configure has an option for using
> shared libraries or static linking
> 2007-10-15 18:08 <eigood> for gzip, it can do a static library link,
> a dynamic library link, or a runtime
> fork/exec of gzip
> 2007-10-15 18:08 <eigood> afaicr, when I did the patch
> 2007-10-15 18:10 <eigood> the real reason, is dpkg used to only
> fork/exec gzip
> 2007-10-15 18:11 <eigood> for efficiency, I gave it an option to
> link to zlib
This reason doesn't make sense because it's not more efficient. It
saves about two fork/execs per package, which is not a significant
part of dpkg's execution cost.
Indeed on modern multicore systems running the decompression in a
separate process allows it to be run on a separate CPU, in parallel to
the other processing done by dpkg proper. So it might be faster.
(I haven't done any benchmarking but I think these conclusions are
pretty obvious.)
Scott James Remnant has said that statically linking the compression
libraries into dpkg was done for robustness. This makes more sense
but I disagree with this approach. There are numerous things on the
system that dpkg depends on working properly, and without which you
can be hosed - starting with the kernel and libc and working upwards.
Binding all of these things statically into dpkg somehow would be
madness, and there is no particular reason why compression libraries
are special. On the contrary there are a few reasons to bind
decompressors in particular more losely: it is useful to be able to
change the set of available decompressors (for both experiments and
future extensions), and decompressors tend to have occasional security
problems which make them vulnerable to their input and which therefore
require rebuilds of all packages which statically link agains them.
Having dpkg invoke the decompresser as a separate program provides
several IMO important advantages. It simplifies the code in dpkg, and
it greatly simplifies the management of cross-version compatibility
and multiple optional decompression schemes (including experimental
ones), by decoupling dpkg from the decompressers. It simplifies the
management of the dpkg source package (since it loses those
build-dependencies), avoids worry about security updates for
decompresser bugs, etc.
> 2007-10-15 18:11 <eigood> however, I didn't want to introduce
> another dependency into the base system
> 2007-10-15 18:11 <eigood> so I made it link statically
I think this would be misguided even if the premise (that the library
isn't included in some other bit of the base system) were true.
The purpose of removing dependencies from the base system is to try to
shrink the base system; this purpose is frustrated rather than
achieved by bundling copies of things into base packages.
Ian.
Reply to: