Hi Ola, thanks for rising this very important question.
Please use this ticket [1] for the discussion. So we will be able to formulate the common position and put everything into the documentation. [1] https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/38 Regards Anton Am Do., 14. Juli 2022 um 23:50 Uhr schrieb Ola Lundqvist <o...@inguza.com>: > Hi fellow LTS contributors > > During my front desk work I have now got down to the CVEs for buster > that are "postponed". > The triage script suggests me to "ignore" or "fix". > I know I should not change triaging status for buster, yet but I'm now > working on setting some best practices to use later on. > > The question is what to do with them in general. > > Here are some examples. > > composer CVE-2022-24828 > e2guardian CVE2021-44273 > bullseye is fixed but I cannot find any trace of a DSA. This must mean > that it was fixed in a point release without a DSA. I have not > checked. > For buster it was marked as no-dsa (Minor issue). Note not proposed > for point release. > One of them was unaffected in stretch the other was also marked as > minor issue for stretch. > > The security team have clearly indicated that this is a minor issue so > I guess it should not be added to dla-needed. > > But what should I do? Should I (or rather some future front desk when > buster is LTS responsibility) change the status from no-dsa to > ignored? > > Or should we change the lts-triage script to not tell that it should be > ignored? > > I'm asking since from earlier discussions we have said that we should > generally not mark issues as "ignored" unless we really should not fix > it, because of too intrusive change, backwards compatibility issues > and the like. Now our triaging script tells us that we should and that > is contradicting the earlier conclusions we had. > > Anyone with good advice? > > The other type is CVE-2021-28210 for edk2. It is marked as minor issue > for buster, but it was fixed in the scope of a DLA for stretch. > > In this case I'm more inclined to add it to dla-needed with the > motivation that it was fixed in stretch and if someone upgrade the > system should not get worse from a security perspective. > Maybe we should automate the detection of this case in some way. > > There are probably more, but now it is getting late for today so I > will continue checking tomorrow. > > Cheers > > // Ola > > -- > --- Inguza Technology AB --- MSc in Information Technology ---- > | o...@inguza.com o...@debian.org | > | http://inguza.com/ Mobile: +46 (0)70-332 1551 | > --------------------------------------------------------------- > >
