[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tracking buster/stable updates suitable for LTS

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 <gladk@debian.org <mailto:gladk@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
    <beuc@beuc.net <mailto:beuc@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.
Reply to: