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 :-) Cheers [1] More use cases come to mind: e.g. if you install for several different architectures, you don't want the same doc several times, etc. [2] https://packages.debian.org/source/bullseye/postgresql-13 -- t
Attachment:
signature.asc
Description: PGP signature