Hi,
"Issues postponed for stretch, but fixed in buster via DSA or point
releases" is now almost empty. Hopefully it won't scare off FDs anymore ;)
For the 30ish other packages, I either revisited the triage, or could
add them to dla-needed.txt (and some to ela-needed.txt).
We got several batches of pending minor CVEs, but also a few more severe
missed updates and follow-ups, and checking the reported packages
brought some past tangent mistakes into light (see my past 2 days
commits for details).
I believe this report is an efficient tool for front-desk to keep track
of oldstable work on the numerous postponed vulnerabilities, and I
expect it to bring more interested packages in the future.
Cheers!
Sylvain
On 17/05/2022 20:47, Ola Lundqvist wrote:
Hi Anton
That is a way to view it. Interesting point. Is this the common view?
I'm asking since:
- the list is long and it does not look like previous front desk did that.
- I thought postponed meant that there is no need for a DLA, but we can
fix that later on when such a need appears.
I'm happy to do either way, but I want to do the right thing :-)
Cheers
// Ola
On Tue, 17 May 2022 at 15:37, Anton Gladky <gl...@debian.org
<mailto:gl...@debian.org>> wrote:
As far as I understand all of those packages can be
added into the dla-needed without pre-review? Why not just
put all of them together.
OK, maybe with the short note "needs manual checking" or
similar.
Regards
Anton
Am Di., 17. Mai 2022 um 14:43 Uhr schrieb Sylvain Beucler
<b...@beuc.net <mailto:b...@beuc.net>>:
>
> Hi,
>
> On 17/05/2022 08:44, Ola Lundqvist wrote:
> > When doing triaging this week as part of the front desk
assignment I
> > realized that the lts-cve-triage.py script outputs the following
> > section "Other issues to triage for stretch (not yet triaged for
> > buster)" after "Issues postponed for stretch, but fixed in
buster via
> > DSA or point releases".
> >
> > I think people before me have missed to help with that triaging
> > because that list of packages to check is long. At least it is
easy to
> > miss it.
>
> See https://lists.debian.org/debian-lts/2022/04/msg00011.html
<https://lists.debian.org/debian-lts/2022/04/msg00011.html> for
> context. I also talked about it during the monthly meeting.
>
> "Issues postponed for stretch, but fixed in buster via DSA or point
> releases" is a long section because it's new, it shouldn't stay
that way.
>
> I'm not sure why the past few front-desk didn't tackle it already
> despite the above communications, in any case I plan to tackle it
during
> my FD slot next week if nobody beats me to it.
>
>
> > Now to the question. Do we generally wait for the Debian
Security team
> > to do their analysis before LTS do it? If that is the case, the
> > current list makes sense. If not I think my proposed change
should be
> > done.
> >
> > I have done a change so that "Issues postponed for stretch, but
fixed
> > in buster via DSA or point releases" is much further down in
the list
> > because it is generally not so important for triaging work,
compared
> > to the other ones.
> >
> > Any objections? If not, I'll commit the change tomorrow.
>
> This section is where we are late compared to stable/oldstable, where
> CVEs are already fixed and published in Debian, but not in Debian
LTS,
> sometimes months after.
>
> This sounds more urgent to me than checking untriaged CVEs, hence why
> it's output before. So I'd keep the ordering as-is.