Hi Moritz, Thanks for CC'ing.
On Thu, Feb 25, 2021 at 08:01:42PM +0100, Moritz Mühlenhoff wrote: > 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. > > For renamed source packages this isn't the case (and if they turn out > to be not vulnerable, they should be marked not-affected anyway) > > > - This is hard / doesn't make sense to fully automate. > > Security Team expressed opposition to such automation in the past. > > Quite the opposite, there's even a bug for it :-) This is #738172. In any case though such an automatism should not start clutering the list, because usually if one has such say a mapping of source packages A renamed from B renamed from C, and know an issue was introduced after the B rename, then we usually can skip C. > > > - Approaches: > > 1. Add a new file to the tracker with active mappings, e.g. > - golang-1.15,golang-1.11,golang-1.8,golang-1.7 I remember we discussed that some years ago indeed at the last sec team mmeeting, which resulted in the above bug for tracking :) this soulds like an idea, this means we would have an explict list of 'actively tracking' packages which is considered with a mapping. It is yet unclear to me how such a mapping would need to be constructed, something both human readable easy but clearly parsable for a helper script is needed (and with small dependency set ideally from python or perl core). In "metalanguage" maybe it could be something describing the following Case 1. Package is really renamed in unstable, and original package is removed (e.g. tiff, tiff3), so this should record as well that tiff3 is removed. Case 2. Package is "superseeds" the original package, examples of those might be the list of python versioned source packages python3.9 -> python3.8. For case 2 see as well the above comment, maybe the comment should be invalidated and in all circumstance add the entries from the active mapping. That means though as well we should then regularly after supports end for something clean up the active list that later on entreis are not cluttered anymore for stuff which is even not anymore in the LTS release (the script might need an override possiblity so that other projects like ELTS can manage their own active mapping lists). Side note: Embedded code copies though should still be handled separately, they need to be chekced on case to case basis, first if souece code is present, second if the security impact is actually given. > 2. Write a script which parses the CVE/list and creates a diff which > adds "foo <unfixed>" (or "foo <removed>") records if a CVE entry lists > one of the source packages of an active mapping, but not the others. Once such a lis then is know which is missing to be added with CVE/source package addition to data/CVE/list, one needs to know if it is <unfixed> or <removed>, this information probably needs to be in the mapping itself? Once the package is removed from unstable suite it should be in any case <removed> instead of <unfixed> initially. For the merging the helper function Emilio implemented (or even the script merge-cve-list) can be used to merge the entries properly in the list. > 3. Run the script manually for a while, to see if it all works well > > 4. If it works fine in practice, set up a hook/systemd timer to > run it automatically and commit the result to the tracker. Agreed on the manual part, integration of automatic updates though only once we would be confident to work in practice in almost all cases withouth we need additional fiddling later afterwards because it added in case X a bunch of entries wich are wrong. Regards, Salvatore
