Quoting Daniel Markstedt (2023-09-03 08:40:35) > ------- Original Message ------- > On Saturday, September 2nd, 2023 at 1:33 AM, Jonas Smedegaard > <jo...@jones.dk> wrote: > > > > > This is one bugreport about multiple issues. That easily gets confusing > > to track, e.g. if some of the issues are solved and some are not, for a > > certain release of the package (and consequently a Debian release where > > that package release is included). > > > > It is generally easier to track when instead filing one bugreport per > > issue. > > > > I can see how this is the preferred approach for a clean tracking of each > security issue. In this case it gets a bit hairy since we have cases where > one patch fixed multiple CVEs, and elsewhere multiple patches were required > to fix regressions introduced by a CVE fix. It was a journey of >1 year to > get to the present state. > > > I tried lookup one of above CVEs inn the Debian security tracker: > > https://security-tracker.debian.org/tracker/CVE-2022-43634 > > > > It references an already filed bugreport about that issue, bug#1034170, > > which is tagged as found only as early as 3.1.14~ds-1. If earlier > > Debian package releases are also affected by that particular issue, then > > please update that bugreport to reflect that fact. > > > > This bugreport is flagged as "archived" (which is done automatically > > after being done for a while, to reduce spam). Before doing other > > changes you therefore need to first unachive it. > > > > E.g. something like this: > > > > bts unarchive 1034170 . found 1034170 3.1.13~ds-1 > > > > Will do, thanks for the command. > > > The other CVEs seemingly have no related bugreport (from a quick look at > > the security tracker - but I suspect that database does not list > > bugreports not involving the security team at first, and only later > > mentioning a CVE if at all). If you don't happen to be aware of > > bugreports exisisting for those other issues, then I suggest to file new > > individual bugreports for each issue (also because it is easy to merge > > issues later as needed). > > > > That's a fairly big undertaking, especially if clean and atomic patches are > required for each...
Minimal patching is required for stable releases, but it can be one patch solving 9 issues, or a combination of multiple patches solving a single issue. > I was really hoping the batch approach would be accepted. > > That said I can definitely create the individual bug tickets for starters and > we can take it from there. Let me set aside some time next week for this. I don't mean to bother you with silly paperwork. I don't mean to imply that each issue need to be *solved* separately, only that it generally is easier to *track* issues separately. E.g. it makes great sense to close several bugreports with a single patch. And if that patch turns out to not actually solve all issues then we can "reopen" or "unseen" individual bugreports as needed. If 9 issues are tracked in one bugreport, then it is not possible to structurally (only sloppily in prose) communicate if "2nd and 5th of the 9 issues reported here was not yet fixed after all"... Hope that makes sense. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
