Re: Included/staticly linked libraries in source packages:

[Florian Weimer <fw@deneb.enyo.de>]

* Kurt Roeckx:

> Hi Florian,
>
> Thanks for doing all of this, since it was rather manual work for me.
>
> Afaik, there are 3 kind of problems with zlib:
> - It's build-depending zlib, but linking staticly
> - It has it's own copy of zlib, and links staticly to it
> - It has it's own copy of the zlib package (ia32-libs, amd64-libs)
>
> And I have no idea which of those problems your automated tests found,
> or how you did it exactly.

There's some explanation on the web page I mentioned before:

  http://www.enyo.de/fw/security/zlib-fingerprint/

> How I would do it is check all binaries and libs to:
> - Contains zlib, like staticly linked.  I guess clamscan did that
> somehow?  Does it find all version, compiled with different compiler
> version and options?  I have no good way of finding this.

It uses generic signatures which do not depend on the architecture.
By sheer chance, right now, there isn't even a difference between the
little-endian and big-endian patterns.

> - Doesn't not have a dedepency on the zlib (objdump -p file | grep
> NEEDED)

The pattern only triggers if one of the zlib object files is linked
in, so it's not necessary to perform this additional check.

> An alternative approach I had in mind was checking all sources to
> contain the zlib source internaly.

This gives a lot of false positives (GCC, GnuPG, tons of others).

> As part of Q&A we want to get rid of those and some other libraries
> and want to make sure those are dynamicly linked to the version in
> debian.  It would be nice if we could have a list of all packages
> like this.

There's a lintian wishlist bug (#318104) which, when implemented, is a
step in this direction.

> You will of course have to take packages using tar in tar into
> account.

You mean nested archives?  Usually, this is done on purpose, but we
should keep a file somewhere which lists all such packages.

> Are you willing to those tests for some of those other packages people
> tend to include which really shouldn't be included?

I don't have a mirror on my own, so I can't test this myself.  I like
the general idea, though.

(Note that the list of packages I posted only covers zlib 1.2, copies
of zlib 1.1 were not included because they aren't affected by the
vulnerability.)