<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 17, 2017 at 6:13 PM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El dimarts, 16 de maig de 2017, a les 19:40:31 CEST, <a href="mailto:jose.aliste@gmail.com">jose.aliste@gmail.com</a> va<br>
escriure:<br>
<span class="">> Hey List,<br>
><br>
> very recently, Thalos(CISCO) has encountered some overflows that could<br>
> potentially lead to security risks. One of this is in the DCT decoder and<br>
> the other in the JPX decoder. The question is what to do? Do we fix these<br>
> overflows or just remove the decoders from poppler since they are not being<br>
> mantained. One of the problems is that Ubuntu is compiled by default to use<br>
> the JPX decoder while most distributions do include libjpeg support.<br>
><br>
> The bugs as I understand are still private, so if any of the developers of<br>
> poppler wants to see the reports, please contact me directly (off list) and<br>
> I will send it to you together with a minimal pdf sample.<br>
<br>
</span>Right now we "almost silently" fall back to the unsupported code, yes we put a<br>
warning at the very end of the configure/cmake process but i guess hardly<br>
anyone reads those.<br>
<br>
My suggestion would be change the configure/cmake process so it behaves like<br>
this (process explained for libjpeg but same would apply for libopenjpeg)<br>
<br>
 * You have libjpeg -> all is good<br>
 * You don't have it, configure fails<br>
    * Unless you pass one of these two options<br>
         * --dct-decoder=unmaintained<br>
         * --dct-decoder=none<br>
<br>
Which would give you either the unmaintained decoder or none at all.<br>
<br>
At least this way we can totally pass the blame for distros for using either<br>
the unmaintained or the none flags.<br>
<br>
I am suggesting this instead of removing it because for some controlled<br>
reasons it may be actually better to be able to use the unmaintained decoders<br>
than nothing (e.g. you're running pdftotext inside a virtual machine, doesn't<br>
matter if you get "rooted" inside the virtual machine).<br>
<br></blockquote><div>I like this idea. I have only one concern about how to manage the "security" bugs that will  have here (like the two from CISCO). Do we simply reply that these are unmantained and that if any distribution is using this code, it's up to them to fix it and provide patches? </div><div><br></div><div><br></div><div>Cheers</div><div><br></div><div>José</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
  Albert<br>
<br>
><br>
><br>
> Kind regards<br>
><br>
> José<br>
<br>
<br>
______________________________<wbr>_________________<br>
poppler mailing list<br>
<a href="mailto:poppler@lists.freedesktop.org">poppler@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/poppler" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/poppler</a><br>
</blockquote></div><br></div></div>