As far as I know, we currently have the following set of bugs related to the recent zlib vulnerability:
309196 rageircd (proactively filed, reused for CAN-2005-2096) 317523 aide 317966 dump 317967 dpkg 317968 zsync 317970 amd64-libs (private copy of DSO) 317971 ia32-libs (private copy of DSO) 317989 dar-static (deliberately linked statically) 318014 bacula-sd 318069 sash 318091 libphysfs-1.0-0 (missing build dependency) 318096 mrtg 318097 oops 318099 lsb-rpm 318100 texmacs (alpha only, probably buildd problem) 318101 systemimager-ssh (private copy of DSO) Most of those zlib copies were discovered by Christoph Biedl, who ran clamscan on the Debian mirror of the Computing Centre of FU Berlin (Hochschulrechenzentrum, ZEDAT). Thanks Christoph for scanning a whopping 650 GB of data (uncompressed)! Also thanks to Kurt Roeckx, who filed some of the other bugs. Not all of these bugs are indeed exploitable because some of the packages trust the input anyway, but if this the case is sometimes hard to tell without being familiar with the package. I hope the individual package maintainers can provide clarification. I didn't file any bugs for Windows binaries included in some packages which might have vulnerable code (Python distutils, for example). Input data for them seemed to be trusted, anyway. How shall we fix these bugs in stable and oldstable? zlib1g is already installed on most systems, so it should be reasonably safe to link dynamically against the system-wide zlib library. We only change programs which use zlib 1.2.x, so the code change is not substantial, either. In very few cases, static linking will continue (dar-static), and these packages must be recompiled against the fixed version of zlib. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
