[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tracking related source packages


Am Donnerstag, den 25.02.2021, 20:01 +0100 schrieb Moritz Mühlenhoff:
> Am Thu, Feb 25, 2021 at 05:30:05PM +0100 schrieb Sylvain Beucler:
> > - This problem is similar/related to tracking embedded code copies.
> >   See https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/2
> >   With one difference: there's no reference source package.
> Not reallly, embedded code copies has a very poor s/n ratio and
> would require manual assessment whether actually affected.


I agree that we can't create an automatism with regard to embedded code copies
if our information about them are yet insufficient. I have investigated source
packages for embedded code copies when we started to support Wheezy in ELTS and
did another check for Stretch a while back. I started with packages which are
rather frequently affected by security vulnerabilities and important server
packages like PHP, Apache, etc. ordered by number of appearances in security

What do you think about to completely remake the embedded-code-copies list? At
the moment we have a custom list with a specific format that resembles yaml.
Why not convert the whole list to real yaml to ease the creation of scripts to
parse the data? It is also human-readable and contributors may find it easier
to contribute new information to the list.

We could keep the current logic like:

source: libevent
 - target: transmission
   distribution: [bullseye,buster,stretch]
   type: embed
   bug: #529372
   severity: low

 - target: chromium-browser
   distribution: [bullseye,buster]


type is embed, modified-embed and static where statically linked is a problem
for security support which we would like to avoid. Just embedding a copy
without using it, is not critical and can be ignored. 

If we have this information we could combine it with a CVE triage script that
could report a possible problem when source a is embedded in target b and
statically linked but should ignore type: embed or embed-modified. The more
information we gather the better our decision making will be. 

Do you agree with this course of action? How can we keep the list up-to-date? I
can do the same check for Buster again but it would be simpler if we get the
maintainers involved somehow because they know best why there is a statically
linked version of another source package or not in their packages.



Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: