Re: How to handle freeimage package
Hi Santiago
See below.
On Thu, 11 Apr 2024 at 02:34, Santiago Ruano Rincón
<santiagorr@riseup.net> wrote:
>
> Hi Ola,
>
> El 10/04/24 a las 22:08, Ola Lundqvist escribió:
> > Hi all
> >
> > Sorry for late reply. It took me too long today to answer the CVE
> > triaging discussion. Now to this issue.
> >
> > Regarding the fedora patches. The patches seem to help for those
> > specific issues they solve.
> >
> > My intention for claiming the package was to go through the CVEs and
> > mark them with postponed or similar.
> > When I'm done with that maybe I will start to fix things, but I
> > claimed it just to avoid double work when going through the issues.
> >
> > I'll start with that now and I hope I can release the package when I'm
> > done with that. I'll re-claim it when/if I think they are worth
> > fixing.
>
> IMHO, claiming a package means working at addressing the issues, fixing
> them. (Re)Triaging of course can/must be done, for example to confirm if
> the issue affects or not specific debian releases. So it reads weird to
> claim a package to mark issues as postponed.
So what other options do I have to avoid double work? I only planned
to do it while doing the triaging and if I found any easy fixes I
would do them, or at least provide patches.
I see nothing wrong with claiming a package for a short while.
But if more people do not think we should use that practice I will
stop that with the risk of double work being done.
> > What is clear after checking all reverse dependencies is that all
> > software packages using freeimage library are of the "tool" type. You
> > run it with human interaction and the user using the tool should know
> > the input. This reduces the severity of the problems.
>
> I am afraid I completely disagree with that. Malicious actors could take
> advantage of security flaws (such as buffer overflows) in interactive
> tools to, e.g., run arbitrary code, cause DoSs, etc. This is true for
> PDFs readers, image processing tools, and etc.
Yes, but it affects the severity of the problem. Remote arbitrary code
execution is more severe than arbitrary code execution after human
interaction.
You can see that definition in the Debian Security team guidelines and
in many other definitions on the severity.
> Part of our mission is to help Debian users to have secure systems, and
> this includes interactive tools.
Yes, but if you look at the Debian Security teams definition on what
defines the different severity levels there is a clear distinction
between that type of software is being used.
https://security-team.debian.org/security_tracker.html#severity-levels
For example see the difference between how the following two are classified:
* local DoS -> low
* Most remote DoS -> medium
The ones I have now postponed are of the "local DoS" class. I'm here
interpreting that "local DoS" is the same as DoS after human
interaction. It is not entirely accurate but similar enough for
triaging decision. See my other mail thread about triaging guide.
I have not postponed any of the ones of type "permits code execution
after user interaction" yet.
Cheers
// Ola
>
> -- Santiago
--
--- Inguza Technology AB --- MSc in Information Technology ----
| ola@inguza.com opal@debian.org |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
---------------------------------------------------------------
Reply to: