Hi Roberto See below.
On Fri, 12 Apr 2024 at 00:51, Roberto C. Sánchez <[email protected]> wrote: > > Hi Ola, > > On Thu, Apr 11, 2024 at 11:11:15PM +0200, Ola Lundqvist wrote: > > > > What I typically do is to read the description, and the referenced > > material to see if the reporter seems to make sense. If there is a fix > > available read the fix. The fix typically give a lot of information. > > In this case there were no fix, only a reproducer and backtrace > > description. They seemed to make sense and therefore I postponed the > > ones that were mentioned as DoS class in the same way as the other > > issues had been postponed when they were of the same class. > > > > I think that it may help to take a step back and look at the big picture > with freeimage. > > - 42 "vulnerable" or "no-dsa" CVEs dating back to 2019 in the security > tracker > - 6 of those are "Minor issue" for (old)stable > - the other 36 are "Revisit when fixed upstream" > - upstream is dormant (maybe dead?) > > In this particular instance, it seems like a waste of time to dig into > individual CVEs for the purpose of triage. Ask yourself, what is to be > gained by spending time doing a detailed triage of each CVE? > > What does seem to make sense is (again, in this particular instance): > > - copy the secteam triage decision for buster for the CVEs that have not > yet been triaged for buster > - move on to the next package (since none of the CVEs have fixes > available) I completely agree. This was my original intention. I send out the email to double-check if that was ok and whether we should also remove it from dla-needed. With your suggestion above, should I also remove it from dla-needed? See also the three outcomes below. > That said, it would be valid for someone who is an LTS contributor to > try to tackle developing fixes for these CVEs (and then also get them > submitted upstream and prepare appropriate patches for (old)stable as > well). But I also wouldn't blame anyone for looking at this package and > thinking that it would be too much trouble. Some of them has fixes in fedora. Should we fix them? I have removed the postpone decision for them (because the postpone decision say that we should postpone until there are patches available). > The point, however, is that triage is not meant to consume a great deal > of resources. If we were looking at a package with 2 or 3 recent CVEs, > then spending some amount of time triaging those CVEs makes sense. It > would be necessary to determine their severity because 2 or 3 CVEs of a > minor severity may not justify producing an update. In a case like that, > assuming that fixes are available, then marking the CVEs "postponed" and > waiting for more CVEs to accumulate would potentially be a sensible > course of action. > > However, looking at a package with dozens of CVEs is a different matter. > It is necessary to scale the triage approach to a level appropriate for > the package under consideration. An exercise of judgment is required in > triage just as it is in the other aspects of dealing with a CVE, > developing/backporting patches, testing the fix, guarding against > regression, etc. > > Put another way, the state of freeimage is such that one of these two > things should happen: > > - what I suggested above (copy secteam decisions and move on to the next > package) > - dive in and start developing fixes to the individual CVEs I see three: 1) copy secteam decision and move on to the next package (I guess remove from dla-needed) 2) copy secteam decision for most of them, but fix the ones with fedora patches 3) dive in and start developing (that will take quite a lot of effort) I think we should do 1 or 2 as a start. Based on all other discussions I'm not sure what a "consensus decision" would be. > Either way, expending the tremendous effort that we have expended on the > specific triage decisions strikes me as a poor use of time. Could not agree more. And for your knowledge I have not spent much time on this. I wanted to avoid exactly that. Cheers // Ola > Regards, > > -Roberto > > -- > Roberto C. Sánchez > -- --- Inguza Technology AB --- MSc in Information Technology ---- | [email protected] [email protected] | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
