[poppler] Do we need to remove the internal DCT and JPX decoders

[Albert Astals Cid]

El dimarts, 16 de maig de 2017, a les 19:40:31 CEST, jose.aliste at gmail.com va 
escriure:
> 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
         * --dct-decoder=unmaintained
         * --dct-decoder=none

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).

Cheers,
  Albert

> 
> 
> Kind regards
> 
> José