Hi Anton,
Thanks for testing the patch.
I see you committed it by mistake while triaging; I reverted and
recommitted with proper authorship and commit information (linking this
thread).
Newly identified packages are ready to be triaged :)
Cheers!
Sylvain
On 21/04/2022 08:15, Anton Gladky wrote:
> I have just tested the patch and it really produces much more packages
> to be triaged and they are really reasonable!
>
> I would propose to merge it into the master branch and start to use it.
>
> Thanks for that!
>
> Am Mi., 20. Apr. 2022 um 20:54 Uhr schrieb Sylvain Beucler
> <beuc@beuc.net <mailto:beuc@beuc.net>>:
>
> Hi Anton,
>
> There's no need for a MR for this short lts-specific patch, and I
> believe this list has better visibility for the LTS team than the
> security-tracker salsa project (where lts-cve-triage.py resides).
>
> Cheers!
> Sylvain
>
> On 20/04/2022 18:09, Anton Gladky wrote:
> > Hi Sylvian,
> >
> > thanks for your work! Could you please create a merge request,
> > so we can discuss this nice improvement there?
> >
> > Regards
> >
> > Am Mi., 20. Apr. 2022 um 17:33 Uhr schrieb Sylvain Beucler
> > <beuc@beuc.net <mailto:beuc@beuc.net> <mailto:beuc@beuc.net
> <mailto:beuc@beuc.net>>>:
> >
> > Now with the patch.
> >
> > On Wed, Apr 20, 2022 at 05:08:20PM +0200, Sylvain Beucler wrote:
> > > During my last front-desk week I noticed that we tend to
> miss or
> > delay
> > > some buster security updates, in particular those that
> come in point
> > > releases, and a few batches of minor postponed fixes. See for
> > > instance, 'dpdk' [1] or 'mailman' [2].
> > >
> > > Attached is a patch to 'bin/lts-cve-triage.py' to help
> exhibit those
> > > updates so we schedule them in dla-needed.txt. This
> includes fixes
> > > from stable/oldstable point releases or past DSAs, but
> excludes
> > issues
> > > explicitly ignored, and old fixes from back when buster
> was unstable.
> > >
> > > The current output is manageable (40-50 packages), and I
> plan to trim
> > > it further down by properly tagging <ignored> some no-dsa
> issues that
> > > are not meant to be fixed in stretch (see e.g. 'ark' [3]), and
> > tagging
> > > <end-of-life> a few others (e.g. 'node-*').
> > >
> > > At this point front-desk can proceed as usual using the
> enhanced
> > > 'lts-cve-triage.py' output. Front-desk may need to use
> 'no-dsa'
> > > sparingly in the future, in favor of its 'postponed' and
> 'ignored'
> > > sub-states [4], so as to better help the tool.
> > >
> > > What do you think?