Re: Included/staticly linked libraries in source packages:
* 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.)
Reply to: