Re: Tracking related source packages
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
Reply to: