Re: Tracking related source packages
I think related packages is fairly easy to automate. I wrote a small script that takes a line separated list of packages on standard input and outputs what packages that are (likely) related.
Here is an example usage:
ola@tigereye:~$ cat stretch-packages.txt | sort -u | ./find-related-source.pl
| grep golang
golang, golang-1.6, golang-1.7, golang-1.8
You can find the script here:
Finding embedded code copies is harder.
On Thu, 25 Feb 2021 at 20:02, Moritz Mühlenhoff <email@example.com
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.
> - Approaches:
1. Add a new file to the tracker with active mappings, e.g.
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.
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.
--- Inguza Technology AB --- MSc in Information Technology ----