On 2022-11-04 at 13:08, Curt wrote: > On 2022-11-04, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote: > >> On Fri, Nov 04, 2022 at 02:52:29PM -0000, Curt wrote: >>> 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). Or some of them may even have never contained the vulnerable code in question. For example, look at FFmpeg. It builds a separate binary package for each of several libraries, such as libavcodec and libavutil (and their matching -dev packages), as well as for the executable tool ffmpeg itself. All of these come from the single 'ffmpeg' source package. Some of the source code in that package is shared between the various libraries and other tools that are built from the FFmpeg project, but some of it is used only by a single library or tool. Now hypothesize that someone finds a security vulnerability in a part of the FFmpeg source code that's used only by libavcodec, and a CVE is filed against libavcodec as a result. Given the behavior described above, this would result in debsecan showing the CVE for all of the binary packages that are built from the ffmpeg source package, even though only some of them - libavcodec[*] and libavcodec-dev, and possibly ffmpeg itself - include the vulnerable code. (The [*] represents the "SO version" of the library, which changes when the library ABI changes, and so will not be the same for everyone who reads this message.) -- 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