On Tue, Dec 10, 2024 at 01:45:49AM +0200, Adrian Bunk wrote: > On Mon, Dec 09, 2024 at 07:22:30PM -0300, Santiago Ruano Rincón wrote: > > > > 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. > Only they aren't necessarily incomplete DLAs. At the moment we distinguish between "this package requires a (yet to be published) DLA in order to address one or more open issues" and "there is some deficiency in a (previously published) DLA that must be corrected." The first includes things like "I am fixing 4 of the 7 open CVEs, and after releasing the DLA I will immediately restore that package to Xla-needed" and the second includes the missing git tags and other houskeeping and admin things we track via Salsa issues.
This makes sense since packages in the first category can in theory be worked on by "anybody" and packages in the second generally need to be handled by whoever prepared the update in the first place. These packages for which I created issues in Salsa are in a bit of a middle ground, but I think that they lean in the direction of the second category. > 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. > It is authoritative and we treat it that way, for packages in the "this package requires a (yet to be published) DLA in order to address one or more open issues" category. However, not all of the packages for which I created issues in Salsa fell into this category. For some, the DLA was already published and completed and what was "missing" was an assist to the maintainer and/or SRM to get an update for a point release. That is not the sort of thing that Xla-needed is meant to capture. So, for that package list that we received, I created issues in Salsa (all of the packages) and I also added some to dla-needed (only packages that needed a new DLA). To minimize the likelihood of duplication, I noted in the Salsa issues when a package was also in dla-needed and in dla-needed I included a link to the Salsa issue. Because the need for a SPU does not cleanly fall into either of the above two categories, I elected to treat it more like an incomplete package update (and create a Salsa issue) because including these in dla-needed would broaden the scope of that file considerably. > Adding a task assigned in gitlab and unassigned in dla-needed is nuts. > I disagree. I explained my criteria in my email to the list, though not the rationale for why Salsa issues rather than putting everything into dla-needed. That said, there was not an especially clean separation between the SPU parts and the DLA parts. For instance, ISTR that in at least one or two cases the previously published DLA covered some CVEs and then today that same package has more CVEs open against it. So, the SPU really should include the previously DLA-fixed CVEs plus the other open CVEs, where the new DLA would only be concerned with the new CVEs. > > 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. > As Santiago mentioned elsewhere in this thread, we continue to improve our processes and tooling. Let me encourage you to write up an issue in lts-team/lts-extra-tasks to capture this. Ideally, real examples would be part of that issue write up, to aid in developing and testing the tool. Regards, -Roberto -- Roberto C. Sánchez
