Re: Revisiting some old DLAs
On Mon, Dec 09, 2024 at 07:22:30PM -0300, Santiago Ruano Rincón wrote:
>...
> El 08/12/24 a las 07:30, Adrian Bunk escribió:
> > On Fri, Dec 06, 2024 at 10:10:19PM -0500, Roberto C. Sánchez wrote:
>...
> > > I have done my best to carefully document for each package the CVE(s)
> > > which are involved. In the cases where a bullseye DLA is needed, I have
> > > also added the package to dla-needed.txt (along with a link to the
> > > related Salsa issue). For packages which were last updated in 2024, I
> > > have gone ahead and assigned the issue in Salsa to the same individual
> > > that prepared the last DLA. For older DLAs I did not do this, but rather
> > > tagged the individual or individuals who prepared the applicable DLAs.
> > >...
> >
> > Can we please maintain this information in dla-needed only,
> > and not have different information in different places?
> >
> > I initially missed this email, and noticed only quite late that a
> > package I picked in dla-needed was already supposed to be assigned.
> >
> > If you consider a DLA incomplete due to missing upload to pu,
> > you could just assign it to the person who is supposed to fix it.
> >
> > Or add it unassigned.
> >
> > Everyone and all tooling is used to dla-needed containing the
> > authoritative information.
> [snip]
>
> To be discussed. The issue with dla-needed (in its current form) and
> bookworm point updates is that dla-needed is aimed at the LTS release.
Current practice is that new DLAs are in dla-needed, and incomplete DLAs
(e.g. missing git) are gitlab issues.
Any DLA-fixed CVE that is fixed in bullseye but not in bookworm would
have to come from a DLA during the past 3.5 months where the contributor
failed to submit the fixes from a DLA to bookworm.[1]
I would treat these as incomplete DLAs, where a gitlab issue should be
created and assigned to the person who provided the DLA.
But my main grievance is regarding different information in different
places. If you want to assign a task to someone and add that in
dla-needed, then assign it in dla-needed and treat the information
in dla-needed as authoritative for responsibility/ownership.
Adding a task assigned in gitlab and unassigned in dla-needed is nuts.
> Yes, our workflow and tools can be improved, but I believe we are doing
> a good work (and thanks to all the team for that)!
To avoid future regressions, the tooling used for the Weekly Information
could check that every CVE fixed in a DLA is in stable at least one of:
- CVE not-affected
- CVE fixed in stable
- CVE fixed in stable-security
- CVE listed in data/next-point-update.txt
- package not in stable
- package listed in dsa-needed, assigned to the DLA contributor
Same check for oldstable, when LTS is oldoldstable.
Even the metadata for "python3.9 in LTS is python3.11 in stable"
already exists.
Such a check would likely create false positives that need manual
handling, but that's better than discovering years later that our
users have security regressions when upgrading.
> Cheers,
>
> -- Santiago
cu
Adrian
[1] let's ignore exotic cornercases like "CVE fixed in buster, package
not in bullseye, CVE unfixed in bookworm"
Reply to: