Hi againI have now looked through the CVEs for libpodofo and found that all remaining issues in wheezy except one are of the DoS class.- Almost all are null pointer dereference- One is a heap-over-read causing a crash- One is unspecificed. So that one leaves some more investigation.I agree that we have a tool that allow pdf manipulation and that one can crash. However the service that run that tool should not crash because of that. So this means that the pdf-manipulation will fail but the service should still run. If the service do not handle tool failure that should in most cases be seen as a buggy service.This leaves me to think that we should mark all of them (with the exception of one) as a no-dsa minor issue.Anyone disagree?Someone can of course still look into fixing these issues.Best regards// OlaOn 30 April 2017 at 23:44, Ola Lundqvist <email@example.com> wrote:Hi MarkusGood points. Thank you for the advice.Best regards// Ola--On 30 April 2017 at 23:34, Markus Koschany <firstname.lastname@example.org> wrote:Hi Ola,
Am 30.04.2017 um 22:00 schrieb Ola Lundqvist:
> Hi Markus
> I think we mostly agree on things here. Good to know.
> There are some minor comments I have though:
> 1) There are to my knowledge two types of "no-dsa". One "Minor issue
> will be fixed in next point release" and another "Minor issue". I have
> been told that if security team decides for a "minor issue" LTS should
> in most cases do the same. However if it is a "minor issue will be fixed
> in next point release" we should probably fix it as usual.
I think everyone who triages packages has to make a decision from time
to time. It can be right or wrong. In my opinion we should not blindly
follow "no-dsa" tags from the security team but instead use the
opportunity to doublecheck issues and make up our own mind. Nevertheless
to a very high degree the security team's decisions are reasonable of
course and often when I triage packages I follow Jessie too.
My point is that "no-dsa" is not final and absolute. If you catch
yourself spending ten hours on a single issue and end up backporting
large portions of the latest upstream release for a no-dsa bug, it might
not really be the best thing to do. But if the fix is straightforward
and manageable and there is even a more serious bug, it shouldn't be
much of an issue to fix the no-dsa bugs as well. Let's face it most of
the Jessie no-dsa CVE won't be fixed in a point release unless we do it
now or in the next LTS.
> 2) Regarding DoS class. I agree that this can be serious, but to me it
> looks like there are no actual service software that depend on this
> library. Just desktop software. We could however consider custom-built
> software that directly depend on this library. I find that to be a
> rather unlikely situation. Still it can be considered.
I consider desktop software like scribus or calibre to be valid
consumers of libpodofo and there is even libpodofo-utils which includes
tools to manipulate PDF files. The latter is suitable for use on server
systems. I think we shouldn't discriminate between server and desktop
> Apart from these comments I agree with you.
> One question to you. Will you look further into fixing the rest of the
> problems? In that case I can add the dla-needed.txt file with your name
> on it. :-)
I have talked to Mattia, the maintainer of libpodofo. He intends to fix
these bugs in unstable and Jessie as well as soon as upstream released
more updates. He will be able to reuse my patches for Jessie. At the
moment I don't intend to assign myself to libpodofo again because
upstream is rather slow with fixing those CVEs. Maybe later but if
someone else wants to work on it now, please go ahead.
--- Inguza Technology AB --- MSc in Information Technology ----\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /-----------------------------
------------------------------ --------- Inguza Technology AB --- MSc in Information Technology ----\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /----------------------------- ------------------------------ ----