[Pkg-netatalk-devel] Bug#1051066: Bug#1051066: netatalk: 9 outstanding CVEs in Bullseye with available patches

[Jonas Smedegaard]

Quoting Daniel Markstedt (2023-09-03 08:40:35)
> ------- Original Message -------
> On Saturday, September 2nd, 2023 at 1:33 AM, Jonas Smedegaard <jonas at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-netatalk-devel/attachments/20230903/bffc3e22/attachment.sig>