On 2022-11-04, <to...@tuxteam.de> <to...@tuxteam.de> wrote: > > On Fri, Nov 04, 2022 at 02:52:29PM -0000, Curt wrote: >> On 2022-11-02, Andy Smith <a...@strugglers.net> wrote: >> > >> > So why is debsecan reporting this as a security issue? >> > >> > This is a very old host that has been continually upgraded since Debian
>> I don't really know, but maybe because >> Much like the official Debian security advisories, debsecan's >> vulnerability tracking is mostly based on source packages. This can be >> confusing because tools like dpkg only display binary package names. >> Therefore, debsecan displays the more familiar binary package names. >> This has the unfortunate effect that all binary packages (including >> packages containing only documentation, for example) are flagged as >> vulnerable, and not only those packages which actually contain the >> vulnerable code. >> I don't even understand that paragraph! Sorry for the interruption! > > One source package may give birth to several binary packages. > Typically you have at least three .deb -- the "business end" > containing the binary (or library, or whatever), the -doc > (which is typically packaged separately to the benefit of those > with tight space requirements [1], and the -dev, with all the > relevant headers for when you want to compile things against > this package. > So the man page means *all* the binary packages derived from a source package with a vulnerability are tagged, though some of those binary packages may have been patched for the vulnerability by the specific distro (or something). --
