* 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.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
