On 2022-11-04 at 12:49, tomas@tuxteam.de wrote: > On Fri, Nov 04, 2022 at 02:52:29PM -0000, Curt wrote: > >> On 2022-11-02, Andy Smith <andy@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. > > Sometimes you have a client/server package (think, e.g. PostgreSQL), > where you want to be able to install clients and servers separately. > > Sometimes you have one source package which can produce different > flavours of binary (think Emacs: -nox for no GUI, GTK, Lucid, etc. > for different GUI widget sets). > > Sometimes you have a bit of each :-) > > Have a look at the postgresql-13 source package for Bullseye [2]: I > count 13 binary packages generated from that :-) For one that often comes to my attention, look at systemd. Looking at the Package-List field visible from 'apt-cache showsrc systemd' on current-as-of-a-week-or-so-ago testing, I count 19 binary packages, including three which are related to udev and not to systemd at all (although for... some reason... systemd-the-project has decided to treat udev as just another component of systemd-the-suite, and so it gets included in the same single source package these days). More relevantly to this thread, the equivalent check with 'apt-cache showsrc grub2' (since grub2 is the source-package name for the packages named in the CVE mentioned by debsecan, according to the OP) shows 49 binary packages - no, that's not a typo, one short of fifty. Most of them follow the pattern of [name], [name]-bin, and [name]-dbg, but there are some outliers. If any of those are installed (or possibly even just not purged?) on the machine in question, that might explain why debsecan shows the CVE as being applicable. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature