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

[Daniel Markstedt]

------- 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...

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.

> 
> Kind regards, and thanks a lot for looking into this,
> 
> - Jonas
> 

You're welcome! 

Daniel