Hi, 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 announcements. 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 embedded_in: - 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. Regards, Markus
Attachment:
signature.asc
Description: This is a digitally signed message part