[poppler] Do we need to remove the internal DCT and JPX decoders
Albert Astals Cid
aacid at kde.org
Wed May 17 22:13:25 UTC 2017
El dimarts, 16 de maig de 2017, a les 19:40:31 CEST, jose.aliste at gmail.com va
> Hey List,
> very recently, Thalos(CISCO) has encountered some overflows that could
> potentially lead to security risks. One of this is in the DCT decoder and
> the other in the JPX decoder. The question is what to do? Do we fix these
> overflows or just remove the decoders from poppler since they are not being
> mantained. One of the problems is that Ubuntu is compiled by default to use
> the JPX decoder while most distributions do include libjpeg support.
> The bugs as I understand are still private, so if any of the developers of
> poppler wants to see the reports, please contact me directly (off list) and
> I will send it to you together with a minimal pdf sample.
Right now we "almost silently" fall back to the unsupported code, yes we put a
warning at the very end of the configure/cmake process but i guess hardly
anyone reads those.
My suggestion would be change the configure/cmake process so it behaves like
this (process explained for libjpeg but same would apply for libopenjpeg)
* You have libjpeg -> all is good
* You don't have it, configure fails
* Unless you pass one of these two options
Which would give you either the unmaintained decoder or none at all.
At least this way we can totally pass the blame for distros for using either
the unmaintained or the none flags.
I am suggesting this instead of removing it because for some controlled
reasons it may be actually better to be able to use the unmaintained decoders
than nothing (e.g. you're running pdftotext inside a virtual machine, doesn't
matter if you get "rooted" inside the virtual machine).
> Kind regards
More information about the poppler