This page keeps track of various tasks that need to be handled.

DLAs on www.debian.org

DLAs are now visible on www.debian.org but there is still some manual work to be done and improved:

Improve scripts to detect missing package assignments

There are many cases where a CVE should be assigned to multiple source packages (either because there are multiple copies of the same software, ex "tiff" and "tiff3", or because other source package are embedding the vulnerable software). It would be nice if our CVE triaging script could detect when we are missing some package assignments ...

See discussion starting at: https://lists.debian.org/debian-lts/2017/03/msg00177.html

automatically strip no-dsa tags by gen-DLA

Sometimes issues tagged no-dsa are fixed by an upload. In such cases the no-dsa tag currently has to removed manually from CVE/list. It would be more reliable and convinient to do this with bin/gen-DLA , which then would strip existing no-dsa tags for CVE IDs passed to the script.

Improve tools to automatically unclaim a claimed package after a week

As per the discussion started in Message-ID: <87a7mjsm9y.fsf@curie.anarc.at>

In progress: https://salsa.debian.org/security-tracker-team/security-tracker/merge_requests/23

Implement script to dispatch frontdesk duties and document on tagging of unavailable weeks

The last manual and auto-assignment was not optimal. Someone (anyone) in the team or a script must distribute the FD duties. Previously to each dispatching, contributors need to tag their future unavailable weeks.

Improve documentation on frontdesk work: Handling bugs tagged no-dsa in oldstable

The reasons for a no-dsa in stable could no apply 100% in oldstable (next-point-release, lack of manpower). We need to improve the frontdesk documentation to explain how we deal with no-dsa tags. We should not follow blindly the debian security no-dsa tags.

Improve the security-tracker to not break salsa

fix https://bugs.debian.org/908678 so that the security-tracker doesn't break salsa.d.o (a.k.a. data/CVE/list is too big, though the security team doesnt want to split the file...)

Regressions, try to minimise them with DEP-8 tests

autopkgtest and ci.debian.net could help to prevent regressions. We could include then tests on important packages with regular updates. At least, before uploading packages with tests, autopkgtest should be run using a jessie image (since running on a local unstable is not fully reliable).

It would be also useful to make ci.debian.net run tests on jessie+jessie/updates, stable+stable-proposed-updates and other suites.

TODO items

History

Find upstream developers who are willing to work on LTS support

For difficult packages (frequent security updates where backports are hard and require domain specific knowledge), we should try to identify upstream developers who are willing to do the backporting work. They could be paid by Freexian for the hours where we need them.

Possible packages where we might need such help:

Expected outcome

Write a list of the persons identified somewhere and send the hourly rates of those persons to deblts@freexian.com.

History


CategoryLts