Re: How to handle freeimage package
Hi Roberto
See below.
On Fri, 12 Apr 2024 at 00:51, Roberto C. Sánchez <roberto@debian.org> 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 ----
| ola@inguza.com opal@debian.org |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
---------------------------------------------------------------
Reply to: