Hi,
If I understand correctly, the proposal is to NOT track unbound1.9 in
security-tracker, but track it separately and explicitly as another
exception in the LTS Front-Desk documentation and/or scripts.
> I can take a
> look at it since I was responsible for the unbound1.9 upload anyway.
Fine by me.
- Sylvain
On 29/04/2021 22:16, Markus Koschany wrote:
Am Donnerstag, den 29.04.2021, 20:59 +0200 schrieb Salvatore Bonaccorso:
On Thu, Apr 29, 2021 at 06:29:33PM +0200, Sylvain Beucler wrote:
Hi,
I saw a batch of new CVEs were tracked for 'unbound', but not for the
stretch-specific 'unbound1.9' package[1].
I can go ahead and add '- unbound1.9' entries in data/CVE/list but I'm not
sure whether that's what we want. Should I?
Thanks Sylvain for the heads-up.
[1] https://lists.debian.org/debian-lts/2021/02/threads.html#00023
As I tried to explain back then in the thread, IIRC, that would in
fact not be really technically correct, because unbound1.9 was never
in unstable at any point in time. As such technically
- unbound1.9 <removed>
would so imply that. I'm not sure if they will warrant an update, but
if you think so why not as proposed there just add the item to
dla-needed.txt list and mention the association with unbound (which
LTS does not support anymore, right?)?
Agreed. I suggest to mark all CVE for unbound in Stretch as end-of-life. This
was already announced in May 2020 and we shouldn't change that retrospectively.
The introduction of a new source package unbound1.9 was an exception due to a
special request. In my opinion we should add unbound1.9 to dla-needed.txt and
investigate which one of the current open CVE affect this version. I can take a
look at it since I was responsible for the unbound1.9 upload anyway.
FTR, linux-4.19 is handled in the very similar way, we never add those
entries for "unstable" to data/CVE/list but Ben just fixes them in a
DLA accordingly. I would follow here the same schema for this very
special package and situation (and if you have it document it
accordingly for the LTS workflows).
+1
